Podcast appearances and mentions of nate hopkins

Play Episode Listen Later Mar 9, 2021 45:00

Charles Max Wood goes into the origin story of his podcasting career and how it relates to his programming career. He starts with his interest from a young age in technology and his dreams of being a radio DJ. He moves quickly through college and into his first job after college where he was introduced to podcasts by a co-worker who had purchased an iPod. He calls out several mentors like Gregg Pollack, Eric Berry, Nate Hopkins, Cliff Ravenscraft, David Brady, Dave Jackson, and many more. He then explains what he'd do differently if he were starting today. Join the Dev Heroes Accelerator at https://devchat.tv/hero Panel Charles Max Wood Sponsors Dev Heroes Accelerator

dj podcasting started panel ipods dave jackson cliff ravenscraft eric berry david brady charles max wood gregg pollack nate hopkins

BONUS: How Charles Max Wood Started Podcasting -- And You Can Too

Play Episode Listen Later Mar 9, 2021 44:47

Charles Max Wood goes into the origin story of his podcasting career and how it relates to his programming career. He starts with his interest from a young age in technology and his dreams of being a radio DJ. He moves quickly through college and into his first job after college where he was introduced to podcasts by a co-worker who had purchased an iPod. He calls out several mentors like Gregg Pollack, Eric Berry, Nate Hopkins, Cliff Ravenscraft, David Brady, Dave Jackson, and many more. He then explains what he'd do differently if he were starting today. Join the Dev Heroes Accelerator at https://devchat.tv/hero Panel Charles Max Wood Sponsors This Dot Labs Dev Heroes Accelerator

dj podcasting started panel ipods dave jackson cliff ravenscraft eric berry david brady charles max wood gregg pollack this dot labs nate hopkins

BONUS: How Charles Max Wood Started Podcasting -- And You Can Too

Play Episode Listen Later Mar 9, 2021 45:10

Charles Max Wood goes into the origin story of his podcasting career and how it relates to his programming career. He starts with his interest from a young age in technology and his dreams of being a radio DJ. He moves quickly through college and into his first job after college where he was introduced to podcasts by a co-worker who had purchased an iPod. He calls out several mentors like Gregg Pollack, Eric Berry, Nate Hopkins, Cliff Ravenscraft, David Brady, Dave Jackson, and many more. He then explains what he'd do differently if he were starting today. Join the Dev Heroes Accelerator at https://devchat.tv/hero Panel Charles Max Wood Sponsors Dev Heroes Accelerator

dj podcasting started panel ipods dave jackson cliff ravenscraft eric berry david brady charles max wood gregg pollack nate hopkins

BONUS: How Charles Max Wood Started Podcasting -- And You Can Too

Play Episode Listen Later Mar 9, 2021 44:36

Charles Max Wood goes into the origin story of his podcasting career and how it relates to his programming career. He starts with his interest from a young age in technology and his dreams of being a radio DJ. He moves quickly through college and into his first job after college where he was introduced to podcasts by a co-worker who had purchased an iPod. He calls out several mentors like Gregg Pollack, Eric Berry, Nate Hopkins, Cliff Ravenscraft, David Brady, Dave Jackson, and many more. He then explains what he'd do differently if he were starting today. Join the Dev Heroes Accelerator at https://devchat.tv/hero Panel Charles Max Wood Sponsors This Dot Labs Dev Heroes Accelerator

dj podcasting started panel ipods dave jackson cliff ravenscraft eric berry david brady charles max wood gregg pollack this dot labs nate hopkins

BONUS: How Charles Max Wood Started Podcasting -- And You Can Too

Adventures in Angular

Play Episode Listen Later Mar 9, 2021 44:47

Charles Max Wood goes into the origin story of his podcasting career and how it relates to his programming career. He starts with his interest from a young age in technology and his dreams of being a radio DJ. He moves quickly through college and into his first job after college where he was introduced to podcasts by a co-worker who had purchased an iPod. He calls out several mentors like Gregg Pollack, Eric Berry, Nate Hopkins, Cliff Ravenscraft, David Brady, Dave Jackson, and many more. He then explains what he'd do differently if he were starting today. Join the Dev Heroes Accelerator at https://devchat.tv/hero Panel Charles Max Wood Sponsors This Dot Labs Dev Heroes Accelerator

dj podcasting started panel ipods dave jackson cliff ravenscraft eric berry david brady charles max wood gregg pollack this dot labs nate hopkins

BONUS: How Charles Max Wood Started Podcasting -- And You Can Too

Views on Vue

Play Episode Listen Later Mar 9, 2021 44:36

Charles Max Wood goes into the origin story of his podcasting career and how it relates to his programming career. He starts with his interest from a young age in technology and his dreams of being a radio DJ. He moves quickly through college and into his first job after college where he was introduced to podcasts by a co-worker who had purchased an iPod. He calls out several mentors like Gregg Pollack, Eric Berry, Nate Hopkins, Cliff Ravenscraft, David Brady, Dave Jackson, and many more. He then explains what he'd do differently if he were starting today. Join the Dev Heroes Accelerator at https://devchat.tv/hero Panel Charles Max Wood Sponsors This Dot Labs Dev Heroes Accelerator

dj podcasting started panel ipods dave jackson cliff ravenscraft eric berry david brady charles max wood gregg pollack this dot labs nate hopkins

RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

Play Episode Listen Later Jan 12, 2021 75:42

Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers. Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood Guest David Heinemeier Hansson Sponsors Linode Next Level Mastermind Links Action Text Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow David Heinemeier Hansson on Twitter @dhh, dhh.dk and Rework.fm Picks Andrew- How to Say It Andrew- Rework episode Nate- Stimulus Reflex Charles- Atomic Habits Charles- Ed Mylet show Charles- The MFCEO with Andy Frisella David Kimura- Swing set kit David Kimura- Rails 6 David Kimura- His daughter Ruby David Heinemeier Hansson- To Have or To Be David Heinemeier Hansson- Shape Up book David Heinemeier Hansson- Rails 6

RUBY 484: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

Play Episode Listen Later Jan 12, 2021 75:42

Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers. Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood Guest David Heinemeier Hansson Sponsors Linode Next Level Mastermind Links Action Text Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow David Heinemeier Hansson on Twitter @dhh, dhh.dk and Rework.fm Picks Andrew- How to Say It Andrew- Rework episode Nate- Stimulus Reflex Charles- Atomic Habits Charles- Ed Mylet show Charles- The MFCEO with Andy Frisella David Kimura- Swing set kit David Kimura- Rails 6 David Kimura- His daughter Ruby David Heinemeier Hansson- To Have or To Be David Heinemeier Hansson- Shape Up book David Heinemeier Hansson- Rails 6

RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

Play Episode Listen Later Jan 12, 2021 75:42

Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers. Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood Guest David Heinemeier Hansson Sponsors Linode Next Level Mastermind Links Action Text Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow David Heinemeier Hansson on Twitter @dhh, dhh.dk and Rework.fm Picks Andrew- How to Say It Andrew- Rework episode Nate- Stimulus Reflex Charles- Atomic Habits Charles- Ed Mylet show Charles- The MFCEO with Andy Frisella David Kimura- Swing set kit David Kimura- Rails 6 David Kimura- His daughter Ruby David Heinemeier Hansson- To Have or To Be David Heinemeier Hansson- Shape Up book David Heinemeier Hansson- Rails 6

Introducing Nate Hopkins, Working with ActionCable's API, Webpacker in Rails Engines, and Stimulus Reflex Updates

Remote Ruby

Play Episode Listen Later Dec 13, 2019 51:37

In this episode, we welcome Nate Hopkins to the sho, talk about ActionCable's API, discuss Jason's trouble with using JavaScript in a new Rails engine, get some updates from Nate on Stimulus Reflex, and Andrew shares experience with managing open source GitHub Action projects.

programming stimulus coding reflex javascript rails software development ruby on rails nate hopkins webpacker rails engines

021 - Nate Hopkins, Co-Founder of CodeFund

Rails with Jason

Play Episode Listen Later Oct 29, 2019 51:04

In this episode, Nate Hopkins of CodeFund joins me for a conversation about early-2000s JavaScript, Nate’s OSS project StimulusReflex, and the aforementioned CodeFund, an open-source funding platform.

co founders javascript rails oss nate hopkins codefund

RR 435: Alternatives to Adding React with Graham Conzett

Play Episode Listen Later Oct 22, 2019 59:28

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 Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in 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 Picks Charles 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

adventures cloud lego react alternatives babel stimulus github jest publish javascript html obs rails panelists basecamp css js angular sentry typescript shape up react native paul jarvis capybara indie hackers andrew mason railsconf charles max wood devchattv nate hopkins conzett webpacker react native web

RR 435: Alternatives to Adding React with Graham Conzett

Play Episode Listen Later Oct 22, 2019 59:28

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 Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in 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 Picks Charles 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

adventures cloud lego react alternatives babel stimulus github jest publish javascript html obs rails panelists basecamp css js angular sentry typescript shape up react native paul jarvis capybara indie hackers andrew mason railsconf charles max wood devchattv nate hopkins conzett webpacker react native web

RR 435: Alternatives to Adding React with Graham Conzett

Play Episode Listen Later Oct 22, 2019 59:28

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 Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in 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 Picks Charles 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

adventures cloud lego react alternatives babel stimulus github jest publish javascript html obs rails panelists basecamp css js angular sentry typescript shape up react native paul jarvis capybara indie hackers andrew mason railsconf charles max wood devchattv nate hopkins conzett webpacker react native web

RR 434: Surviving Webpack with Ross Kaffenberger

Play Episode Listen Later Oct 15, 2019 83:43

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 situation Ross 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 Kaffenberger Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues 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 Picks Dave 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

twitch embrace surviving cloud app transitioning pack chosen views manifest github javascript obs rails panelists portable knockout packs module volt js vue brandon sanderson stitch fix sentry jquery restream sprockets mistborn lg electronics webpack andrew mason btu charles max wood second everyday devchattv nate hopkins webpacker mozilla add

RR 434: Surviving Webpack with Ross Kaffenberger

Play Episode Listen Later Oct 15, 2019 83:43

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 situation Ross 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 Kaffenberger Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues 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 Picks Dave 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

twitch embrace surviving cloud app transitioning pack chosen views manifest github javascript obs rails panelists portable knockout packs module volt js vue brandon sanderson stitch fix sentry jquery restream sprockets mistborn lg electronics webpack andrew mason btu charles max wood second everyday devchattv nate hopkins webpacker mozilla add

RR 434: Surviving Webpack with Ross Kaffenberger

Play Episode Listen Later Oct 15, 2019 83:43

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 situation Ross 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 Kaffenberger Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues 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 Picks Dave 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

twitch embrace surviving cloud app transitioning pack chosen views manifest github javascript obs rails panelists portable knockout packs module volt js vue brandon sanderson stitch fix sentry jquery restream sprockets mistborn lg electronics webpack andrew mason btu charles max wood second everyday devchattv nate hopkins webpacker mozilla add

RR 431: Building a Consulting Business with Todd Kaufman

Play Episode Listen Later Sep 24, 2019 68:29

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

SOS 011: Diversity in Open Source with Laura Gaetano

Sustain Our Software

Play Episode Listen Later Sep 24, 2019 49:48

In this week’s episode of Sustain Our Software the panel interviews Laura Gaetano. Laura is a developer and designer, whose main job was running was running Rails Girls Summer of Code. The panel considers how great Rails Girls is and all that they are doing. The panel also expresses their love for the Rails framework. Laura explains the difference between Rails Girls and Rails Girls Summer of Code. The panel asks about the challenges that the Rails Girls Summer of code experience. Laura tells the panel how open source and the Ruby community has changed since they started. When they first started Rails Girls Summer of Code there was a lot less support for open source and diversity in programming. Now their main challenges are lack of resources, such as money and people who are invested in Rails Girls Summer of Code for the long term. Other challenges in the organization stem from the nature of the organization. They are just trying to get everything done, that things like documentation and long term management solutions get forgotten. They want to get all their experience for the last six years documented so that knowledge can help in the future of Rails Girls Summer of Code. The panel considers what a great feeling it is when people use or contribute to their open source and ask Laura what it’s like to actually help someone become a developer through her open source efforts. Laura explains how amazing it is to see women from past Rails Girls Summer of Code and their success. Laura shares her love of open source and the collaboration that happens in the community. Doing Rails Girls Summer of Code she gets a lot more human contact than in typical open source projects, she explains how that has made a difference in the way that she sees open source. The panel asks Laura about the state of diversity in open source. Laura explains that there are initiatives out there to support diversity in opensource. She invites everyone to visit opensourcediversity.org. They provide resources to learn about diversity. They even have an open forum where people have a safe space to learn about diversity. She explains that diversity is now a common talking point at conferences to help improve diversity by educating developers about it. The panel discusses making projects more inclusive and explains how Github added s social impact feature that helps make your project more inclusive. The topic turns to a talk Laura gave in 2017. Her talk explains that open source needs more than code. She explains that she would like to see more crowdsourcing of knowledge and design in open source. Programming is a major part of open source and she is so impressed the how willing programmers are to volunteer their time. However, she would love to see that desire from other people in the technology industry. Open source would be more maintainable if they had people marketing, networking, documenting. Having open source maintainers who focus on these things would help generate more funding and make it more sustainable. The panel considers why there is such an emphasis on the code contributions, even more so than managing or other roles in open source. Code is a very visible contribution, easy to hold up and say look what they did. Other roles aren’t so easy to hold up, how can someone hold up the hours they spent finding sponsors or perfecting documentation. The discussion turns to mental health in open source. Laura talks about her own state of mind and how hard it can be to get herself to do anything when she is feeling burnt out. She explains that she needs to change the way she approaches work. The panel discusses ways that we can help those experiencing mental health problems in open source. They suggest talking to each other more about their experiences, about what depression, anxiety, and burn out look like and how they affect different people. The panel discusses what processes can be put in place to help developers to avoid burn out. The panel wonders if developers are susceptible to mental health problems. Do the large workloads and high amounts of stress contribute to these issues. Laura explains that in her opinion, we as humans tend to think that our experience is unique, so other industries probably feel the same way. The reality is that this is a worldwide problem, especially for those that Laura calls knowledge workers. The panel considers other ways we can help open source maintainers not get burnt out. The power of gratitude is one way they think might help. Laura thinks that getting a thank you from supports is very important. She relates how she feels when she talks with participants of Rails Girls Summer of Code and how it makes all her hard work worth it. The panel discusses the power of money in open source, explaining why they started codefund. They explain the benefits of open source getting some money for their contributions. They consider the effect it plays on burn out. While Laura agrees to receive funds for open source contributions can be helpful, she warns that it could be a double-edged sword. She warns that the receiving fund could be adding more stress to open source because of the responsibility it adds. Laura explains that she has already started to see entitlement from open source users, getting upset when the maintainer doesn't fix something right away. The panel considers how these benefits and costs when the funding is anonymous compared to when it is a direct sponsorship. Panelists Eric Berry Nate Hopkins Guest Laura Gaetano Sponsors DevEd Podcast The Freelancers Show My Ruby Story CacheFly Links AlterConf Berlin 2017: Making your voice heard: Open Source Needs You by Laura Gaetano Laura Gaetano - Building inclusive Open Source communities | ReasonConf 2018 https://devchat.tv/ruby-rogues/ https://railsgirlssummerofcode.org/ https://opensourcediversity.org/ https://www.codenewbie.org/podcast/rails-girls-summer-of-code https://github.com/about/diversity https://twitter.com/natfriedman/status/1157379019878232064 https://m.signalvnoise.com/to-smile-again/ https://twitter.com/alicetragedy https://github.com/alicetragedy https://www.facebook.com/Sustain-Our-Software-SOS-857471391289849/ https://twitter.com/sos_opensource Picks Eric Berry: https://webflow.com/ Nate Hopkins: https://www.metabase.com Willow Hybrid Tree Laura Gaetano: Jocelyn K. Glei The Bulletin Design for Real Life

design diversity open code real life programming open source github rails panelists bulletin gaetano eric berry cachefly glei jocelyn k glei rails girls nate hopkins rails girls summer

Episode 11: Diversity in Open Source with Laura Gaetano

Sustain

Play Episode Listen Later Sep 24, 2019 49:53

In this week’s episode of Sustain Our Software the panel interviews Laura Gaetano. Laura is a developer and designer, whose main job was running was running Rails Girls Summer of Code. The panel considers how great Rails Girls is and all that they are doing. The panel also expresses their love for the Rails framework. Laura explains the difference between Rails Girls and Rails Girls Summer of Code. The panel asks about the challenges that the Rails Girls Summer of code experience. Laura tells the panel how open source and the Ruby community has changed since they started. When they first started Rails Girls Summer of Code there was a lot less support for open source and diversity in programming. Now their main challenges are lack of resources, such as money and people who are invested in Rails Girls Summer of Code for the long term. Other challenges in the organization stem from the nature of the organization. They are just trying to get everything done, that things like documentation and long term management solutions get forgotten. They want to get all their experience for the last six years documented so that knowledge can help in the future of Rails Girls Summer of Code. The panel considers what a great feeling it is when people use or contribute to their open source and ask Laura what it’s like to actually help someone become a developer through her open source efforts. Laura explains how amazing it is to see women from past Rails Girls Summer of Code and their success. Laura shares her love of open source and the collaboration that happens in the community. Doing Rails Girls Summer of Code she gets a lot more human contact than in typical open source projects, she explains how that has made a difference in the way that she sees open source. The panel asks Laura about the state of diversity in open source. Laura explains that there are initiatives out there to support diversity in opensource. She invites everyone to visit opensourcediversity.org. They provide resources to learn about diversity. They even have an open forum where people have a safe space to learn about diversity. She explains that diversity is now a common talking point at conferences to help improve diversity by educating developers about it. The panel discusses making projects more inclusive and explains how Github added s social impact feature that helps make your project more inclusive. The topic turns to a talk Laura gave in 2017. Her talk explains that open source needs more than code. She explains that she would like to see more crowdsourcing of knowledge and design in open source. Programming is a major part of open source and she is so impressed the how willing programmers are to volunteer their time. However, she would love to see that desire from other people in the technology industry. Open source would be more maintainable if they had people marketing, networking, documenting. Having open source maintainers who focus on these things would help generate more funding and make it more sustainable. The panel considers why there is such an emphasis on the code contributions, even more so than managing or other roles in open source. Code is a very visible contribution, easy to hold up and say look what they did. Other roles aren’t so easy to hold up, how can someone hold up the hours they spent finding sponsors or perfecting documentation. The discussion turns to mental health in open source. Laura talks about her own state of mind and how hard it can be to get herself to do anything when she is feeling burnt out. She explains that she needs to change the way she approaches work. The panel discusses ways that we can help those experiencing mental health problems in open source. They suggest talking to each other more about their experiences, about what depression, anxiety, and burn out look like and how they affect different people. The panel discusses what processes can be put in place to help developers to avoid burn out. The panel wonders if developers are susceptible to mental health problems. Do the large workloads and high amounts of stress contribute to these issues. Laura explains that in her opinion, we as humans tend to think that our experience is unique, so other industries probably feel the same way. The reality is that this is a worldwide problem, especially for those that Laura calls knowledge workers. The panel considers other ways we can help open source maintainers not get burnt out. The power of gratitude is one way they think might help. Laura thinks that getting a thank you from supports is very important. She relates how she feels when she talks with participants of Rails Girls Summer of Code and how it makes all her hard work worth it. The panel discusses the power of money in open source, explaining why they started codefund. They explain the benefits of open source getting some money for their contributions. They consider the effect it plays on burn out. While Laura agrees to receive funds for open source contributions can be helpful, she warns that it could be a double-edged sword. She warns that the receiving fund could be adding more stress to open source because of the responsibility it adds. Laura explains that she has already started to see entitlement from open source users, getting upset when the maintainer doesn't fix something right away. The panel considers how these benefits and costs when the funding is anonymous compared to when it is a direct sponsorship. Panelists Eric Berry Nate Hopkins Guest Laura Gaetano Sponsors DevEd Podcast The Freelancers Show My Ruby Story CacheFly Links AlterConf Berlin 2017: Making your voice heard: Open Source Needs You by Laura Gaetano Laura Gaetano - Building inclusive Open Source communities | ReasonConf 2018 https://devchat.tv/ruby-rogues/ https://railsgirlssummerofcode.org/ https://opensourcediversity.org/ https://www.codenewbie.org/podcast/rails-girls-summer-of-code https://github.com/about/diversity https://twitter.com/natfriedman/status/1157379019878232064 https://m.signalvnoise.com/to-smile-again/ https://twitter.com/alicetragedy https://github.com/alicetragedy https://www.facebook.com/Sustain-Our-Software-SOS-857471391289849/ https://twitter.com/sos_opensource Picks Eric Berry: https://webflow.com/ Nate Hopkins: https://www.metabase.com Willow Hybrid Tree Laura Gaetano: Jocelyn K. Glei The Bulletin Design for Real Life Special Guest: Laura Gaetano.

design diversity open code real life programming open source github rails panelists bulletin gaetano eric berry cachefly glei jocelyn k glei rails girls nate hopkins rails girls summer

RR 431: Building a Consulting Business with Todd Kaufman

Play Episode Listen Later Sep 24, 2019 68:29

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

SOS 011: Diversity in Open Source with Laura Gaetano

Play Episode Listen Later Sep 24, 2019 49:48

In this week’s episode of Sustain Our Software the panel interviews Laura Gaetano. Laura is a developer and designer, whose main job was running was running Rails Girls Summer of Code. The panel considers how great Rails Girls is and all that they are doing. The panel also expresses their love for the Rails framework. Laura explains the difference between Rails Girls and Rails Girls Summer of Code. The panel asks about the challenges that the Rails Girls Summer of code experience. Laura tells the panel how open source and the Ruby community has changed since they started. When they first started Rails Girls Summer of Code there was a lot less support for open source and diversity in programming. Now their main challenges are lack of resources, such as money and people who are invested in Rails Girls Summer of Code for the long term. Other challenges in the organization stem from the nature of the organization. They are just trying to get everything done, that things like documentation and long term management solutions get forgotten. They want to get all their experience for the last six years documented so that knowledge can help in the future of Rails Girls Summer of Code. The panel considers what a great feeling it is when people use or contribute to their open source and ask Laura what it’s like to actually help someone become a developer through her open source efforts. Laura explains how amazing it is to see women from past Rails Girls Summer of Code and their success. Laura shares her love of open source and the collaboration that happens in the community. Doing Rails Girls Summer of Code she gets a lot more human contact than in typical open source projects, she explains how that has made a difference in the way that she sees open source. The panel asks Laura about the state of diversity in open source. Laura explains that there are initiatives out there to support diversity in opensource. She invites everyone to visit opensourcediversity.org. They provide resources to learn about diversity. They even have an open forum where people have a safe space to learn about diversity. She explains that diversity is now a common talking point at conferences to help improve diversity by educating developers about it. The panel discusses making projects more inclusive and explains how Github added s social impact feature that helps make your project more inclusive. The topic turns to a talk Laura gave in 2017. Her talk explains that open source needs more than code. She explains that she would like to see more crowdsourcing of knowledge and design in open source. Programming is a major part of open source and she is so impressed the how willing programmers are to volunteer their time. However, she would love to see that desire from other people in the technology industry. Open source would be more maintainable if they had people marketing, networking, documenting. Having open source maintainers who focus on these things would help generate more funding and make it more sustainable. The panel considers why there is such an emphasis on the code contributions, even more so than managing or other roles in open source. Code is a very visible contribution, easy to hold up and say look what they did. Other roles aren’t so easy to hold up, how can someone hold up the hours they spent finding sponsors or perfecting documentation. The discussion turns to mental health in open source. Laura talks about her own state of mind and how hard it can be to get herself to do anything when she is feeling burnt out. She explains that she needs to change the way she approaches work. The panel discusses ways that we can help those experiencing mental health problems in open source. They suggest talking to each other more about their experiences, about what depression, anxiety, and burn out look like and how they affect different people. The panel discusses what processes can be put in place to help developers to avoid burn out. The panel wonders if developers are susceptible to mental health problems. Do the large workloads and high amounts of stress contribute to these issues. Laura explains that in her opinion, we as humans tend to think that our experience is unique, so other industries probably feel the same way. The reality is that this is a worldwide problem, especially for those that Laura calls knowledge workers. The panel considers other ways we can help open source maintainers not get burnt out. The power of gratitude is one way they think might help. Laura thinks that getting a thank you from supports is very important. She relates how she feels when she talks with participants of Rails Girls Summer of Code and how it makes all her hard work worth it. The panel discusses the power of money in open source, explaining why they started codefund. They explain the benefits of open source getting some money for their contributions. They consider the effect it plays on burn out. While Laura agrees to receive funds for open source contributions can be helpful, she warns that it could be a double-edged sword. She warns that the receiving fund could be adding more stress to open source because of the responsibility it adds. Laura explains that she has already started to see entitlement from open source users, getting upset when the maintainer doesn't fix something right away. The panel considers how these benefits and costs when the funding is anonymous compared to when it is a direct sponsorship. Panelists Eric Berry Nate Hopkins Guest Laura Gaetano Sponsors DevEd Podcast The Freelancers Show My Ruby Story CacheFly Links AlterConf Berlin 2017: Making your voice heard: Open Source Needs You by Laura Gaetano Laura Gaetano - Building inclusive Open Source communities | ReasonConf 2018 https://devchat.tv/ruby-rogues/ https://railsgirlssummerofcode.org/ https://opensourcediversity.org/ https://www.codenewbie.org/podcast/rails-girls-summer-of-code https://github.com/about/diversity https://twitter.com/natfriedman/status/1157379019878232064 https://m.signalvnoise.com/to-smile-again/ https://twitter.com/alicetragedy https://github.com/alicetragedy https://www.facebook.com/Sustain-Our-Software-SOS-857471391289849/ https://twitter.com/sos_opensource Picks Eric Berry: https://webflow.com/ Nate Hopkins: https://www.metabase.com Willow Hybrid Tree Laura Gaetano: Jocelyn K. Glei The Bulletin Design for Real Life

design diversity open code real life programming open source github rails panelists bulletin gaetano eric berry cachefly glei jocelyn k glei rails girls nate hopkins rails girls summer

RR 431: Building a Consulting Business with Todd Kaufman

Play Episode Listen Later Sep 24, 2019 68:29

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

RR 430: Opal with Elia Schito

Play Episode Listen Later Sep 17, 2019 59:51

Episode Summary Today’s guest Elia Schito has been a Ruby developer for 12+ years and works for Nebulab. During his career he looked for Ruby to JavaScript translators and found Opal. The panel discusses where Opal belongs within an app and when the compilation into JavaScript occurs. The main reason a person would want to use Opal is to avoid writing in JavaScript. Elia talks about the benefits of using Opal. One is that productivity is better in a language like Ruby. Also, if you’re working on a project that needs to get done quickly, it makes sense to use Opal so that your speed is not hindered. Elia talks about testing Opal with things like WebPacker and Hyperstack, and explains what Hyperstack is. Opal recently released a newer, bigger version, and Elia talks about the features of the new release. He details what kind of JavaScript it produces and how to hook it into your CICD, how to run it locally, and overall how to use the compiler. He talks about how to debug in Opal. He notes that during the development cycle in Opal, you can refresh your page and it will compile the Ruby code into JS, so if there are any errors you will see it immediately. Opal is compatible with other tools to check your code. In the future, Elia wants to increase the coverage of the core and standard library, and believes that Opal is a great way to increase your skills in Ruby and JavaScript. He talks about the general reception of Opal among users. Opal is a perfect fit for smaller teams or older fullstack developers, especially if you don’t have a frontend team Elia notes that Opal, much like anything else, is a matter of preference, and relates it to the past reliance on CoffeeScript. For developers who refuse to write in JavaScript, Opal is an excellent option. He talks about the speed of compiling ruby to JavaScript in Opal and how it supports keeping current with Rails versions and other frameworks. The panel asks if the Opal community made any inroads with DHH for making it part of the Rails stack proper and whether Opal wants to be integrated with Rails. Elia talks about some of Opal’s contributions to the Ruby Community. Elia talks about what generally happens if you choose to use Opal in a project. Opal is small, but you will have to make some tradeoffs. You have to call your standard library from Opal, but there are many ways to overcome that. The show concludes with Elia calling on the community to help him resurrect the Volt framework. Panelists Andrew Mason David Kimura Nate Hopkins With special guest: Elia Schito Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues My Ruby Story Links Opal WebPacker Stimulus Hyperstack Capybara CoffeeScript Devise Clearwater Reactive Volt framework Nebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated Billing Pingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his website Explaining Postmodernism Texmate

cloud stimulus javascript rails panelists reactive volt elia clearwater js devise sentry ci cd dhh github actions capybara andrew mason benjamin moore coffeescript devchattv explaining postmodernism nate hopkins webpacker

RR 430: Opal with Elia Schito

Play Episode Listen Later Sep 17, 2019 59:51

Episode Summary Today’s guest Elia Schito has been a Ruby developer for 12+ years and works for Nebulab. During his career he looked for Ruby to JavaScript translators and found Opal. The panel discusses where Opal belongs within an app and when the compilation into JavaScript occurs. The main reason a person would want to use Opal is to avoid writing in JavaScript. Elia talks about the benefits of using Opal. One is that productivity is better in a language like Ruby. Also, if you’re working on a project that needs to get done quickly, it makes sense to use Opal so that your speed is not hindered. Elia talks about testing Opal with things like WebPacker and Hyperstack, and explains what Hyperstack is. Opal recently released a newer, bigger version, and Elia talks about the features of the new release. He details what kind of JavaScript it produces and how to hook it into your CICD, how to run it locally, and overall how to use the compiler. He talks about how to debug in Opal. He notes that during the development cycle in Opal, you can refresh your page and it will compile the Ruby code into JS, so if there are any errors you will see it immediately. Opal is compatible with other tools to check your code. In the future, Elia wants to increase the coverage of the core and standard library, and believes that Opal is a great way to increase your skills in Ruby and JavaScript. He talks about the general reception of Opal among users. Opal is a perfect fit for smaller teams or older fullstack developers, especially if you don’t have a frontend team Elia notes that Opal, much like anything else, is a matter of preference, and relates it to the past reliance on CoffeeScript. For developers who refuse to write in JavaScript, Opal is an excellent option. He talks about the speed of compiling ruby to JavaScript in Opal and how it supports keeping current with Rails versions and other frameworks. The panel asks if the Opal community made any inroads with DHH for making it part of the Rails stack proper and whether Opal wants to be integrated with Rails. Elia talks about some of Opal’s contributions to the Ruby Community. Elia talks about what generally happens if you choose to use Opal in a project. Opal is small, but you will have to make some tradeoffs. You have to call your standard library from Opal, but there are many ways to overcome that. The show concludes with Elia calling on the community to help him resurrect the Volt framework. Panelists Andrew Mason David Kimura Nate Hopkins With special guest: Elia Schito Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues My Ruby Story Links Opal WebPacker Stimulus Hyperstack Capybara CoffeeScript Devise Clearwater Reactive Volt framework Nebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated Billing Pingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his website Explaining Postmodernism Texmate

cloud stimulus javascript rails panelists reactive volt elia clearwater js devise sentry ci cd dhh github actions capybara andrew mason benjamin moore coffeescript devchattv explaining postmodernism nate hopkins webpacker

RR 430: Opal with Elia Schito

Play Episode Listen Later Sep 17, 2019 59:51

Episode Summary Today’s guest Elia Schito has been a Ruby developer for 12+ years and works for Nebulab. During his career he looked for Ruby to JavaScript translators and found Opal. The panel discusses where Opal belongs within an app and when the compilation into JavaScript occurs. The main reason a person would want to use Opal is to avoid writing in JavaScript. Elia talks about the benefits of using Opal. One is that productivity is better in a language like Ruby. Also, if you’re working on a project that needs to get done quickly, it makes sense to use Opal so that your speed is not hindered. Elia talks about testing Opal with things like WebPacker and Hyperstack, and explains what Hyperstack is. Opal recently released a newer, bigger version, and Elia talks about the features of the new release. He details what kind of JavaScript it produces and how to hook it into your CICD, how to run it locally, and overall how to use the compiler. He talks about how to debug in Opal. He notes that during the development cycle in Opal, you can refresh your page and it will compile the Ruby code into JS, so if there are any errors you will see it immediately. Opal is compatible with other tools to check your code. In the future, Elia wants to increase the coverage of the core and standard library, and believes that Opal is a great way to increase your skills in Ruby and JavaScript. He talks about the general reception of Opal among users. Opal is a perfect fit for smaller teams or older fullstack developers, especially if you don’t have a frontend team Elia notes that Opal, much like anything else, is a matter of preference, and relates it to the past reliance on CoffeeScript. For developers who refuse to write in JavaScript, Opal is an excellent option. He talks about the speed of compiling ruby to JavaScript in Opal and how it supports keeping current with Rails versions and other frameworks. The panel asks if the Opal community made any inroads with DHH for making it part of the Rails stack proper and whether Opal wants to be integrated with Rails. Elia talks about some of Opal’s contributions to the Ruby Community. Elia talks about what generally happens if you choose to use Opal in a project. Opal is small, but you will have to make some tradeoffs. You have to call your standard library from Opal, but there are many ways to overcome that. The show concludes with Elia calling on the community to help him resurrect the Volt framework. Panelists Andrew Mason David Kimura Nate Hopkins With special guest: Elia Schito Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues My Ruby Story Links Opal WebPacker Stimulus Hyperstack Capybara CoffeeScript Devise Clearwater Reactive Volt framework Nebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated Billing Pingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his website Explaining Postmodernism Texmate

cloud stimulus javascript rails panelists reactive volt elia clearwater js devise sentry ci cd dhh github actions capybara andrew mason benjamin moore coffeescript devchattv explaining postmodernism nate hopkins webpacker

StimulusReflex with Nate Hopkins

Remote Ruby

Play Episode Listen Later Sep 13, 2019 42:31

After discovering StimulusReflex, we knew we had to get Nate Hopkins to join us on the podcast. Nate is working on some very cool things around the StimulusJS library and Rails. When not working on StimulusReflex, Nate is an artist, consultant, and Ruby Rogues panelist. We talked with Nate about the early days of JavaScript up to JavaScript as we know it today, as well as the motivation behind StimulusReflex.

programming coding javascript rails software development ruby on rails ruby rogues nate hopkins

RR 429: Mechanical Confidence with Adam Cuppy

Play Episode Listen Later Sep 10, 2019 72:18

Episode Summary Adam Cuppy is the cofounder and current chief operating officer at Zeal, web and mobile app consultancy. Today the panel is discussing the talk he gave at Rails Conf called Mechanically Confident. Adam has a hypothesis that confidence is not the result of belief alone but ingrained routine. The more routine, the more pattern, the more rehearsal applied to a given thing, the more confident you are with that thing The history behind Adam’s theory stems from his background in theater and performing arts. The concept of rehearsal is commonplace in the performing arts, but not other industries. He talks about where rehearsal comes in for programmers and how he has noticed the patterns of senior developers. The panelists talk about where they see routine and rehearsal come into play with their work The panelists wonder how do you avoid a stopgap from a slight change, and Adam relates it to some of the most rehearsed actors, improv actors. It’s important to rehearse everything you can, building a routine around the things you control, so that when something does happen you have everything else under control. Adam talks about different tools to help build a routine and an experiment he did with a group of interns to help them establish a routine. When the interns had a routine, in this case, a designated order in which they placed their windows, he saw immediate improvement in their performance. When the order of the windows was changed, it caused initial confusion in the group. The panel discusses the cognitive load applied to managing chaos and how a routine helps. Adam admits that routine is an individualized thing, and that chaos can be a pattern as long as you know where everything is They wonder at what point does reliance on patterns become false confidence, relating it to the strict TDD trend within the Ruby community, and how too much routine can make you rigid. Todd again ties this back to acting. The panelists discuss ways to implement a routine. Adam advises to start by finding what is it that you do consistently that creates a happy and proud result. They talk about how to create that small iterative change towards something I want to get better at. The panelists discuss the merits of visualization and if it is a tactic that developers can use to gain confidence, and what to do after you’ve visualized. They discuss whether looking ahead helps or hinders a person, and Adam talks about how to look ahead properly. The show concludes with Adam’s advice for people who would like to give a presentation or conference talk but hasn’t. He talks about how his theory has evolved since he first gave his talk. His closing thoughts are that trends matter more than individual days, how to expedite the experience timeline, and the importance of perspective. If you want to expedite learning, give the why behind something Panelists Andrew Mason David Kimura Nate Hopkins Charles Max Wood With special guest: Adam Cuppy Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Devops Links Zeal Teamocil Docker TDD Speakerline Follow DevChat on Facebook and Twitter Picks David Kimura: Belt sander PingVerse Nate Hopkins: Talent is Overrated Confreaks 10 Years: Keynote Andrew Mason: His company is hiring, contact him @andrewmcodes Charles Max Wood: Algolia RXJS Live Gitlab Commit Adam Cuppy: This Is Marketing by Seth Goden Interestings podcast Follow Adam @adamcuppy

RR 429: Mechanical Confidence with Adam Cuppy

Play Episode Listen Later Sep 10, 2019 72:18

Episode Summary Adam Cuppy is the cofounder and current chief operating officer at Zeal, web and mobile app consultancy. Today the panel is discussing the talk he gave at Rails Conf called Mechanically Confident. Adam has a hypothesis that confidence is not the result of belief alone but ingrained routine. The more routine, the more pattern, the more rehearsal applied to a given thing, the more confident you are with that thing The history behind Adam’s theory stems from his background in theater and performing arts. The concept of rehearsal is commonplace in the performing arts, but not other industries. He talks about where rehearsal comes in for programmers and how he has noticed the patterns of senior developers. The panelists talk about where they see routine and rehearsal come into play with their work The panelists wonder how do you avoid a stopgap from a slight change, and Adam relates it to some of the most rehearsed actors, improv actors. It’s important to rehearse everything you can, building a routine around the things you control, so that when something does happen you have everything else under control. Adam talks about different tools to help build a routine and an experiment he did with a group of interns to help them establish a routine. When the interns had a routine, in this case, a designated order in which they placed their windows, he saw immediate improvement in their performance. When the order of the windows was changed, it caused initial confusion in the group. The panel discusses the cognitive load applied to managing chaos and how a routine helps. Adam admits that routine is an individualized thing, and that chaos can be a pattern as long as you know where everything is They wonder at what point does reliance on patterns become false confidence, relating it to the strict TDD trend within the Ruby community, and how too much routine can make you rigid. Todd again ties this back to acting. The panelists discuss ways to implement a routine. Adam advises to start by finding what is it that you do consistently that creates a happy and proud result. They talk about how to create that small iterative change towards something I want to get better at. The panelists discuss the merits of visualization and if it is a tactic that developers can use to gain confidence, and what to do after you’ve visualized. They discuss whether looking ahead helps or hinders a person, and Adam talks about how to look ahead properly. The show concludes with Adam’s advice for people who would like to give a presentation or conference talk but hasn’t. He talks about how his theory has evolved since he first gave his talk. His closing thoughts are that trends matter more than individual days, how to expedite the experience timeline, and the importance of perspective. If you want to expedite learning, give the why behind something Panelists Andrew Mason David Kimura Nate Hopkins Charles Max Wood With special guest: Adam Cuppy Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Devops Links Zeal Teamocil Docker TDD Speakerline Follow DevChat on Facebook and Twitter Picks David Kimura: Belt sander PingVerse Nate Hopkins: Talent is Overrated Confreaks 10 Years: Keynote Andrew Mason: His company is hiring, contact him @andrewmcodes Charles Max Wood: Algolia RXJS Live Gitlab Commit Adam Cuppy: This Is Marketing by Seth Goden Interestings podcast Follow Adam @adamcuppy

confidence adventures talent cloud overrated belt zeal devops mechanical rails panelists docker sentry tdd algolia andrew mason this is marketing ryobi cuppy railsconf charles max wood seth goden devchattv nate hopkins interestings confreaks

RR 429: Mechanical Confidence with Adam Cuppy

Play Episode Listen Later Sep 10, 2019 72:18

Episode Summary Adam Cuppy is the cofounder and current chief operating officer at Zeal, web and mobile app consultancy. Today the panel is discussing the talk he gave at Rails Conf called Mechanically Confident. Adam has a hypothesis that confidence is not the result of belief alone but ingrained routine. The more routine, the more pattern, the more rehearsal applied to a given thing, the more confident you are with that thing The history behind Adam’s theory stems from his background in theater and performing arts. The concept of rehearsal is commonplace in the performing arts, but not other industries. He talks about where rehearsal comes in for programmers and how he has noticed the patterns of senior developers. The panelists talk about where they see routine and rehearsal come into play with their work The panelists wonder how do you avoid a stopgap from a slight change, and Adam relates it to some of the most rehearsed actors, improv actors. It’s important to rehearse everything you can, building a routine around the things you control, so that when something does happen you have everything else under control. Adam talks about different tools to help build a routine and an experiment he did with a group of interns to help them establish a routine. When the interns had a routine, in this case, a designated order in which they placed their windows, he saw immediate improvement in their performance. When the order of the windows was changed, it caused initial confusion in the group. The panel discusses the cognitive load applied to managing chaos and how a routine helps. Adam admits that routine is an individualized thing, and that chaos can be a pattern as long as you know where everything is They wonder at what point does reliance on patterns become false confidence, relating it to the strict TDD trend within the Ruby community, and how too much routine can make you rigid. Todd again ties this back to acting. The panelists discuss ways to implement a routine. Adam advises to start by finding what is it that you do consistently that creates a happy and proud result. They talk about how to create that small iterative change towards something I want to get better at. The panelists discuss the merits of visualization and if it is a tactic that developers can use to gain confidence, and what to do after you’ve visualized. They discuss whether looking ahead helps or hinders a person, and Adam talks about how to look ahead properly. The show concludes with Adam’s advice for people who would like to give a presentation or conference talk but hasn’t. He talks about how his theory has evolved since he first gave his talk. His closing thoughts are that trends matter more than individual days, how to expedite the experience timeline, and the importance of perspective. If you want to expedite learning, give the why behind something Panelists Andrew Mason David Kimura Nate Hopkins Charles Max Wood With special guest: Adam Cuppy Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Devops Links Zeal Teamocil Docker TDD Speakerline Follow DevChat on Facebook and Twitter Picks David Kimura: Belt sander PingVerse Nate Hopkins: Talent is Overrated Confreaks 10 Years: Keynote Andrew Mason: His company is hiring, contact him @andrewmcodes Charles Max Wood: Algolia RXJS Live Gitlab Commit Adam Cuppy: This Is Marketing by Seth Goden Interestings podcast Follow Adam @adamcuppy

RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

Play Episode Listen Later Sep 3, 2019 76:05

Sponsors Sentry use code “devchat” for $100 credit Sustain Our Software Adventures in Blockchain Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood With Special Guest: David Heinemeier Hansson Episode Summary Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers. Links Action Text Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow DevChat on Facebook and Twitter Picks Andrew Mason: How to Say It Rework episode Nate Hopkins: Stimulus Reflex Charles Max Wood: Atomic Habits Ed Mylet show The MFCEO with Andy Frisella David Kimura: Swing set kit Rails 6 His daughter Ruby David Heinemeier Hansson: Follow David on Twitter @dhh, dhh.dk and Rework.fm To Have or To Be Shape Up book Rails 6

RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

Play Episode Listen Later Sep 3, 2019 76:05

Sponsors Sentry use code “devchat” for $100 credit Sustain Our Software Adventures in Blockchain Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood With Special Guest: David Heinemeier Hansson Episode Summary Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers. Links Action Text Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow DevChat on Facebook and Twitter Picks Andrew Mason: How to Say It Rework episode Nate Hopkins: Stimulus Reflex Charles Max Wood: Atomic Habits Ed Mylet show The MFCEO with Andy Frisella David Kimura: Swing set kit Rails 6 His daughter Ruby David Heinemeier Hansson: Follow David on Twitter @dhh, dhh.dk and Rework.fm To Have or To Be Shape Up book Rails 6

RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

Play Episode Listen Later Sep 3, 2019 76:05

Sponsors Sentry use code “devchat” for $100 credit Sustain Our Software Adventures in Blockchain Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood With Special Guest: David Heinemeier Hansson Episode Summary Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers. Links Action Text Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow DevChat on Facebook and Twitter Picks Andrew Mason: How to Say It Rework episode Nate Hopkins: Stimulus Reflex Charles Max Wood: Atomic Habits Ed Mylet show The MFCEO with Andy Frisella David Kimura: Swing set kit Rails 6 His daughter Ruby David Heinemeier Hansson: Follow David on Twitter @dhh, dhh.dk and Rework.fm To Have or To Be Shape Up book Rails 6

RR 425: Rails + Webpacker with Taylor Jones

Play Episode Listen Later Aug 13, 2019 41:36

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey Taylor Jones: Slack Engineering Team Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

zoom panel react slack stimulus javascript conductor rails basecamp broccoli bootstrap sentry jquery shape up datadog heroku andrew mason taylor jones jason swett devchattv nate hopkins webpacker

RR 425: Rails + Webpacker with Taylor Jones

Play Episode Listen Later Aug 13, 2019 41:36

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey Taylor Jones: Slack Engineering Team Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

zoom panel react slack stimulus javascript conductor rails basecamp broccoli bootstrap sentry jquery shape up datadog heroku andrew mason taylor jones jason swett devchattv nate hopkins webpacker

RR 425: Rails + Webpacker with Taylor Jones

Play Episode Listen Later Aug 13, 2019 41:36

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey Taylor Jones: Slack Engineering Team Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

zoom panel react slack stimulus javascript conductor rails basecamp broccoli bootstrap sentry jquery shape up datadog heroku andrew mason taylor jones jason swett devchattv nate hopkins webpacker

RR 424: Documenting Your Code

Play Episode Listen Later Aug 6, 2019 40:04

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kumira Nate Hopkins Andrew Mason Episode Summary Today the panel is talking about documentation. They begin by discussing what documentation is, where it fits within an application, and if the code documents itself. They agree that documentation starts in the comments to explain what you’re doing, but if that’s your exclusive method, then a refactor is in order. They talk about where to start with documentation and different ways they’ve done it. The panel talks about the importance of documentation, especially for people just joining a team. In addition to documenting the project itself, it is important to document what different libraries do and how to interact with them. They discuss where to put this kind of documentation. They talk about documenting patterns, best practices, and procedures in addition to the ‘how to’ of a project. The conversation turns to style guidelines, what they are, and how to keep them up to date. They talk about what tools are available to generate documentation that are close to the code but outside of it that can help keep documentation up to date. The panel believes that there is a relationship between the size of your team and the necessity to document. Nate introduces the idea found in the article by Tom Preston-Werner that you should think about what you’re going to create in the code, and document it first. Links RDoc YARD RuboCop YAML Slim ERB Prettier Pronto Api.rubyonrails.org Swagger Thoughtbot and Thoughtbot Playbook AirBNB Ruby Testdouble HoundCI Okonet API Blueprint Ruby on Rails API documentation guidelines Tom Preston-Werner article Readme Driven Development Follow DevChat on Facebook and Twitter Picks Nate Hopkins: Code Fund Andrew Mason: SpaceVIM RailsDiff Rails Releases David Kimura: Jackery Supercharger Portable

code panel yards api slim pronto documenting swagger sentry datadog erb prettier yaml andrew mason thoughtbot devchattv nate hopkins rdoc

RR 424: Documenting Your Code

Play Episode Listen Later Aug 6, 2019 40:04

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kumira Nate Hopkins Andrew Mason Episode Summary Today the panel is talking about documentation. They begin by discussing what documentation is, where it fits within an application, and if the code documents itself. They agree that documentation starts in the comments to explain what you’re doing, but if that’s your exclusive method, then a refactor is in order. They talk about where to start with documentation and different ways they’ve done it. The panel talks about the importance of documentation, especially for people just joining a team. In addition to documenting the project itself, it is important to document what different libraries do and how to interact with them. They discuss where to put this kind of documentation. They talk about documenting patterns, best practices, and procedures in addition to the ‘how to’ of a project. The conversation turns to style guidelines, what they are, and how to keep them up to date. They talk about what tools are available to generate documentation that are close to the code but outside of it that can help keep documentation up to date. The panel believes that there is a relationship between the size of your team and the necessity to document. Nate introduces the idea found in the article by Tom Preston-Werner that you should think about what you’re going to create in the code, and document it first. Links RDoc YARD RuboCop YAML Slim ERB Prettier Pronto Api.rubyonrails.org Swagger Thoughtbot and Thoughtbot Playbook AirBNB Ruby Testdouble HoundCI Okonet API Blueprint Ruby on Rails API documentation guidelines Tom Preston-Werner article Readme Driven Development Follow DevChat on Facebook and Twitter Picks Nate Hopkins: Code Fund Andrew Mason: SpaceVIM RailsDiff Rails Releases David Kimura: Jackery Supercharger Portable

code panel yards api slim pronto documenting swagger sentry ruby on rails datadog erb prettier yaml andrew mason thoughtbot devchattv nate hopkins rdoc rails api

RR 424: Documenting Your Code