Podcast appearances and mentions of Cory House

  • 20PODCASTS
  • 100EPISODES
  • 53mAVG DURATION
  • ?INFREQUENT EPISODES
  • Sep 18, 2024LATEST

POPULARITY

20172018201920202021202220232024


Best podcasts about Cory House

Latest podcast episodes about Cory House

PodRocket - A web development podcast from LogRocket
Custom DevTools for your React App with Cory House

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Sep 18, 2024 32:32


React and JavaScript expert Cory House discusses the creation of custom development tools for React applications, sharing insights from his recent talk at React Rally and exploring how the right tools can shape development workflows and enhance automated testing strategies. Links https://www.bitnative.com https://github.com/coryhouse/ama https://x.com/housecor https://github.com/coryhouse https://stackoverflow.com/users/26180/cory-house https://www.linkedin.com/in/coryhouse https://www.pluralsight.com/authors/cory-house https://www.reactjsconsulting.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Cory House.

Test Automation Experience
Master React Development: Cory House

Test Automation Experience

Play Episode Listen Later Jun 14, 2024 43:42


Is it possible to prioritize quality AND speed? In this episode, we dive into the importance of personal responsibility in software development. Cory House, a seasoned React and JavaScript consultant, shares how to balance speed and quality, manage relationship dynamics within teams, and advocate for quality code. Cory also offers technical advice for web development. He discusses common developer mistakes in React, TypeScript's benefits and trade-offs, automated tools to manage code quality, and strategies for transitioning to modern JavaScript frameworks.❓What did you think of the show? Leave your anonymous feedback:https://forms.gle/Df5sDABiNMQn4YSj7 CONNECT WITH CORY HOUSE

PodRocket - A web development podcast from LogRocket
PHP, web components, and reusable components

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Sep 22, 2023 12:15


In this week's roundup, we talk about why PHP doesn't suck, when to use web components, and the trade-offs of using reusable components. Links Apple PHP doesn't suck (anymore) with Aaron Francis: https://apple.co/3PITVrH What web components are good at with Nolan Lawson: https://apple.co/3LLBOzl Creating reusable components with Cory House: https://apple.co/3sYO20A Spotify PHP doesn't suck (anymore) with Aaron Francis: https://spoti.fi/46kaWhF What web components are good at with Nolan Lawson: https://spoti.fi/3PgTZ0I Creating reusable components with Cory House: https://spoti.fi/44SLM8u Google PHP doesn't suck (anymore) with Aaron Francis: https://bit.ly/48ngIk6 What web components are good at with Nolan Lawson: https://bit.ly/3PezxgV Creating reusable components with Cory House: https://bit.ly/45M0WxO Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guests: Aaron Francis, Cory House, and Nolan Lawson.

PodRocket - A web development podcast from LogRocket
Creating reusable components with Cory House

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Sep 12, 2023 48:30


Want to know how to create a reusable component you can actually reuse? Cory House, founder and principal consultant at reactjsconsulting.com, comes on to talk about how to create reusable components, and how to create effective design systems and reusable component libraries. Links https://twitter.com/housecor https://www.bitnative.com https://www.linkedin.com/in/coryhouse https://www.reactjsconsulting.com https://www.pluralsight.com/authors/cory-house https://github.com/coryhouse https://stackoverflow.com/users/26180/cory-house https://www.youtube.com/watch?v=r7YstJ5eF8g&ab_channel=CoryHouse Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Cory House.

Maintainable
Cory House - Finding Opportunities for Improvement

Maintainable

Play Episode Listen Later Jun 5, 2023 35:27


Robby has a chat with Cory House (he/him/his), the Founder at Reactjsconsulting.com, a software developer, author, speaker, and consultant. “I love the old saying that we write software for humans. So, I think about that regularly”, Cory says about what the maintainability of software is all about. When it comes down to it, he thinks more about his fellow developers than the compiler. He talks about the importance of good variable naming, shares the tactics for writing good tests for your regular expressions, and lists the benefits of automating pull-request feedback on potentially subjective feedback so that we can focus our attention on objective curiosities. He will also dive into testing strategies for React JS applications, how granular unit testing patterns don't apply well to automated browser tests, why it's valuable to keep a running list of opportunities for improvements rather than a list of technical debt, and why he believes that not every software project requires a dedicated architect but there should be someone who is acting in that role. You're going to love this one so stay tuned!Book Recommendations:So Good They Can't Ignore You By Cal NewportHelpful Links:Pluralsight coursesCory on LinkedInCory on TwitterWebsiteReactJS ConsultingSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Odd Trails
Episode 71: The Spider Woman

Odd Trails

Play Episode Listen Later Apr 10, 2023 58:35


Stories in this episode: - Haunted Ranch or Hallucination, by Kat - Doppelganger Mom, by Lia - The Time I Saw Sasquatch, by Cory - House on the Border Between Worlds, by Anji - The Spider Woman, by Elizabeth - My Friend Ford, by Skyler Submissions: stories@oddtrails.com Listen ad-free and support the show for only $5 a month by signing up for our Patreon! You'll also hear episodes at a crystal clear 320 kbps. Head over to patreon.com/oddtrails. Connect with us on Instagram @oddtrailspodcast or on the Cryptic County Facebook group: https://www.facebook.com/groups/433173970399259 Check out the other Cryptic County podcasts like Let's Not Meet: A True Horror Podcast and the Old Time Radiocast at CrypticCountyPodcasts.com or wherever you get your podcasts! Get a 4-week trial, free postage, and a digital scale at https://www.stamps.com. Click the microphone at the top of the page, and enter code TRAILS. Thanks to Stamps.com for sponsoring the show! Go to HelloFresh.com/trails50 and use code trails50 for 50% off, plus your first box ships free! Upgrade your sleep with Miracle Made! Go to TryMiracle.com/TRAILS and use the code TRAILS to claim your free 3-piece towel set and save over 40% off. All stories were narrated and produced with the permission of their respective authors. - Spotify: https://open.spotify.com/show/1n7wNZGJJ3Oc31O4TYx4x3 - Apple Podcasts: https://podcasts.apple.com/us/podcast/feed/id1598762965

Modern Web
S09E24- React: Past, Present, & Future with Cory House

Modern Web

Play Episode Listen Later Dec 28, 2022 44:33


In this episode, Rob Ocel and Jesse Tomchak are joined by Cory House at Connect Tech 2022 to discuss the past, present, and future of React. They talk about: lessons learned from 7 years of React (featuring discussions of coupling, testing, and hooks), how to pick a React meta-framework, and what pillars they think successful developers should prioritize.   Hosts Rob Ocel- Software Architect and Team Lead at This Dot Labs Jesse Tomchak- Software Architect at This Dot Labs   Guest Cory House- Founder of ReactJS Consulting   Sponsored by This Dot Labs

The Stack Overflow Podcast
Faster feedback loops make for faster developer velocity

The Stack Overflow Podcast

Play Episode Listen Later Oct 19, 2022 28:54


Having trouble with understanding your team's productivity outside of frameworks and tooling? Create a backlog and work through it: Instant Agile! How much of that backlog you work through is a good baseline measure. The Stack Overflow blog recently featured an article from Stack Overflow's Director of Engineering, Ben Matthews: Does high velocity lead to burnout? That may be the wrong question to askIf you're interested in seeing how Couchbase's SQL database solutions can help improve your team's velocity, check out Capella.  Cory House helps teams deliver successful React projects through his consulting business, ReactJS Consulting.  If you want to learn more about Matt, check out his LinkedIn.Congrats to Lifeboat badge winner, Alohci, who threw a great answer to rescue the question, Display button with  inline CSS.

All Hands on Tech
008 - Why you should (or shouldn't) use React with Cory House

All Hands on Tech

Play Episode Listen Later Dec 24, 2019 52:04


React is really popular, but is it the right choice for your team? Pluralsight author Cory House tackled this topic in a recent webinar which we’re sharing via this episode. Cory dives into the many upsides, and some of the downsides, that you should weigh when considering React. Full webinar link Create React App Cory's Puralsight courses @housecor on Twitter *** If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen. Please send any questions or comments to podcast@pluralsight.com.

The freeCodeCamp Podcast
Ep. 59: Shawn Wang left a $350K/year finance job to learn to code

The freeCodeCamp Podcast

Play Episode Listen Later Apr 15, 2019 126:41


On this week's episode of the freeCodeCamp podcast, Quincy interviews Shawn Wang (@swyx). We talk about "learning in public" and his transition into tech from finance, where he left behind a job that paid him US $350,000 per year. Shawn grew up in Singapore and came to the US as a college student. He worked in finance, but at age 30, he burned out. So he decided to learn to code. He used freeCodeCamp and a ton of other resources, and since then he's worked as a freelance developer, and at several companies including Netlify. Follow Shawn on Twitter: https://twitter.com/swyx Follow Quincy on Twitter: https://twitter.com/ossia Here are some links we discuss in the interview. Shawn's Projects: The official React subreddit that Shawn moderates: https://reddit.com/r/reactjs Shawn's article on No Zero Days: https://www.freecodecamp.org/forum/t/no-zero-days-my-roadmap-from-javascript-noob-to-full-stack-developer-in-12-months/164514 Job Search / Salary Negotation articles: Cracking the Coding Interview: https://fcc.im/2UihbNm Hasseeb Qureshi's story of getting a $250K/y developer job at Airbnb: https://haseebq.com/farewell-app-academy-hello-airbnb-part-i Steve Yegge's "Get that job at Google" essay: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html Patrick McKenzie on Salary Negotiation https://www.kalzumeus.com/2012/01/23/salary-negotiation/ Quincy's recommended article: I spent 3 months applying to jobs after a coding bootcamp. Here's what I learned: https://medium.freecodecamp.org/9a07468d2331 Algorithm Expert: https://www.algoexpert.io Full Stack Academy https://www.fullstackacademy.com Shawn's Learn In Public movement: Shawn's Learn In Public essay https://gist.github.com/sw-yx/9720bd4a30606ca3ffb8d407113c0fe5‌‌ Kent C Dodds' Zero to 60 in Software Development: How to Jumpstart Your Career https://www.youtube.com/watch?v=-qPh6I2hfjw&app=desktop‌‌ Cory House on Becoming an Outlier: https://vimeo.com/97415346‌‌ Brad Frost on Creative Exhaust: http://bradfrost.com/blog/post/creative-exhaust/‌‌ Patrick McKenzie on the origin of the word "friendcatcher": https://news.ycombinator.com/item?id=511089‌‌ Chris Coyier on "Working In Public": https://chriscoyier.net/2012/09/23/working-in-public/ Links to other things we discuss: Shawn's Software Engineering Daily Interview with Sacha Greif: https://softwareengineeringdaily.com/2017/08/09/state-of-javascript-with-sacha-greif/‌‌ The origin of No Zero Days: https://www.reddit.com/r/getdisciplined/comments/1q96b5/i_just_dont_care_about_myself/cdah4af/‌‌ John Resig, creator of jQuery, telling his team to rip out jQuery: http://bikeshed.fm/180 ‌‌Jeff Bezos' Two Pizza Team rule: https://buffer.com/resources/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done‌‌ Shawn's "You can learn so much on the internet for the low, low price of your ego" quote draws from Paul Graham's Keep Your Identity Small: http://paulgraham.com/identity.html‌‌ Shawn's Impostor Syndrome Bootcamp Podcast: https://player.fm/series/impostor-syndrome‌‌ TypeScript's growth via npm surveys: https://mobile.twitter.com/seldo/status/1088240877107965953

.NET Rocks!
GraphQL with Cory House

.NET Rocks!

Play Episode Listen Later Jul 26, 2018 57:36


GraphQL continues to evolve - should it be in your toolbox? Carl and Richard talk to Cory House about how he's been working with GraphQL. Cory talks about how he appreciates the lack of ceremony around GraphQL and it's strengths in dealing with a diversity of clients and bandwidth availability. Comparisons with oData are inevitable, and the jury is kind of out on it - both technologies are viable. GraphQL has a great ecosystem growing up around it, and is well worth a look if you need web-callable APIs!Support this podcast at — https://redcircle.com/net-rocks/donations

.NET Rocks!
GraphQL with Cory House

.NET Rocks!

Play Episode Listen Later Jul 26, 2018 57:35


GraphQL continues to evolve - should it be in your toolbox? Carl and Richard talk to Cory House about how he's been working with GraphQL. Cory talks about how he appreciates the lack of ceremony around GraphQL and it's strengths in dealing with a diversity of clients and bandwidth availability. Comparisons with oData are inevitable, and the jury is kind of out on it - both technologies are viable. GraphQL has a great ecosystem growing up around it, and is well worth a look if you need web-callable APIs!Support this podcast at — https://redcircle.com/net-rocks/donations

React Round Up
RRU 011: Simple React Patterns with Lucas Reis

React Round Up

Play Episode Listen Later May 15, 2018 60:56


Panel: Charles Max Wood Cory House Special Guests: Lucas Reis In this episode of React Round Up, the panel discusses simple React patterns with Lucas Reis. Lucas works as a senior front-end developer at Zocdoc and previously worked in Brazil for an ecommerce company called B2W. He recently wrote a blog post about simple React patterns that really took off and became popular on the web. They talk about this blog post, what defines a successful pattern, and then they discuss the different patterns that he has discovered in his years of React programming. In particular, we dive pretty deep on: Lucas intro Tries to write blog posts as much as possible Simple React Patterns blog post React What does he mean by “successful” patterns? Three things that define good patterns Define successful? The mix component The Container/Branch/View pattern First successful pattern he has found Separation of concerns Common concern: are we worried about mixing concerns? If/else Can you encapsulate in the view? Pattern matching React loadable You need to think of 3 states at least Higher-order component Render props And much, much more! Links: Zocdoc B2W Simple React Patterns blog post React Simple Made Easy by Rich Hickey Lucas’s GitHub Lucas’s Blog @iamlucasreis Picks: Charles FullContact Udemy Cory Fluent conf Immer Lucas Percy Be studying the languages and be inspired!

Devchat.tv Master Feed
RRU 011: Simple React Patterns with Lucas Reis

Devchat.tv Master Feed

Play Episode Listen Later May 15, 2018 60:56


Panel: Charles Max Wood Cory House Special Guests: Lucas Reis In this episode of React Round Up, the panel discusses simple React patterns with Lucas Reis. Lucas works as a senior front-end developer at Zocdoc and previously worked in Brazil for an ecommerce company called B2W. He recently wrote a blog post about simple React patterns that really took off and became popular on the web. They talk about this blog post, what defines a successful pattern, and then they discuss the different patterns that he has discovered in his years of React programming. In particular, we dive pretty deep on: Lucas intro Tries to write blog posts as much as possible Simple React Patterns blog post React What does he mean by “successful” patterns? Three things that define good patterns Define successful? The mix component The Container/Branch/View pattern First successful pattern he has found Separation of concerns Common concern: are we worried about mixing concerns? If/else Can you encapsulate in the view? Pattern matching React loadable You need to think of 3 states at least Higher-order component Render props And much, much more! Links: Zocdoc B2W Simple React Patterns blog post React Simple Made Easy by Rich Hickey Lucas’s GitHub Lucas’s Blog @iamlucasreis Picks: Charles FullContact Udemy Cory Fluent conf Immer Lucas Percy Be studying the languages and be inspired!

React Round Up
RRU 010: Best Practices with React and Redux with Samuel Mendenhall

React Round Up

Play Episode Listen Later May 8, 2018 51:15


Panel: Cory House Nader Dabit Special Guests: Samuel Mendenhall In this episode of React Round Up, the panel discusses best practices with React and Redux with Samuel Mendenhall. Samuel has been working in web development for the past five years and was recently working for Red Hat. They talk about what has led him to React, as well as some of the most common mistakes that people make in React. They also talk about the amazing power of TypeScript and when you may not want to use Redux. In particular, we dive pretty deep on: Sam intro jQuery, Backbone, and Angular React and React Native New role at Microsoft in commercial software engineering group Working a lot with React and tooling What have you learned since working with React? Shallow learning curve The concept of React is very simple What work did you do at Red Hat? Internal tooling What are some common mistakes people have made in React? Defensive programming Making sure functions are bound correctly He’s an advocate for using TypeScript The pros of using TypeScript Connect in React Connect will do shallow comparisons Redux When you shouldn’t use Redux When should Redux be used in a project? MobX And much, much more! Links: jQuery Backbone Angular React Red Hat React Native TypeScript Redux MobX @engineersamwell Sam’s GitHub Picks: Cory Transform.now.sh Plop js Nader React Amsterdam YouTube AWS AppSync AWS Amplify Sam Webpack

Devchat.tv Master Feed
RRU 010: Best Practices with React and Redux with Samuel Mendenhall

Devchat.tv Master Feed

Play Episode Listen Later May 8, 2018 51:15


Panel: Cory House Nader Dabit Special Guests: Samuel Mendenhall In this episode of React Round Up, the panel discusses best practices with React and Redux with Samuel Mendenhall. Samuel has been working in web development for the past five years and was recently working for Red Hat. They talk about what has led him to React, as well as some of the most common mistakes that people make in React. They also talk about the amazing power of TypeScript and when you may not want to use Redux. In particular, we dive pretty deep on: Sam intro jQuery, Backbone, and Angular React and React Native New role at Microsoft in commercial software engineering group Working a lot with React and tooling What have you learned since working with React? Shallow learning curve The concept of React is very simple What work did you do at Red Hat? Internal tooling What are some common mistakes people have made in React? Defensive programming Making sure functions are bound correctly He’s an advocate for using TypeScript The pros of using TypeScript Connect in React Connect will do shallow comparisons Redux When you shouldn’t use Redux When should Redux be used in a project? MobX And much, much more! Links: jQuery Backbone Angular React Red Hat React Native TypeScript Redux MobX @engineersamwell Sam’s GitHub Picks: Cory Transform.now.sh Plop js Nader React Amsterdam YouTube AWS AppSync AWS Amplify Sam Webpack

Devchat.tv Master Feed
JSJ 310: Thwarting Insider Threats with Greg Kushto

Devchat.tv Master Feed

Play Episode Listen Later Apr 24, 2018 45:59


Panel: Charles Max Wood Cory House AJ O’Neal Aimee Knight Special Guests: Greg Kushto In this episode, the JavaScript Jabber panelists discuss thwarting insider threats with Greg Kushto. Greg is the vice president of sales engineering for Force 3 and has been focused on computer security for the last 25 years. They discuss what insider threats are, what the term includes, and give examples of what insider threats look like. They also touch on some overarching principles that companies can use to help prevent insider threats from occurring. In particular, we dive pretty deep on: Greg intro Insider threats are a passion of his Most computer attacks come from the inside of the company Insider threats have changed over time What does the term “insider threats” include? Using data in an irresponsible manner Who’s fault is it? Blame the company or blame the employee? Need to understand that insider threats don’t always happen on purpose How to prevent insider threats Very broad term Are there some general principles to implement? Figure out what exactly you are doing and documenting it Documentations doesn’t have to be a punishment Know what data you have and what you need to do to protect it How easy it is to get hacked Practical things to keep people from clicking on curious links The need to change the game Fighting insider threats isn’t fun, but it is necessary And much, much more! Links: Force 3 Greg’s LinkedIn @Greg_Kushto Greg’s BLog Picks: Charles HaveIBeenPwned.com Plural Sight Elixir podcast coming soon NG conf MicroConf RubyHack Microsoft Build Cory Plop VS code sync plugin Aimee Awesome Proposals GitHub AJ O’Neal Fluffy Pancakes The Mind and the Brain by Jeffrey M. Schwartz Greg StormCast

JavaScript Jabber
JSJ 310: Thwarting Insider Threats with Greg Kushto

JavaScript Jabber

Play Episode Listen Later Apr 24, 2018 45:59


Panel: Charles Max Wood Cory House AJ O’Neal Aimee Knight Special Guests: Greg Kushto In this episode, the JavaScript Jabber panelists discuss thwarting insider threats with Greg Kushto. Greg is the vice president of sales engineering for Force 3 and has been focused on computer security for the last 25 years. They discuss what insider threats are, what the term includes, and give examples of what insider threats look like. They also touch on some overarching principles that companies can use to help prevent insider threats from occurring. In particular, we dive pretty deep on: Greg intro Insider threats are a passion of his Most computer attacks come from the inside of the company Insider threats have changed over time What does the term “insider threats” include? Using data in an irresponsible manner Who’s fault is it? Blame the company or blame the employee? Need to understand that insider threats don’t always happen on purpose How to prevent insider threats Very broad term Are there some general principles to implement? Figure out what exactly you are doing and documenting it Documentations doesn’t have to be a punishment Know what data you have and what you need to do to protect it How easy it is to get hacked Practical things to keep people from clicking on curious links The need to change the game Fighting insider threats isn’t fun, but it is necessary And much, much more! Links: Force 3 Greg’s LinkedIn @Greg_Kushto Greg’s BLog Picks: Charles HaveIBeenPwned.com Plural Sight Elixir podcast coming soon NG conf MicroConf RubyHack Microsoft Build Cory Plop VS code sync plugin Aimee Awesome Proposals GitHub AJ O’Neal Fluffy Pancakes The Mind and the Brain by Jeffrey M. Schwartz Greg StormCast

All JavaScript Podcasts by Devchat.tv
JSJ 310: Thwarting Insider Threats with Greg Kushto

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Apr 24, 2018 45:59


Panel: Charles Max Wood Cory House AJ O’Neal Aimee Knight Special Guests: Greg Kushto In this episode, the JavaScript Jabber panelists discuss thwarting insider threats with Greg Kushto. Greg is the vice president of sales engineering for Force 3 and has been focused on computer security for the last 25 years. They discuss what insider threats are, what the term includes, and give examples of what insider threats look like. They also touch on some overarching principles that companies can use to help prevent insider threats from occurring. In particular, we dive pretty deep on: Greg intro Insider threats are a passion of his Most computer attacks come from the inside of the company Insider threats have changed over time What does the term “insider threats” include? Using data in an irresponsible manner Who’s fault is it? Blame the company or blame the employee? Need to understand that insider threats don’t always happen on purpose How to prevent insider threats Very broad term Are there some general principles to implement? Figure out what exactly you are doing and documenting it Documentations doesn’t have to be a punishment Know what data you have and what you need to do to protect it How easy it is to get hacked Practical things to keep people from clicking on curious links The need to change the game Fighting insider threats isn’t fun, but it is necessary And much, much more! Links: Force 3 Greg’s LinkedIn @Greg_Kushto Greg’s BLog Picks: Charles HaveIBeenPwned.com Plural Sight Elixir podcast coming soon NG conf MicroConf RubyHack Microsoft Build Cory Plop VS code sync plugin Aimee Awesome Proposals GitHub AJ O’Neal Fluffy Pancakes The Mind and the Brain by Jeffrey M. Schwartz Greg StormCast

JavaScript Jabber
JSJ 309: WebAssembly and JavaScript with Ben Titzer

JavaScript Jabber

Play Episode Listen Later Apr 17, 2018 52:21


Panel: Charles Max Wood Cory House Aimee Knight Special Guests: Ben Titzer In this episode, the JavaScript Jabber panelists discuss WebAssembly and JavaScript with Ben Titzer. Ben is a JavaScript VM engineer and is on the V8 team at Google. He was one of the co-inventors of WebAssembly and he now works on VM engineering as well as other things for WebAssembly. They talk about how WebAssembly came to be and when it would be of most benefit to you in your own code. In particular, we dive pretty deep on: Ben intro JavaScript Co-inventor of WebAssembly (Wasm) Joined V8 in 2014 asm.js Built a JIT compiler to make asm.js faster TurboFan What is the role of JavaScript? What is the role of WebAssembly? SIMD.js JavaScript is not a statically typed language Adding SIMD to Wasm was easier Easy to add things to Wasm Will JavaScript benefit? Using JavaScript with Wasm pros and cons Pros to compiling with Wasm Statically typed languages The more statically typed you are, the more you will benefit from Wasm TypeScript Is WebAssembly headed towards being used in daily application? Rust is investing heavily in Wasm WebAssembly in gaming And much, much more! Links: JavaScript V8 WebAssembly asm.js TurboFan TypeScript Rust WebAssembly GitHub Ben’s GitHub Picks: Charles Ready Player One Movie DevChat.tv YouTube Alexa Flash Briefings: Add skill for “JavaScript Rants” Cory npm Semantic Version Calculator Kent Beck Tweet Aimee MDN 418 Status code Quantity Always Trumps Quality blog post Ben American Politics

All JavaScript Podcasts by Devchat.tv
JSJ 309: WebAssembly and JavaScript with Ben Titzer

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Apr 17, 2018 52:21


Panel: Charles Max Wood Cory House Aimee Knight Special Guests: Ben Titzer In this episode, the JavaScript Jabber panelists discuss WebAssembly and JavaScript with Ben Titzer. Ben is a JavaScript VM engineer and is on the V8 team at Google. He was one of the co-inventors of WebAssembly and he now works on VM engineering as well as other things for WebAssembly. They talk about how WebAssembly came to be and when it would be of most benefit to you in your own code. In particular, we dive pretty deep on: Ben intro JavaScript Co-inventor of WebAssembly (Wasm) Joined V8 in 2014 asm.js Built a JIT compiler to make asm.js faster TurboFan What is the role of JavaScript? What is the role of WebAssembly? SIMD.js JavaScript is not a statically typed language Adding SIMD to Wasm was easier Easy to add things to Wasm Will JavaScript benefit? Using JavaScript with Wasm pros and cons Pros to compiling with Wasm Statically typed languages The more statically typed you are, the more you will benefit from Wasm TypeScript Is WebAssembly headed towards being used in daily application? Rust is investing heavily in Wasm WebAssembly in gaming And much, much more! Links: JavaScript V8 WebAssembly asm.js TurboFan TypeScript Rust WebAssembly GitHub Ben’s GitHub Picks: Charles Ready Player One Movie DevChat.tv YouTube Alexa Flash Briefings: Add skill for “JavaScript Rants” Cory npm Semantic Version Calculator Kent Beck Tweet Aimee MDN 418 Status code Quantity Always Trumps Quality blog post Ben American Politics

All JavaScript Podcasts by Devchat.tv
JSJ 309: WebAssembly and JavaScript with Ben Titzer

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Apr 17, 2018 52:21


Panel: Charles Max Wood Cory House Aimee Knight Special Guests: Ben Titzer In this episode, the JavaScript Jabber panelists discuss WebAssembly and JavaScript with Ben Titzer. Ben is a JavaScript VM engineer and is on the V8 team at Google. He was one of the co-inventors of WebAssembly and he now works on VM engineering as well as other things for WebAssembly. They talk about how WebAssembly came to be and when it would be of most benefit to you in your own code. In particular, we dive pretty deep on: Ben intro JavaScript Co-inventor of WebAssembly (Wasm) Joined V8 in 2014 asm.js Built a JIT compiler to make asm.js faster TurboFan What is the role of JavaScript? What is the role of WebAssembly? SIMD.js JavaScript is not a statically typed language Adding SIMD to Wasm was easier Easy to add things to Wasm Will JavaScript benefit? Using JavaScript with Wasm pros and cons Pros to compiling with Wasm Statically typed languages The more statically typed you are, the more you will benefit from Wasm TypeScript Is WebAssembly headed towards being used in daily application? Rust is investing heavily in Wasm WebAssembly in gaming And much, much more! Links: JavaScript V8 WebAssembly asm.js TurboFan TypeScript Rust WebAssembly GitHub Ben’s GitHub Picks: Charles Ready Player One Movie DevChat.tv YouTube Alexa Flash Briefings: Add skill for “JavaScript Rants” Cory npm Semantic Version Calculator Kent Beck Tweet Aimee MDN 418 Status code Quantity Always Trumps Quality blog post Ben American Politics

Devchat.tv Master Feed
RRU 007: Breaking up with Higher Order Components with David Atchley

Devchat.tv Master Feed

Play Episode Listen Later Apr 17, 2018 68:24


Panel: Charles Max Wood Nader Dabit Cory House Kent C Dodds Special Guests: David Atchley In this episode of React Round Up, the panel discuss breaking up with higher-order components with David Atchley. David has been doing software development for 24 years now and has worked mostly in web development. He has worked at many places from start-ups to large companies and does client work currently for Tandem.ly. They talk about what higher-order components and render props are and when you would want to use them to help you in your code. They also touch on overuse and misuse of applications and coding tools and the difference between using render props and HOCs. In particular, we dive pretty deep on: David intro What are higher-order components? What are render props? Higher-order components are patterned after higher-order functions Connect from React Redux React What are the use cases for higher-order components? Redux Would you suggest writing a render prop instead in certain situations? Deciding to use a HOC or a render prop depends on the situation Think critically about the applications you are using Kent’s Advanced React Component Patterns Egghead Course Difference between render props and HOCs Build an HOC out of a render prop if you want to share code Context API from React Concern with new Context API Problem with overuse How do you help people avoid overuse and misuse? Unstated library by James Kyle Start developing code at the local level React Native And much, much more! Links: Tandem.ly React Redux Kent’s Egghead Course Context API from React Unstated library by James Kyle React Native David’s GitHub @Tuxz0r Tandem.ly Medium Picks: Charles I’d Pay You $500,000 a Year, but You Can’t Do the Work by Shelly Palmer Liars by Glenn Beck Cory CodeSandbox Live Babel repl React Cheat Sheet Fluent Conf Nader Shoe Dog by Phil Knight Nader’s Blog Post Kent Answers to common questions about render props blog post React’s new Context API blog post React Composer Brandon Sanderson CodeSandbox Live David React, Inline Functions, and Performance by Ryan Florence Build Better Products by Laura Klein

Devchat.tv Master Feed
JSJ 309: WebAssembly and JavaScript with Ben Titzer

Devchat.tv Master Feed

Play Episode Listen Later Apr 17, 2018 52:21


Panel: Charles Max Wood Cory House Aimee Knight Special Guests: Ben Titzer In this episode, the JavaScript Jabber panelists discuss WebAssembly and JavaScript with Ben Titzer. Ben is a JavaScript VM engineer and is on the V8 team at Google. He was one of the co-inventors of WebAssembly and he now works on VM engineering as well as other things for WebAssembly. They talk about how WebAssembly came to be and when it would be of most benefit to you in your own code. In particular, we dive pretty deep on: Ben intro JavaScript Co-inventor of WebAssembly (Wasm) Joined V8 in 2014 asm.js Built a JIT compiler to make asm.js faster TurboFan What is the role of JavaScript? What is the role of WebAssembly? SIMD.js JavaScript is not a statically typed language Adding SIMD to Wasm was easier Easy to add things to Wasm Will JavaScript benefit? Using JavaScript with Wasm pros and cons Pros to compiling with Wasm Statically typed languages The more statically typed you are, the more you will benefit from Wasm TypeScript Is WebAssembly headed towards being used in daily application? Rust is investing heavily in Wasm WebAssembly in gaming And much, much more! Links: JavaScript V8 WebAssembly asm.js TurboFan TypeScript Rust WebAssembly GitHub Ben’s GitHub Picks: Charles Ready Player One Movie DevChat.tv YouTube Alexa Flash Briefings: Add skill for “JavaScript Rants” Cory npm Semantic Version Calculator Kent Beck Tweet Aimee MDN 418 Status code Quantity Always Trumps Quality blog post Ben American Politics

Devchat.tv Master Feed
JSJ 309: WebAssembly and JavaScript with Ben Titzer

Devchat.tv Master Feed

Play Episode Listen Later Apr 17, 2018 52:21


Panel: Charles Max Wood Cory House Aimee Knight Special Guests: Ben Titzer In this episode, the JavaScript Jabber panelists discuss WebAssembly and JavaScript with Ben Titzer. Ben is a JavaScript VM engineer and is on the V8 team at Google. He was one of the co-inventors of WebAssembly and he now works on VM engineering as well as other things for WebAssembly. They talk about how WebAssembly came to be and when it would be of most benefit to you in your own code. In particular, we dive pretty deep on: Ben intro JavaScript Co-inventor of WebAssembly (Wasm) Joined V8 in 2014 asm.js Built a JIT compiler to make asm.js faster TurboFan What is the role of JavaScript? What is the role of WebAssembly? SIMD.js JavaScript is not a statically typed language Adding SIMD to Wasm was easier Easy to add things to Wasm Will JavaScript benefit? Using JavaScript with Wasm pros and cons Pros to compiling with Wasm Statically typed languages The more statically typed you are, the more you will benefit from Wasm TypeScript Is WebAssembly headed towards being used in daily application? Rust is investing heavily in Wasm WebAssembly in gaming And much, much more! Links: JavaScript V8 WebAssembly asm.js TurboFan TypeScript Rust WebAssembly GitHub Ben’s GitHub Picks: Charles Ready Player One Movie DevChat.tv YouTube Alexa Flash Briefings: Add skill for “JavaScript Rants” Cory npm Semantic Version Calculator Kent Beck Tweet Aimee MDN 418 Status code Quantity Always Trumps Quality blog post Ben American Politics

React Round Up
RRU 007: Breaking up with Higher Order Components with David Atchley

React Round Up

Play Episode Listen Later Apr 17, 2018 68:24


Panel: Charles Max Wood Nader Dabit Cory House Kent C Dodds Special Guests: David Atchley In this episode of React Round Up, the panel discuss breaking up with higher-order components with David Atchley. David has been doing software development for 24 years now and has worked mostly in web development. He has worked at many places from start-ups to large companies and does client work currently for Tandem.ly. They talk about what higher-order components and render props are and when you would want to use them to help you in your code. They also touch on overuse and misuse of applications and coding tools and the difference between using render props and HOCs. In particular, we dive pretty deep on: David intro What are higher-order components? What are render props? Higher-order components are patterned after higher-order functions Connect from React Redux React What are the use cases for higher-order components? Redux Would you suggest writing a render prop instead in certain situations? Deciding to use a HOC or a render prop depends on the situation Think critically about the applications you are using Kent’s Advanced React Component Patterns Egghead Course Difference between render props and HOCs Build an HOC out of a render prop if you want to share code Context API from React Concern with new Context API Problem with overuse How do you help people avoid overuse and misuse? Unstated library by James Kyle Start developing code at the local level React Native And much, much more! Links: Tandem.ly React Redux Kent’s Egghead Course Context API from React Unstated library by James Kyle React Native David’s GitHub @Tuxz0r Tandem.ly Medium Picks: Charles I’d Pay You $500,000 a Year, but You Can’t Do the Work by Shelly Palmer Liars by Glenn Beck Cory CodeSandbox Live Babel repl React Cheat Sheet Fluent Conf Nader Shoe Dog by Phil Knight Nader’s Blog Post Kent Answers to common questions about render props blog post React’s new Context API blog post React Composer Brandon Sanderson CodeSandbox Live David React, Inline Functions, and Performance by Ryan Florence Build Better Products by Laura Klein

JavaScript Jabber
JSJ 309: WebAssembly and JavaScript with Ben Titzer

JavaScript Jabber

Play Episode Listen Later Apr 17, 2018 52:21


Panel: Charles Max Wood Cory House Aimee Knight Special Guests: Ben Titzer In this episode, the JavaScript Jabber panelists discuss WebAssembly and JavaScript with Ben Titzer. Ben is a JavaScript VM engineer and is on the V8 team at Google. He was one of the co-inventors of WebAssembly and he now works on VM engineering as well as other things for WebAssembly. They talk about how WebAssembly came to be and when it would be of most benefit to you in your own code. In particular, we dive pretty deep on: Ben intro JavaScript Co-inventor of WebAssembly (Wasm) Joined V8 in 2014 asm.js Built a JIT compiler to make asm.js faster TurboFan What is the role of JavaScript? What is the role of WebAssembly? SIMD.js JavaScript is not a statically typed language Adding SIMD to Wasm was easier Easy to add things to Wasm Will JavaScript benefit? Using JavaScript with Wasm pros and cons Pros to compiling with Wasm Statically typed languages The more statically typed you are, the more you will benefit from Wasm TypeScript Is WebAssembly headed towards being used in daily application? Rust is investing heavily in Wasm WebAssembly in gaming And much, much more! Links: JavaScript V8 WebAssembly asm.js TurboFan TypeScript Rust WebAssembly GitHub Ben’s GitHub Picks: Charles Ready Player One Movie DevChat.tv YouTube Alexa Flash Briefings: Add skill for “JavaScript Rants” Cory npm Semantic Version Calculator Kent Beck Tweet Aimee MDN 418 Status code Quantity Always Trumps Quality blog post Ben American Politics

JavaScript Jabber
JSJ 308: D3.js with Ben Clinkinbeard

JavaScript Jabber

Play Episode Listen Later Apr 10, 2018 45:50


Panel: Joe Eames Cory House Aimee Knight Special Guests: Ben Clinkinbeard In this episode, the JavaScript Jabber panelists talk about D3.js with Ben Clinkinbeard. D3.js is a JavaScript library that has you use declarative code to tell it what you want and then it figures out all of the browser inconsistencies and creates the notes for you. He talks about the two main concepts behind D3, scales and selections, which once you understand make D3 a lot more user friendly. He then touches on SPGs and discusses his Learn D3 in 5 Days course. In particular, we dive pretty deep on: What is D3.js? Stands for Data Driven Documents JavaScript How much of the learning curve is attributed to learning D3? SPG 2 main concepts behind D3: scales and selections Is learning about SPGs a prerequisite to leaning D3? How serious are you talking when saying idiosyncrasies? SPG tag Understanding positioning in SPG Positions with CSS transforms Are you required to use SPG? Not required to use SPG with D3 Canvas SPG is vector based SPG utility function Responseivefy Learn D3 in 5 Days course Is there and overlap with D3 and React? And much, much more! Links: D3.js JavaScript Responsivefy Learn D3 in 5 Days course React @bclinkinbeard Ben’s GitHub Picks: Cory React cheat sheet “Why software engineers disagree about everything” by Haseeb Qureshi Joe Eames “JavaScript vs. TypeScript vs. ReasonML” by Dr. Axel Rauschmayer Aimee “How To Use Technical Debt In Your Favor” Neuroscience News Twitter Ben ComLink

React Round Up
RRU 006: Setting Up and Getting Used to Gatsby with Aman Mittal

React Round Up

Play Episode Listen Later Apr 10, 2018 45:11


Panel: Charles Max Wood Cory House Tara Manicsic Kent C Dodds Special Guests: Aman Mittal In this episode of React Round Up, the panel discuss setting up and getting used to Gatsby with Aman Mittal. Aman is a computer science graduate, has been working in web development for the past two years, and has worked with companies such as freeCodeCamp. He has been working with React for the past 6 months and started working with Gatsby in January of 2018. They talk about what Gatsby is, why you would want to use it, and what a simple Gatsby site would look like. In particular, we dive pretty deep on: Aman introduction What is your experience with React? Working with Gatsby because of a client What is Gatsby? Gatsby uses React Has become quite mature Why Choose Gatsby? Good with small and medium business clients Gatsby and PWAs Does it rely heavily on GraphQL? GraphQL is useful with Gatsby but it is not necessary What would a simple Gatsby site look like? Index component Has support for CSS and JS The distinction between a static site generator and a normal web app Is Gatsby interactive on the front-end? More mature than other static site generators Generate HTML files for all of your routes Gatsby gives you the best of both worlds Gatsby’s own website Workshop.me How would you suggest people get started with Gatsby? And much, much more! Links: freeCodeCamp React Gatsby GraphQL JavaScript Workshop.me Aman’s GitHub Aman’s Medium @Amanhimself Readingbooks.blog Picks: Charles Get involved in your local government Overcast Cory The Reusable JavaScript Revolution - talk by Cory House Console Log Article Building large scale react applications in a monorepo by Luis Vieira Tara React Videos on YouTube Channel Coco Kent Coco The Greatest Showman React Testing Library Netlify Aman Gatsby Themes The Southern Reach Trilogy by Jeff VanderMeer

All JavaScript Podcasts by Devchat.tv
JSJ 308: D3.js with Ben Clinkinbeard

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Apr 10, 2018 45:50


Panel: Joe Eames Cory House Aimee Knight Special Guests: Ben Clinkinbeard In this episode, the JavaScript Jabber panelists talk about D3.js with Ben Clinkinbeard. D3.js is a JavaScript library that has you use declarative code to tell it what you want and then it figures out all of the browser inconsistencies and creates the notes for you. He talks about the two main concepts behind D3, scales and selections, which once you understand make D3 a lot more user friendly. He then touches on SPGs and discusses his Learn D3 in 5 Days course. In particular, we dive pretty deep on: What is D3.js? Stands for Data Driven Documents JavaScript How much of the learning curve is attributed to learning D3? SPG 2 main concepts behind D3: scales and selections Is learning about SPGs a prerequisite to leaning D3? How serious are you talking when saying idiosyncrasies? SPG tag Understanding positioning in SPG Positions with CSS transforms Are you required to use SPG? Not required to use SPG with D3 Canvas SPG is vector based SPG utility function Responseivefy Learn D3 in 5 Days course Is there and overlap with D3 and React? And much, much more! Links: D3.js JavaScript Responsivefy Learn D3 in 5 Days course React @bclinkinbeard Ben’s GitHub Picks: Cory React cheat sheet “Why software engineers disagree about everything” by Haseeb Qureshi Joe Eames “JavaScript vs. TypeScript vs. ReasonML” by Dr. Axel Rauschmayer Aimee “How To Use Technical Debt In Your Favor” Neuroscience News Twitter Ben ComLink

Devchat.tv Master Feed
JSJ 308: D3.js with Ben Clinkinbeard

Devchat.tv Master Feed

Play Episode Listen Later Apr 10, 2018 45:50


Panel: Joe Eames Cory House Aimee Knight Special Guests: Ben Clinkinbeard In this episode, the JavaScript Jabber panelists talk about D3.js with Ben Clinkinbeard. D3.js is a JavaScript library that has you use declarative code to tell it what you want and then it figures out all of the browser inconsistencies and creates the notes for you. He talks about the two main concepts behind D3, scales and selections, which once you understand make D3 a lot more user friendly. He then touches on SPGs and discusses his Learn D3 in 5 Days course. In particular, we dive pretty deep on: What is D3.js? Stands for Data Driven Documents JavaScript How much of the learning curve is attributed to learning D3? SPG 2 main concepts behind D3: scales and selections Is learning about SPGs a prerequisite to leaning D3? How serious are you talking when saying idiosyncrasies? SPG tag Understanding positioning in SPG Positions with CSS transforms Are you required to use SPG? Not required to use SPG with D3 Canvas SPG is vector based SPG utility function Responseivefy Learn D3 in 5 Days course Is there and overlap with D3 and React? And much, much more! Links: D3.js JavaScript Responsivefy Learn D3 in 5 Days course React @bclinkinbeard Ben’s GitHub Picks: Cory React cheat sheet “Why software engineers disagree about everything” by Haseeb Qureshi Joe Eames “JavaScript vs. TypeScript vs. ReasonML” by Dr. Axel Rauschmayer Aimee “How To Use Technical Debt In Your Favor” Neuroscience News Twitter Ben ComLink

Devchat.tv Master Feed
RRU 006: Setting Up and Getting Used to Gatsby with Aman Mittal

Devchat.tv Master Feed

Play Episode Listen Later Apr 10, 2018 45:11


Panel: Charles Max Wood Cory House Tara Manicsic Kent C Dodds Special Guests: Aman Mittal In this episode of React Round Up, the panel discuss setting up and getting used to Gatsby with Aman Mittal. Aman is a computer science graduate, has been working in web development for the past two years, and has worked with companies such as freeCodeCamp. He has been working with React for the past 6 months and started working with Gatsby in January of 2018. They talk about what Gatsby is, why you would want to use it, and what a simple Gatsby site would look like. In particular, we dive pretty deep on: Aman introduction What is your experience with React? Working with Gatsby because of a client What is Gatsby? Gatsby uses React Has become quite mature Why Choose Gatsby? Good with small and medium business clients Gatsby and PWAs Does it rely heavily on GraphQL? GraphQL is useful with Gatsby but it is not necessary What would a simple Gatsby site look like? Index component Has support for CSS and JS The distinction between a static site generator and a normal web app Is Gatsby interactive on the front-end? More mature than other static site generators Generate HTML files for all of your routes Gatsby gives you the best of both worlds Gatsby’s own website Workshop.me How would you suggest people get started with Gatsby? And much, much more! Links: freeCodeCamp React Gatsby GraphQL JavaScript Workshop.me Aman’s GitHub Aman’s Medium @Amanhimself Readingbooks.blog Picks: Charles Get involved in your local government Overcast Cory The Reusable JavaScript Revolution - talk by Cory House Console Log Article Building large scale react applications in a monorepo by Luis Vieira Tara React Videos on YouTube Channel Coco Kent Coco The Greatest Showman React Testing Library Netlify Aman Gatsby Themes The Southern Reach Trilogy by Jeff VanderMeer

JavaScript Jabber
JSJ 306: The Framework Summit with Joe Eames

JavaScript Jabber

Play Episode Listen Later Mar 27, 2018 48:03


Panel: Charles Max Wood Cory House Aimee Knight Joe Eames AJ O'Neal In this episode, the JavaScript Jabber panelists talk about the Framework Summit. It was the brainchild of Merrick Christensen. This summit includes talks on multiple different frameworks all in a two-day conference, which allows you to get exposed to new frameworks while still learning more about the framework your job requires you to use. Another goal of the conference is that it will be able to open people’s eyes up to the different frameworks available to them and show that no one framework is superior to another. In particular, we dive pretty deep on: What is the Framework Summit? The framework you use plays a huge role in your programming For people who want to learn about more than one framework Allows you to explore The format of the conference Park City, Utah in October 2018 Helps you answer which framework should you use? Goal is to open people’s eyes up to other frameworks Decrease internet arguments over which framework is better Fluent Conference Get to have conversation with other people who work in your framework Making connections React Rally Talk Evan Czaplicki The context matters Being able to deep dive into the different frameworks Using frameworks in conjunction with one another Have you seen “religionist” themes in programming frameworks? Why Good People Are Divided by Politics and Religion by Jonathan Haidt Some people will never look beyond their frameworks If it’s working, why would you mess with it? And much, much more! Links: React Dev Summit JS Dev Summit Framework Summit Angular React Ember JavaScript Fluent Conference React Rally Talk Evan Czaplicki Why Good People Are Divided by Politics and Religion by Jonathan Haidt @FrameworkSummit Picks: Charles Parked Out By the Lake Dustin Christensen DevChat.tv Newspaper by Themeforest Cory Quokka Aimee Republic of Tea – Apple Cider Vinegar Tea The Way of Testivus Joe Evan Czaplicki Talk AJ Dinosaurs Cough Syrup by Young the Giant

All JavaScript Podcasts by Devchat.tv
JSJ 306: The Framework Summit with Joe Eames

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Mar 27, 2018 48:03


Panel: Charles Max Wood Cory House Aimee Knight Joe Eames AJ O'Neal In this episode, the JavaScript Jabber panelists talk about the Framework Summit. It was the brainchild of Merrick Christensen. This summit includes talks on multiple different frameworks all in a two-day conference, which allows you to get exposed to new frameworks while still learning more about the framework your job requires you to use. Another goal of the conference is that it will be able to open people’s eyes up to the different frameworks available to them and show that no one framework is superior to another. In particular, we dive pretty deep on: What is the Framework Summit? The framework you use plays a huge role in your programming For people who want to learn about more than one framework Allows you to explore The format of the conference Park City, Utah in October 2018 Helps you answer which framework should you use? Goal is to open people’s eyes up to other frameworks Decrease internet arguments over which framework is better Fluent Conference Get to have conversation with other people who work in your framework Making connections React Rally Talk Evan Czaplicki The context matters Being able to deep dive into the different frameworks Using frameworks in conjunction with one another Have you seen “religionist” themes in programming frameworks? Why Good People Are Divided by Politics and Religion by Jonathan Haidt Some people will never look beyond their frameworks If it’s working, why would you mess with it? And much, much more! Links: React Dev Summit JS Dev Summit Framework Summit Angular React Ember JavaScript Fluent Conference React Rally Talk Evan Czaplicki Why Good People Are Divided by Politics and Religion by Jonathan Haidt @FrameworkSummit Picks: Charles Parked Out By the Lake Dustin Christensen DevChat.tv Newspaper by Themeforest Cory Quokka Aimee Republic of Tea – Apple Cider Vinegar Tea The Way of Testivus Joe Evan Czaplicki Talk AJ Dinosaurs Cough Syrup by Young the Giant

Devchat.tv Master Feed
JSJ 306: The Framework Summit with Joe Eames

Devchat.tv Master Feed

Play Episode Listen Later Mar 27, 2018 48:03


Panel: Charles Max Wood Cory House Aimee Knight Joe Eames AJ O'Neal In this episode, the JavaScript Jabber panelists talk about the Framework Summit. It was the brainchild of Merrick Christensen. This summit includes talks on multiple different frameworks all in a two-day conference, which allows you to get exposed to new frameworks while still learning more about the framework your job requires you to use. Another goal of the conference is that it will be able to open people’s eyes up to the different frameworks available to them and show that no one framework is superior to another. In particular, we dive pretty deep on: What is the Framework Summit? The framework you use plays a huge role in your programming For people who want to learn about more than one framework Allows you to explore The format of the conference Park City, Utah in October 2018 Helps you answer which framework should you use? Goal is to open people’s eyes up to other frameworks Decrease internet arguments over which framework is better Fluent Conference Get to have conversation with other people who work in your framework Making connections React Rally Talk Evan Czaplicki The context matters Being able to deep dive into the different frameworks Using frameworks in conjunction with one another Have you seen “religionist” themes in programming frameworks? Why Good People Are Divided by Politics and Religion by Jonathan Haidt Some people will never look beyond their frameworks If it’s working, why would you mess with it? And much, much more! Links: React Dev Summit JS Dev Summit Framework Summit Angular React Ember JavaScript Fluent Conference React Rally Talk Evan Czaplicki Why Good People Are Divided by Politics and Religion by Jonathan Haidt @FrameworkSummit Picks: Charles Parked Out By the Lake Dustin Christensen DevChat.tv Newspaper by Themeforest Cory Quokka Aimee Republic of Tea – Apple Cider Vinegar Tea The Way of Testivus Joe Evan Czaplicki Talk AJ Dinosaurs Cough Syrup by Young the Giant

React Round Up
RRU 003: Advanced Component Patterns and Downshift with Kent C Dodds

React Round Up

Play Episode Listen Later Mar 20, 2018 64:26


Panel: Charles Max Wood Nader Dabit Kent C Dodds Cory House In this episode of React Round Up, the panel discusses advanced component patterns and Downshift. They talk about different component patterns, especially render prop patters, and the fact that Downshift allows for your components to be much more useful generally for more people. They also note that the render prop patterns can help to separate logic from view, which makes things easier to develop. In particular, we dive pretty deep on: Component patterns Downshift Egghead course What makes it advanced? Requires taking a step back and think about your components a little differently Is there a React Native version? React Render prop patterns Code abstraction or code re-use Why Downshift is powerful Can use regular HTML and CSS with Downshift Allows you to be in charge of rendering What other places is the render prop pattern useful? What is the benefit of using a react component over a JS component? Awesome React Render Props GitHub Repo Downshift is highly accessible jQuery UI @MarcySutton Render props reduce the amount of opinion that component has Choosing render props gives the consumer more power as well as more responsibility Render props are best used with open source projects And much, much more! Links: React Dev Summit Downshift Egghead Course React Native React Awesome React Render Props GitHub Repo jQuery UI @MarcySutton Kent’s GitHub Kent’s Website (with links to courses) Picks: Charles Kent’s blog Hogwarts Battle Board Game Take time to write leisure code Sign up for React Dev Summit with code KentCDodds for 10% off Cory Manorisms YouTube Videos Kent React Component Component Winamp2-js His Newsletter Beyond React 16 by Dan Abramov

Devchat.tv Master Feed
RRU 003: Advanced Component Patterns and Downshift with Kent C Dodds

Devchat.tv Master Feed

Play Episode Listen Later Mar 20, 2018 64:26


Panel: Charles Max Wood Nader Dabit Kent C Dodds Cory House In this episode of React Round Up, the panel discusses advanced component patterns and Downshift. They talk about different component patterns, especially render prop patters, and the fact that Downshift allows for your components to be much more useful generally for more people. They also note that the render prop patterns can help to separate logic from view, which makes things easier to develop. In particular, we dive pretty deep on: Component patterns Downshift Egghead course What makes it advanced? Requires taking a step back and think about your components a little differently Is there a React Native version? React Render prop patterns Code abstraction or code re-use Why Downshift is powerful Can use regular HTML and CSS with Downshift Allows you to be in charge of rendering What other places is the render prop pattern useful? What is the benefit of using a react component over a JS component? Awesome React Render Props GitHub Repo Downshift is highly accessible jQuery UI @MarcySutton Render props reduce the amount of opinion that component has Choosing render props gives the consumer more power as well as more responsibility Render props are best used with open source projects And much, much more! Links: React Dev Summit Downshift Egghead Course React Native React Awesome React Render Props GitHub Repo jQuery UI @MarcySutton Kent’s GitHub Kent’s Website (with links to courses) Picks: Charles Kent’s blog Hogwarts Battle Board Game Take time to write leisure code Sign up for React Dev Summit with code KentCDodds for 10% off Cory Manorisms YouTube Videos Kent React Component Component Winamp2-js His Newsletter Beyond React 16 by Dan Abramov

Devchat.tv Master Feed
JSJ 304: React: The Big Picture

Devchat.tv Master Feed

Play Episode Listen Later Mar 13, 2018 51:00


Panel: Charles Max Wood Aimee Knight Joe Eames Cory House AJ O'Neal Special Guests: None In this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components. In particular, we dive pretty deep on: What is React: The Big Picture course? React The frameworks work with each other Reason and Elm How to decide when using React is the best option? React tradeoffs JavaScript React expects you to do a little more typing and work React is very close to JavaScript React pushes you towards a single file per component React Round Up Are the Code Mods as wonderful as they sound? Angular Create React App What are Code Mods? Lack of opinionated approach in React Using React in a more consistent way MobX and Redux Start off using just plain React When wouldn’t you want to use React? And much, much more! Links: React: The Big Picture Cory’s Pluralsight Reason Elm React JavaScript React Round Up Create React App Angular MobX Redux Framework Summit 2018 Angular: The Big Picture React Dev Summit Picks: Charles Hunting Hitler The Greatest Showman: Sing-a-long Aimee “Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin “How to understand the large codebase of an open-source project?” blog post Joe Marital Bliss Card Game AJ Pplwink.com

Devchat.tv Master Feed
RRU 002: Webpack the Good Parts with Juho Vepsäläinen

Devchat.tv Master Feed

Play Episode Listen Later Mar 13, 2018 53:22


Panel: Charles Max Wood Nader Dabit Cory House Special Guests: Juho Vepsäläinen In this episode of React Round Up, the panel discusses Webpack the good parts with Juho Vepsäläinen. He talks a lot about the book he has written on Webpack, which helps people understand Webpack and how to work with it. They also discuss the advantages to using Webpack and discuss how you can use it in your coding to your benefit. In particular, we dive pretty deep on: For 10% off, use “Juho” to sign up for React Dev Summit What is Webpack? Juho’s Webpack book: SurviveJS React How can someone get into learning about Webpack if they’re not from a React background? It’s all about the contents behind Webpack How popular is Webpack and how large is it? You don’t need to read all 400 pages of his book Is there a certain way to write with Webpack? You can learn things as you go with Webpack How to approach code using Webpack How new updates with change the philosophy behind Webpack It’s good for Webpack to have pressure from the outside There is no reason to use a newer tool if it already works in an older tool Are there particular plug-ins that you use in Webpack that you really like? HTML plug-in React Native Interesting Webpack project uses Juho’s GitHub Decreasing need to be a Webpacker expert And much, much more! Links: React Dev Summit Webpack SuviveJS React React Native Juho’s GitHub NGconf React Finland Conference Picks: Charles React Dev Summit View on Vue Podcast The Whole-Brain Child by Daniel J. Siegel and Tina Payne Bryson Scott Beebe Nader React blogpost Ready Player One by Ernest Cline Cory The Knowledge Project Podcast Juho JAMstack

JavaScript Jabber
JSJ 304: React: The Big Picture

JavaScript Jabber

Play Episode Listen Later Mar 13, 2018 51:00


Panel: Charles Max Wood Aimee Knight Joe Eames Cory House AJ O'Neal Special Guests: None In this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components. In particular, we dive pretty deep on: What is React: The Big Picture course? React The frameworks work with each other Reason and Elm How to decide when using React is the best option? React tradeoffs JavaScript React expects you to do a little more typing and work React is very close to JavaScript React pushes you towards a single file per component React Round Up Are the Code Mods as wonderful as they sound? Angular Create React App What are Code Mods? Lack of opinionated approach in React Using React in a more consistent way MobX and Redux Start off using just plain React When wouldn’t you want to use React? And much, much more! Links: React: The Big Picture Cory’s Pluralsight Reason Elm React JavaScript React Round Up Create React App Angular MobX Redux Framework Summit 2018 Angular: The Big Picture React Dev Summit Picks: Charles Hunting Hitler The Greatest Showman: Sing-a-long Aimee “Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin “How to understand the large codebase of an open-source project?” blog post Joe Marital Bliss Card Game AJ Pplwink.com

All JavaScript Podcasts by Devchat.tv
JSJ 304: React: The Big Picture

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Mar 13, 2018 51:00


Panel: Charles Max Wood Aimee Knight Joe Eames Cory House AJ O'Neal Special Guests: None In this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components. In particular, we dive pretty deep on: What is React: The Big Picture course? React The frameworks work with each other Reason and Elm How to decide when using React is the best option? React tradeoffs JavaScript React expects you to do a little more typing and work React is very close to JavaScript React pushes you towards a single file per component React Round Up Are the Code Mods as wonderful as they sound? Angular Create React App What are Code Mods? Lack of opinionated approach in React Using React in a more consistent way MobX and Redux Start off using just plain React When wouldn’t you want to use React? And much, much more! Links: React: The Big Picture Cory’s Pluralsight Reason Elm React JavaScript React Round Up Create React App Angular MobX Redux Framework Summit 2018 Angular: The Big Picture React Dev Summit Picks: Charles Hunting Hitler The Greatest Showman: Sing-a-long Aimee “Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin “How to understand the large codebase of an open-source project?” blog post Joe Marital Bliss Card Game AJ Pplwink.com

React Round Up
RRU 002: Webpack the Good Parts with Juho Vepsäläinen

React Round Up

Play Episode Listen Later Mar 13, 2018 53:22


Panel: Charles Max Wood Nader Dabit Cory House Special Guests: Juho Vepsäläinen In this episode of React Round Up, the panel discusses Webpack the good parts with Juho Vepsäläinen. He talks a lot about the book he has written on Webpack, which helps people understand Webpack and how to work with it. They also discuss the advantages to using Webpack and discuss how you can use it in your coding to your benefit. In particular, we dive pretty deep on: For 10% off, use “Juho” to sign up for React Dev Summit What is Webpack? Juho’s Webpack book: SurviveJS React How can someone get into learning about Webpack if they’re not from a React background? It’s all about the contents behind Webpack How popular is Webpack and how large is it? You don’t need to read all 400 pages of his book Is there a certain way to write with Webpack? You can learn things as you go with Webpack How to approach code using Webpack How new updates with change the philosophy behind Webpack It’s good for Webpack to have pressure from the outside There is no reason to use a newer tool if it already works in an older tool Are there particular plug-ins that you use in Webpack that you really like? HTML plug-in React Native Interesting Webpack project uses Juho’s GitHub Decreasing need to be a Webpacker expert And much, much more! Links: React Dev Summit Webpack SuviveJS React React Native Juho’s GitHub NGconf React Finland Conference Picks: Charles React Dev Summit View on Vue Podcast The Whole-Brain Child by Daniel J. Siegel and Tina Payne Bryson Scott Beebe Nader React blogpost Ready Player One by Ernest Cline Cory The Knowledge Project Podcast Juho JAMstack

React Round Up
RRU 001: Getting Started with React

React Round Up

Play Episode Listen Later Mar 6, 2018 68:28


Panel:  Charles Max Wood Tara Manicsic Nader Dabit Kent C. Dodds Cory House Special Guests: None In this episode of React Round Up, the panel discusses how they each got into React and they provide some great resources for people who want to learn more about React and what it’s all about. They emphasize the fact that React is a very straightforward language and can be used relatively painlessly with a little bit of learning before jumping in. In particular, we dive pretty deep on: How each of the panelists got into React Angular beginnings React Native React Native Training React JS Consulting Node developer beginnings Backbone to React Ruby background How to get into React yourself Learn things in the right order React-Howto Beginners Guide to ReactJS You Don’t Know JS, ES6, and Beyond by Kyle Simpson CodeSandbox.io ES6 Get comfortable with JavaScript first Biggest mistake people make when learning about react ES6 and Beyond Workshop React Community How did the panel learn ES6? And much, much more! Links: React Native Training  React JS Consulting React-Howto Beginners Guide to ReactJS You Don’t Know JS, ES6, and Beyond by Kyle Simpson CodeSandbox.io ES6 and Beyond Workshop Tara’s Twitter and GitHub Cory’s Twitter, Medium Blog, and BitNative Blog Nader’s Twitter, Medium, GitHub, React Native Training Blog, React Native Training YouTube Kent’s Twitter and GitHub Charles’ Twitter and DevChat.tv Picks: Charles React Course on Pluralsite React Dev Summit 2018 Ready Player One Tara JazzCon #toshmagosh Nader Viro Media AWS AppSync Kent Dogs Nitin Tulswani Cory Node Tip React: The Big Picture React Rally

Devchat.tv Master Feed
RRU 001: Getting Started with React

Devchat.tv Master Feed

Play Episode Listen Later Mar 6, 2018 68:28


Panel:  Charles Max Wood Tara Manicsic Nader Dabit Kent C. Dodds Cory House Special Guests: None In this episode of React Round Up, the panel discusses how they each got into React and they provide some great resources for people who want to learn more about React and what it’s all about. They emphasize the fact that React is a very straightforward language and can be used relatively painlessly with a little bit of learning before jumping in. In particular, we dive pretty deep on: How each of the panelists got into React Angular beginnings React Native React Native Training React JS Consulting Node developer beginnings Backbone to React Ruby background How to get into React yourself Learn things in the right order React-Howto Beginners Guide to ReactJS You Don’t Know JS, ES6, and Beyond by Kyle Simpson CodeSandbox.io ES6 Get comfortable with JavaScript first Biggest mistake people make when learning about react ES6 and Beyond Workshop React Community How did the panel learn ES6? And much, much more! Links: React Native Training  React JS Consulting React-Howto Beginners Guide to ReactJS You Don’t Know JS, ES6, and Beyond by Kyle Simpson CodeSandbox.io ES6 and Beyond Workshop Tara’s Twitter and GitHub Cory’s Twitter, Medium Blog, and BitNative Blog Nader’s Twitter, Medium, GitHub, React Native Training Blog, React Native Training YouTube Kent’s Twitter and GitHub Charles’ Twitter and DevChat.tv Picks: Charles React Course on Pluralsite React Dev Summit 2018 Ready Player One Tara JazzCon #toshmagosh Nader Viro Media AWS AppSync Kent Dogs Nitin Tulswani Cory Node Tip React: The Big Picture React Rally

All JavaScript Podcasts by Devchat.tv
JSJ 301: CSS Grids: The Future of Frontend Layout with Dave Geddes

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Feb 20, 2018 63:42


Panel:  Charles Max Wood Aimee Knight Cory House AJ O'Neal Joe Eames Aaron Frost Special Guests: Dave Geddes In this episode, the JavaScript Jabber panelists talk with Dave Geddes about CSS Grids. Dave quit his job about a year ago and has been living the entrepreneur and programmer life since then. Now, he builds mastery games to help people learn CSS. Dave discusses the differences between Flexbox and CSS Grid and how the games that he creates can help people learn CSS Grid in a fun and interactive way. In particular, we dive pretty deep on: CSS Mastery games FlexboxZombies.com GridCritters.com Uses spaced repetition and delayed recall to learn CSS Grid Flexbox CSS Grid as the cake and Flexbox as the frosting Edge spec What Flexbox can do Sub-Grids Geddski.com Nesting Grids Old Grid vs New Grid layout Why would you move from Flexbox to CSS Grid? CSS Grid tools GridByExample.com Education and Gamification Pick a UI that interests you For a discount on Grid Critters: enter JS Jabber for 20% off And much, much more! Links: Linode FlexboxZombies.com GridCritters.com Geddski.com GridByExample.com FreshBooks @Geddski Picks: Charles R Pods Earphones Aimee NEU Cleanse “At Age 6, Girls Are Less Likely to Identify Females As ‘Really, Really Smart’” Cory Cory Tweet AJ How to Start a Startup Made in America by Sam Walton Joe The Dungeoneers by John David Anderson NG Conf Aaron Fire and Fury by Michael Wolff Dave They Are Billions

JavaScript Jabber
JSJ 301: CSS Grids: The Future of Frontend Layout with Dave Geddes

JavaScript Jabber

Play Episode Listen Later Feb 20, 2018 63:42


Panel:  Charles Max Wood Aimee Knight Cory House AJ O'Neal Joe Eames Aaron Frost Special Guests: Dave Geddes In this episode, the JavaScript Jabber panelists talk with Dave Geddes about CSS Grids. Dave quit his job about a year ago and has been living the entrepreneur and programmer life since then. Now, he builds mastery games to help people learn CSS. Dave discusses the differences between Flexbox and CSS Grid and how the games that he creates can help people learn CSS Grid in a fun and interactive way. In particular, we dive pretty deep on: CSS Mastery games FlexboxZombies.com GridCritters.com Uses spaced repetition and delayed recall to learn CSS Grid Flexbox CSS Grid as the cake and Flexbox as the frosting Edge spec What Flexbox can do Sub-Grids Geddski.com Nesting Grids Old Grid vs New Grid layout Why would you move from Flexbox to CSS Grid? CSS Grid tools GridByExample.com Education and Gamification Pick a UI that interests you For a discount on Grid Critters: enter JS Jabber for 20% off And much, much more! Links: Linode FlexboxZombies.com GridCritters.com Geddski.com GridByExample.com FreshBooks @Geddski Picks: Charles R Pods Earphones Aimee NEU Cleanse “At Age 6, Girls Are Less Likely to Identify Females As ‘Really, Really Smart’” Cory Cory Tweet AJ How to Start a Startup Made in America by Sam Walton Joe The Dungeoneers by John David Anderson NG Conf Aaron Fire and Fury by Michael Wolff Dave They Are Billions

Devchat.tv Master Feed
JSJ 301: CSS Grids: The Future of Frontend Layout with Dave Geddes

Devchat.tv Master Feed

Play Episode Listen Later Feb 20, 2018 63:42


Panel:  Charles Max Wood Aimee Knight Cory House AJ O'Neal Joe Eames Aaron Frost Special Guests: Dave Geddes In this episode, the JavaScript Jabber panelists talk with Dave Geddes about CSS Grids. Dave quit his job about a year ago and has been living the entrepreneur and programmer life since then. Now, he builds mastery games to help people learn CSS. Dave discusses the differences between Flexbox and CSS Grid and how the games that he creates can help people learn CSS Grid in a fun and interactive way. In particular, we dive pretty deep on: CSS Mastery games FlexboxZombies.com GridCritters.com Uses spaced repetition and delayed recall to learn CSS Grid Flexbox CSS Grid as the cake and Flexbox as the frosting Edge spec What Flexbox can do Sub-Grids Geddski.com Nesting Grids Old Grid vs New Grid layout Why would you move from Flexbox to CSS Grid? CSS Grid tools GridByExample.com Education and Gamification Pick a UI that interests you For a discount on Grid Critters: enter JS Jabber for 20% off And much, much more! Links: Linode FlexboxZombies.com GridCritters.com Geddski.com GridByExample.com FreshBooks @Geddski Picks: Charles R Pods Earphones Aimee NEU Cleanse “At Age 6, Girls Are Less Likely to Identify Females As ‘Really, Really Smart’” Cory Cory Tweet AJ How to Start a Startup Made in America by Sam Walton Joe The Dungeoneers by John David Anderson NG Conf Aaron Fire and Fury by Michael Wolff Dave They Are Billions

All JavaScript Podcasts by Devchat.tv
JSJ 300: Celebration

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Feb 14, 2018 56:58


Panel:  Charles Max Wood Aimee Knight Cory House AJ O'Neal Joe Eames Special Guests: None In this episode, the JavaScript Jabber panelists speak on where they are what they are up to today. Aimee is still in Nashville, Tennessee, and it is currently working at Built Technologies and is working with JavaScript. Cory is still authoring courses for Pluralsite, has more recently been doing consulting with React, and is the principal engineer at Cox Automotive. Joe is doing a lot of Pluralsight work, puts together conferences, and is working on a new podcast with Charles. AJ recently did some side work with Dash, is interested in working on a new domain service, and recently got married. Charles is currently at ngATL conference, and has been attending a lot of conferences recently. He is also starting to head over to the video realm and is creating a new podcast called React Roundup and a View Podcast with Joe. They also talk about what they each have planned in the upcoming year for their careers and their lives. In particular, we dive pretty deep on: Built Technologies JavaScript Front End and Full Stack Pluralsite React consulting Cox Automotive Front end apps View and React podcast Angular JS to Angular Pluralsight courses Big Picture React courses Fork of Bitcoin called Dash New domain service ngATL React Roundup Podcast New podcasts on artificial intelligence, IOT, augmented and virtual reality game development, python Node, JavaScript, and Rust And much, much more! Links: Linode Built Technologies Pluralsite Cox Automotive Dash ngATL DevChat.tv Youtube FreshBooks Picks: Charles ATR2100 Microphone Zoom H6 Apple AirPods ngATL ngGirls Aimee Improving Ourselves to Death What Does Code Readability Mean? Cory JavaScript Tip Tweet   AJ How to Start a Startup YouTube Series Singham Movie   Joe WebFlow.com

JavaScript Jabber
JSJ 300: Celebration

JavaScript Jabber

Play Episode Listen Later Feb 13, 2018 56:58


Panel:  Charles Max Wood Aimee Knight Cory House AJ O'Neal Joe Eames Special Guests: None In this episode, the JavaScript Jabber panelists speak on where they are what they are up to today. Aimee is still in Nashville, Tennessee, and it is currently working at Built Technologies and is working with JavaScript. Cory is still authoring courses for Pluralsite, has more recently been doing consulting with React, and is the principal engineer at Cox Automotive. Joe is doing a lot of Pluralsight work, puts together conferences, and is working on a new podcast with Charles. AJ recently did some side work with Dash, is interested in working on a new domain service, and recently got married. Charles is currently at ngATL conference, and has been attending a lot of conferences recently. He is also starting to head over to the video realm and is creating a new podcast called React Roundup and a View Podcast with Joe. They also talk about what they each have planned in the upcoming year for their careers and their lives. In particular, we dive pretty deep on: Built Technologies JavaScript Front End and Full Stack Pluralsite React consulting Cox Automotive Front end apps View and React podcast Angular JS to Angular Pluralsight courses Big Picture React courses Fork of Bitcoin called Dash New domain service ngATL React Roundup Podcast New podcasts on artificial intelligence, IOT, augmented and virtual reality game development, python Node, JavaScript, and Rust And much, much more! Links: Linode Built Technologies Pluralsite Cox Automotive Dash ngATL DevChat.tv Youtube FreshBooks Picks: Charles ATR2100 Microphone Zoom H6 Apple AirPods ngATL ngGirls Aimee Improving Ourselves to Death What Does Code Readability Mean? Cory JavaScript Tip Tweet   AJ How to Start a Startup YouTube Series Singham Movie   Joe WebFlow.com

Devchat.tv Master Feed
JSJ 300: Celebration

Devchat.tv Master Feed

Play Episode Listen Later Feb 13, 2018 56:58


Panel:  Charles Max Wood Aimee Knight Cory House AJ O'Neal Joe Eames Special Guests: None In this episode, the JavaScript Jabber panelists speak on where they are what they are up to today. Aimee is still in Nashville, Tennessee, and it is currently working at Built Technologies and is working with JavaScript. Cory is still authoring courses for Pluralsite, has more recently been doing consulting with React, and is the principal engineer at Cox Automotive. Joe is doing a lot of Pluralsight work, puts together conferences, and is working on a new podcast with Charles. AJ recently did some side work with Dash, is interested in working on a new domain service, and recently got married. Charles is currently at ngATL conference, and has been attending a lot of conferences recently. He is also starting to head over to the video realm and is creating a new podcast called React Roundup and a View Podcast with Joe. They also talk about what they each have planned in the upcoming year for their careers and their lives. In particular, we dive pretty deep on: Built Technologies JavaScript Front End and Full Stack Pluralsite React consulting Cox Automotive Front end apps View and React podcast Angular JS to Angular Pluralsight courses Big Picture React courses Fork of Bitcoin called Dash New domain service ngATL React Roundup Podcast New podcasts on artificial intelligence, IOT, augmented and virtual reality game development, python Node, JavaScript, and Rust And much, much more! Links: Linode Built Technologies Pluralsite Cox Automotive Dash ngATL DevChat.tv Youtube FreshBooks Picks: Charles ATR2100 Microphone Zoom H6 Apple AirPods ngATL ngGirls Aimee Improving Ourselves to Death What Does Code Readability Mean? Cory JavaScript Tip Tweet   AJ How to Start a Startup YouTube Series Singham Movie   Joe WebFlow.com

All JavaScript Podcasts by Devchat.tv
JSJ 298: Angular, Vue and TypeScript with John Papa

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jan 31, 2018 63:04


Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: John Papa In this episode, JavaScript Jabber panelist speak with John Papa. John has been doing web programming for over twenty years on multiple platforms and has been contributing to the developer communities through conferences, authoring books, videos and courses on Pluralsight. John is on the show to discuss an articles he wrote on A Look at Angular Along Side Vue, and another article on Vue.js  with TypeScript. John talks about the new features with the different versions of Angular technologies, anxiety in the different features, comparisons between the technologies and use case with Angular. In particular, we dive pretty deep on: A look at Angular Along Side Vue - Article Angular 5, Amber,Vue,  React, Angular Angular 2 - different features CLI Spell Webpack Comparisons - Why the anxiety? Opinions of Angular and sprinkling in other technologies Vue is the easy to use with Angular Are there breakpoints with the uses case? Choosing technologies Talk about working with Vue and Angular DSL - Domain Specific Language Vue and 3rd party libraries Talk about Vue working with TypeScript Vue.js  with TypeScript Vue with TypeScript looks similar to Angular Vetur What does 2018 have in store for Angular? Native apps and web functionality And much more! Links: https://johnpapa.net Vue.js  with TypeScript A Look at Angular Along Side Vue @john_papa https://github.com/johnpapa Picks: Corey cypress.io Charles E Myth Revisited Profit First  Dunkirk Aimee Crucial Conversations  Ripple or XRP Joe The Greatest Showman Better Late Then Never Vue 7 Languages In 7 Weeks  - Book John Jumanji 2017 Emotional Intelligence

Devchat.tv Master Feed
JSJ 298: Angular, Vue and TypeScript with John Papa

Devchat.tv Master Feed

Play Episode Listen Later Jan 30, 2018 63:04


Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: John Papa In this episode, JavaScript Jabber panelist speak with John Papa. John has been doing web programming for over twenty years on multiple platforms and has been contributing to the developer communities through conferences, authoring books, videos and courses on Pluralsight. John is on the show to discuss an articles he wrote on A Look at Angular Along Side Vue, and another article on Vue.js  with TypeScript. John talks about the new features with the different versions of Angular technologies, anxiety in the different features, comparisons between the technologies and use case with Angular. In particular, we dive pretty deep on: A look at Angular Along Side Vue - Article Angular 5, Amber,Vue,  React, Angular Angular 2 - different features CLI Spell Webpack Comparisons - Why the anxiety? Opinions of Angular and sprinkling in other technologies Vue is the easy to use with Angular Are there breakpoints with the uses case? Choosing technologies Talk about working with Vue and Angular DSL - Domain Specific Language Vue and 3rd party libraries Talk about Vue working with TypeScript Vue.js  with TypeScript Vue with TypeScript looks similar to Angular Vetur What does 2018 have in store for Angular? Native apps and web functionality And much more! Links: https://johnpapa.net Vue.js  with TypeScript A Look at Angular Along Side Vue @john_papa https://github.com/johnpapa Picks: Corey cypress.io Charles E Myth Revisited Profit First  Dunkirk Aimee Crucial Conversations  Ripple or XRP Joe The Greatest Showman Better Late Then Never Vue 7 Languages In 7 Weeks  - Book John Jumanji 2017 Emotional Intelligence

JavaScript Jabber
JSJ 298: Angular, Vue and TypeScript with John Papa

JavaScript Jabber

Play Episode Listen Later Jan 30, 2018 63:04


Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: John Papa In this episode, JavaScript Jabber panelist speak with John Papa. John has been doing web programming for over twenty years on multiple platforms and has been contributing to the developer communities through conferences, authoring books, videos and courses on Pluralsight. John is on the show to discuss an articles he wrote on A Look at Angular Along Side Vue, and another article on Vue.js  with TypeScript. John talks about the new features with the different versions of Angular technologies, anxiety in the different features, comparisons between the technologies and use case with Angular. In particular, we dive pretty deep on: A look at Angular Along Side Vue - Article Angular 5, Amber,Vue,  React, Angular Angular 2 - different features CLI Spell Webpack Comparisons - Why the anxiety? Opinions of Angular and sprinkling in other technologies Vue is the easy to use with Angular Are there breakpoints with the uses case? Choosing technologies Talk about working with Vue and Angular DSL - Domain Specific Language Vue and 3rd party libraries Talk about Vue working with TypeScript Vue.js  with TypeScript Vue with TypeScript looks similar to Angular Vetur What does 2018 have in store for Angular? Native apps and web functionality And much more! Links: https://johnpapa.net Vue.js  with TypeScript A Look at Angular Along Side Vue @john_papa https://github.com/johnpapa Picks: Corey cypress.io Charles E Myth Revisited Profit First  Dunkirk Aimee Crucial Conversations  Ripple or XRP Joe The Greatest Showman Better Late Then Never Vue 7 Languages In 7 Weeks  - Book John Jumanji 2017 Emotional Intelligence

All JavaScript Podcasts by Devchat.tv
JSJ 296: Changes in React and the license with Azat Mardan

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jan 16, 2018 57:34


Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: Azat Mardan In this episode, JavaScript Jabber panelist speak with Azat Mardan. Azat is a return guest, previously on JSJ Episode 230. Azat is an author of 14 books on Node JS, JavaScript, and React JS. Azat works at Capital One on the technology team. Azat is the founder and creator of Node University. Azat is on the show to talk about changes in React and licensing. Some of the topics cover Facebook,  licensing with React, using the wrong version of React, patent wars, and much more in-depth information on current events in React. In particular, we dive pretty deep on: Facebook - Licensing with React Using the Wrong version of React in some companies BSD licensing Patent wars Facebook developing React Difference in Preact and Inferno Rewriting applications What did Capital One do about the changes? React 16 Pure React Was the BSD patents - Med and Sm Companies Patents explained React Developers at Facebook Fiber - New Core Architecture And much more! Links: http://azat.co https://node.university https://devchat.tv/js-jabber/230-jsj-node-at-capital-one-with-azat-mardan Picks: Cory Axel Rauschmayer post Prettier Charles Indiegogo for Dev Chat forum.devchat.tv Aimee Dev Tees Hacker News - Question on Stack Exchange and Estimates  Joe Heroku  El Camino Christmas Azat PMP  Azat - Short Lecture

JavaScript Jabber
JSJ 296: Changes in React and the license with Azat Mardan

JavaScript Jabber

Play Episode Listen Later Jan 16, 2018 57:34


Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: Azat Mardan In this episode, JavaScript Jabber panelist speak with Azat Mardan. Azat is a return guest, previously on JSJ Episode 230. Azat is an author of 14 books on Node JS, JavaScript, and React JS. Azat works at Capital One on the technology team. Azat is the founder and creator of Node University. Azat is on the show to talk about changes in React and licensing. Some of the topics cover Facebook,  licensing with React, using the wrong version of React, patent wars, and much more in-depth information on current events in React. In particular, we dive pretty deep on: Facebook - Licensing with React Using the Wrong version of React in some companies BSD licensing Patent wars Facebook developing React Difference in Preact and Inferno Rewriting applications What did Capital One do about the changes? React 16 Pure React Was the BSD patents - Med and Sm Companies Patents explained React Developers at Facebook Fiber - New Core Architecture And much more! Links: http://azat.co https://node.university https://devchat.tv/js-jabber/230-jsj-node-at-capital-one-with-azat-mardan Picks: Cory Axel Rauschmayer post Prettier Charles Indiegogo for Dev Chat forum.devchat.tv Aimee Dev Tees Hacker News - Question on Stack Exchange and Estimates  Joe Heroku  El Camino Christmas Azat PMP  Azat - Short Lecture

Devchat.tv Master Feed
JSJ 296: Changes in React and the license with Azat Mardan

Devchat.tv Master Feed

Play Episode Listen Later Jan 16, 2018 57:34


Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: Azat Mardan In this episode, JavaScript Jabber panelist speak with Azat Mardan. Azat is a return guest, previously on JSJ Episode 230. Azat is an author of 14 books on Node JS, JavaScript, and React JS. Azat works at Capital One on the technology team. Azat is the founder and creator of Node University. Azat is on the show to talk about changes in React and licensing. Some of the topics cover Facebook,  licensing with React, using the wrong version of React, patent wars, and much more in-depth information on current events in React. In particular, we dive pretty deep on: Facebook - Licensing with React Using the Wrong version of React in some companies BSD licensing Patent wars Facebook developing React Difference in Preact and Inferno Rewriting applications What did Capital One do about the changes? React 16 Pure React Was the BSD patents - Med and Sm Companies Patents explained React Developers at Facebook Fiber - New Core Architecture And much more! Links: http://azat.co https://node.university https://devchat.tv/js-jabber/230-jsj-node-at-capital-one-with-azat-mardan Picks: Cory Axel Rauschmayer post Prettier Charles Indiegogo for Dev Chat forum.devchat.tv Aimee Dev Tees Hacker News - Question on Stack Exchange and Estimates  Joe Heroku  El Camino Christmas Azat PMP  Azat - Short Lecture

All JavaScript Podcasts by Devchat.tv
JSJ 295: Developers as Entrepreneurs with Ryan Glover

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jan 9, 2018 65:42


Panel:  Charles Max Wood  Cory House Joe Eames Aimee Knight   Special Guests: Ryan Glover In this episode, JavaScript Jabber panelist speak with Ryan Glover. Ryan is on JavaScript Jabber to talks about Entrepreneurship as a developer.  Ryan runs Clever Beagle in Chicago Illinois. Clever Beagle is a mentorship company that helps people build their first software Product. Ryan and the panel discuss the many roads of entrepreneurship, startup business ideas, servicing and teaching the community, how to’s, and psychological challenges, hiring, seeing your ideas through to the end, and privilege.  In particular, we dive pretty deep on: How do you get started as an entrepreneur?  Clever Beagle The Meteor Chef Where are people getting stuck on the builds?  Fear, unknowns Simple, but not easy  Drive and ability to step into the unknown Survival of the fittest Hire before you are already  Losing your marbles Starting on a smaller scale How do I know my idea is going to work?  Book - Brick by Brick Multiple lines of business Managing a portfolio of business  Revenue streams  Marketing  Quitter When do I quit?  6-12 months of cash before you quit Making mistakes in entrepreneurship? Be a reader and study Go out a read books!  Experiential not taught  Luck and Privilege Video - Life of Privilege Explained in a $100 Race Procrastinate on Purpose And much more!  Links: Clever Beagle  The Meteor Chef https://www.linkedin.com/in/ryangglover http://www.ryanglover.net Brick by Brick Quitter Procrastinate on Purpose Do Thing That Don’t Scale @rglover Picks: Cory The Power of Moments The 50th Law Charles ReactDevSummit.com Indiegogo for Dev Chat .NetRocks Aimee Life of Privilege Explained in a $100 Race Joe Everybody Lies Murder on the Orient Express   Ryan Turning Pro - Steven Pressfield series The Power of Beliefs in Business

JavaScript Jabber
JSJ 295: Developers as Entrepreneurs with Ryan Glover

JavaScript Jabber

Play Episode Listen Later Jan 8, 2018 65:42


Panel:  Charles Max Wood  Cory House Joe Eames Aimee Knight   Special Guests: Ryan Glover In this episode, JavaScript Jabber panelist speak with Ryan Glover. Ryan is on JavaScript Jabber to talks about Entrepreneurship as a developer.  Ryan runs Clever Beagle in Chicago Illinois. Clever Beagle is a mentorship company that helps people build their first software Product. Ryan and the panel discuss the many roads of entrepreneurship, startup business ideas, servicing and teaching the community, how to’s, and psychological challenges, hiring, seeing your ideas through to the end, and privilege.  In particular, we dive pretty deep on: How do you get started as an entrepreneur?  Clever Beagle The Meteor Chef Where are people getting stuck on the builds?  Fear, unknowns Simple, but not easy  Drive and ability to step into the unknown Survival of the fittest Hire before you are already  Losing your marbles Starting on a smaller scale How do I know my idea is going to work?  Book - Brick by Brick Multiple lines of business Managing a portfolio of business  Revenue streams  Marketing  Quitter When do I quit?  6-12 months of cash before you quit Making mistakes in entrepreneurship? Be a reader and study Go out a read books!  Experiential not taught  Luck and Privilege Video - Life of Privilege Explained in a $100 Race Procrastinate on Purpose And much more!  Links: Clever Beagle  The Meteor Chef https://www.linkedin.com/in/ryangglover http://www.ryanglover.net Brick by Brick Quitter Procrastinate on Purpose Do Thing That Don’t Scale @rglover Picks: Cory The Power of Moments The 50th Law Charles ReactDevSummit.com Indiegogo for Dev Chat .NetRocks Aimee Life of Privilege Explained in a $100 Race Joe Everybody Lies Murder on the Orient Express   Ryan Turning Pro - Steven Pressfield series The Power of Beliefs in Business

Devchat.tv Master Feed
JSJ 295: Developers as Entrepreneurs with Ryan Glover

Devchat.tv Master Feed

Play Episode Listen Later Jan 8, 2018 65:42


Panel:  Charles Max Wood  Cory House Joe Eames Aimee Knight   Special Guests: Ryan Glover In this episode, JavaScript Jabber panelist speak with Ryan Glover. Ryan is on JavaScript Jabber to talks about Entrepreneurship as a developer.  Ryan runs Clever Beagle in Chicago Illinois. Clever Beagle is a mentorship company that helps people build their first software Product. Ryan and the panel discuss the many roads of entrepreneurship, startup business ideas, servicing and teaching the community, how to’s, and psychological challenges, hiring, seeing your ideas through to the end, and privilege.  In particular, we dive pretty deep on: How do you get started as an entrepreneur?  Clever Beagle The Meteor Chef Where are people getting stuck on the builds?  Fear, unknowns Simple, but not easy  Drive and ability to step into the unknown Survival of the fittest Hire before you are already  Losing your marbles Starting on a smaller scale How do I know my idea is going to work?  Book - Brick by Brick Multiple lines of business Managing a portfolio of business  Revenue streams  Marketing  Quitter When do I quit?  6-12 months of cash before you quit Making mistakes in entrepreneurship? Be a reader and study Go out a read books!  Experiential not taught  Luck and Privilege Video - Life of Privilege Explained in a $100 Race Procrastinate on Purpose And much more!  Links: Clever Beagle  The Meteor Chef https://www.linkedin.com/in/ryangglover http://www.ryanglover.net Brick by Brick Quitter Procrastinate on Purpose Do Thing That Don’t Scale @rglover Picks: Cory The Power of Moments The 50th Law Charles ReactDevSummit.com Indiegogo for Dev Chat .NetRocks Aimee Life of Privilege Explained in a $100 Race Joe Everybody Lies Murder on the Orient Express   Ryan Turning Pro - Steven Pressfield series The Power of Beliefs in Business

IT Career Energizer
Stop Trying To Do It All with Cory House

IT Career Energizer

Play Episode Listen Later Nov 19, 2017 17:04


Cory House is a Pluralsight author, Microsoft Most Valuable Professional, Software Architect, international speaker and principal at React JS Consulting. He has trained over 10,000 software developers at conferences and businesses worldwide on clean coding practices, front-end development, testing and software architecture. Cory currently specializes in JavaScript and front-end development using React. In this episode Cory talks about the impact that public speaking has had on his career progression and why multi-tasking can result in failure. Cory tells us about an unexpected success and why you shouldn’t be trying to do it all. To find out more about this episode, visit the show notes page at www.itcareerenergizer.com/e32

react javascript stop trying pluralsight software architect microsoft most valuable professional cory house
All JavaScript Podcasts by Devchat.tv
JSJ 282: Trails.js with Scott Wyatt

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Oct 10, 2017 45:31


Panel: Joe Amies Aimee Knight Charles Max Wood Cory House Special Guests:  Scott Wyatt In this episode, JavaScript Jabbers talk with Scott Wyatt. Scott is the Co-founder, CTO, UEX at Cali StyleTechnologies, and is a Node developer and graphic designer.  Scott is on JavaScript Jabber to talk about Trails.js. and its simplistic build, but many useful functions. Scott mentions that Trails.js was created by Travis Webb. Scott gives us an introduction to the Trails.js framework, as the Jabbers take apart and dive deep into the build, functions, and uses.  Scott goes into what trail packs are, and the similar or related projects. Scott talks about the ease of using trails to build with, and not ending up in frustration. In particular, we dive pretty deep on: Trails.js is Node Framework and lightweight or Blueprint Similar to Redux? Is it MVC like Rails You don’t need to understand it, it is all under the hood. Tuple Space Is this sole for server-side rendering? Closest projects - Sails Avoid problems like React. Not dealing with corporations Why would you want to use trails instead of other projects like Sails, rails, etc. How do you get started - trailjs.io Quickest way to learn Trails is to build a Trail Pack Don’t be afraid to kill you darlings Testing It Trails production ready? It is a particular type of app where Trails shines? Links trailsjs.io Travis Webb Picks Amy Full Stack Developers by Brad Frost Tracking Macros Joe The Behavior Gap Charles Profit First  Keto Diet scott-wyatt/GitHub   Cory Never write another high Order Component Scott Proxy Engine

JavaScript Jabber
JSJ 282: Trails.js with Scott Wyatt

JavaScript Jabber

Play Episode Listen Later Oct 10, 2017 45:31


Panel: Joe Amies Aimee Knight Charles Max Wood Cory House Special Guests:  Scott Wyatt In this episode, JavaScript Jabbers talk with Scott Wyatt. Scott is the Co-founder, CTO, UEX at Cali StyleTechnologies, and is a Node developer and graphic designer.  Scott is on JavaScript Jabber to talk about Trails.js. and its simplistic build, but many useful functions. Scott mentions that Trails.js was created by Travis Webb. Scott gives us an introduction to the Trails.js framework, as the Jabbers take apart and dive deep into the build, functions, and uses.  Scott goes into what trail packs are, and the similar or related projects. Scott talks about the ease of using trails to build with, and not ending up in frustration. In particular, we dive pretty deep on: Trails.js is Node Framework and lightweight or Blueprint Similar to Redux? Is it MVC like Rails You don’t need to understand it, it is all under the hood. Tuple Space Is this sole for server-side rendering? Closest projects - Sails Avoid problems like React. Not dealing with corporations Why would you want to use trails instead of other projects like Sails, rails, etc. How do you get started - trailjs.io Quickest way to learn Trails is to build a Trail Pack Don’t be afraid to kill you darlings Testing It Trails production ready? It is a particular type of app where Trails shines? Links trailsjs.io Travis Webb Picks Amy Full Stack Developers by Brad Frost Tracking Macros Joe The Behavior Gap Charles Profit First  Keto Diet scott-wyatt/GitHub   Cory Never write another high Order Component Scott Proxy Engine

Devchat.tv Master Feed
JSJ 282: Trails.js with Scott Wyatt

Devchat.tv Master Feed

Play Episode Listen Later Oct 10, 2017 45:31


Panel: Joe Amies Aimee Knight Charles Max Wood Cory House Special Guests:  Scott Wyatt In this episode, JavaScript Jabbers talk with Scott Wyatt. Scott is the Co-founder, CTO, UEX at Cali StyleTechnologies, and is a Node developer and graphic designer.  Scott is on JavaScript Jabber to talk about Trails.js. and its simplistic build, but many useful functions. Scott mentions that Trails.js was created by Travis Webb. Scott gives us an introduction to the Trails.js framework, as the Jabbers take apart and dive deep into the build, functions, and uses.  Scott goes into what trail packs are, and the similar or related projects. Scott talks about the ease of using trails to build with, and not ending up in frustration. In particular, we dive pretty deep on: Trails.js is Node Framework and lightweight or Blueprint Similar to Redux? Is it MVC like Rails You don’t need to understand it, it is all under the hood. Tuple Space Is this sole for server-side rendering? Closest projects - Sails Avoid problems like React. Not dealing with corporations Why would you want to use trails instead of other projects like Sails, rails, etc. How do you get started - trailjs.io Quickest way to learn Trails is to build a Trail Pack Don’t be afraid to kill you darlings Testing It Trails production ready? It is a particular type of app where Trails shines? Links trailsjs.io Travis Webb Picks Amy Full Stack Developers by Brad Frost Tracking Macros Joe The Behavior Gap Charles Profit First  Keto Diet scott-wyatt/GitHub   Cory Never write another high Order Component Scott Proxy Engine

Cross Cutting Concerns Podcast
Podcast 058 - Pete Shearer on React and Redux

Cross Cutting Concerns Podcast

Play Episode Listen Later Sep 10, 2017 13:09


Pete Shearer (aka Pete on Software) is building with React and Redux. Show Notes: Redux-synapse React SPA - Single Page Application XML literals in VB.NET StackOverflow thread about Virtual DOM & React Redux Redux has bindings for Angular, Vue, and Aurelia Flux MobX Ember, Backbone, Knockout, jQuery Some concepts you'll need to learn React: NPM, Webpack, Minify, Lint Create-react-app Web Bos - React for Beginners Steven Grider - Modern React with Redux Cory House - Pluralsight Pete mentioned underscore, but he meant to say lodash. I was on two episodes of Pete's podcast: Aspect Oriented Programming with Matthew Groves Matthew Groves on Couchbase Pete Shearer is on Twitter. Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.

All JavaScript Podcasts by Devchat.tv
JSJ 277: Dojo 2 with Dylan Schiemann and Kitson Kelly

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Sep 6, 2017 62:52


JSJ 277: Dojo 2 with Dylan Schiemann and Kitson Kelly This episode of JavaScript Jabber features panelists Aimee Knight, Cory House, and Charles Max Wood. They talk with Dylan Schiemann and Kitson Kelly about Dojo 2. [00:02:03] Introduction to Dylan Schiemann Dylan is the CEO at Sitepen and co-founder of the Dojo Toolkit. [00:02:22] Introduction to Kitson  Kitson is the CTO at Sitepen and project lead for Dojo 2. [00:02:43] Elevator Pitch for Dojo Dojo 1 has been around forever. Started back in 2004 as a way to solve the challenge of "I want to build something cool in a browser." Promises and web components were inspired by or created by Dojo. It's been a huge influence on the web development community. Dojo 2 is a ground up re-write with ES 2015, TypeScript and modern API's. It's a modernized framework for Enterprise applications. [00:04:29] How is Dojo different from other frameworks? There's a spectrum: small libraries like React with an ecosystem and community of things you add to it to Angular which is closer to the MV* framework with bi-directional data binding. Vue lands somewhere in the middle. Dojo 2 is also somewhere in the middle as well. It's written in TypeScript and has embraced the TypeScript experience. [00:06:00] Did the Angular 2 move influence the Dojo 2 development and vice-versa? Dojo 2 had moved to TypeScript and 2 days later Angular announced that they were going to TypeScript. Angular also moved very quickly through their BETA phase, which caused some challenges for the Angular community. With Dojo 2, they didn't start the public discussion and BETA until they knew much better what was and wasn't going to change. They've also been talking about Dojo 2 for 6 or 7 years. The update was held up by adoption of ES6 and other technologies. Dojo 1 was also responsible for a lot of the low-level underpinning that Angular didn't have to innovate on. Dojo 2 was built around a mature understanding of how web applications are built now. People doing Enterprise need a little more help and assistance from their framework. Dojo provides a much more feature rich set of capabilities. Angular could have pushed much more of TypeScript's power through to the developer experience. Dojo much more fully adopts it. It's also easier if all of your packages have the same version number. Call out to Angular 4 vs Angular 2. [00:12:44] AMD Modules Why use AMD instead of ES6 modules? You can use both. Dojo 2 was involved in the creation of UMD. James Burke created UMD while working on Dojo. ES6 modules and module loading systems weren't entirely baked when Dojo 2 started to reach maturity, so they went with UMD. It's only been a few months since Safari implemented the ES6 module system. Firefox and friends are still playing catchup. The Dojo CLI build tool uses webpack, so it's mostly invisible at this point. So, at this point, should I be using UMD modules? or ES6? Is there an advantage to using AMD? With TypeScript you'd use ES6 modules, but UMD modules can be loaded on the fly. [00:16:00] Are you using Grunt? Internally, for tasks we use Grunt. But for users, we have a CLI tool that wraps around Webpack. For package builds and CI, Grunt is used. [00:18:30] What is the focus on Enterprise all about? There are a lot of different challenges and complexities to building Enterprise apps. Dojo was the first framework with internationalization, large data grids, SVG charts, etc. Dojo has spend a long time getting this right. Many other systems don't handle all the edge cases. Internationalization in Angular 2 or 4 seems unfinished. Most Dojo users are building for enterprises like banks and using the features that handle large amounts of data and handle those use cases better. [00:21:05] If most application frameworks have the features you listed, is there a set of problems it excels at? The Dojo team had a hard look at whether there was a need for their framework since many frameworks allow you to build great applications. Do we want to invest into something like this? React has internationalization libraries. But you'll spend a lot of time deciding which library to use and how well it'll integrate with everything else. A tradeoff in decision fatigue. In the Enterprise, development isn't sexy. It's necessary and wants to use boring but reliable technology. They like to throw bodies at a problem and that requires reliable frameworks with easily understood decision points. Producing code right is a strong case for TypeScript and they pull that through to the end user. Many frameworks start solving a small set of problems, become popular, and then bolt on what they need to solve everything else... Dojo tried to make sure it had the entire package in a clear, easy to use way. You can build great apps with most of the big frameworks out there. Dojo has been doing this for long enough that they know where to optimize for maintainability and performance. [00:29:00] Where is Dojo's sweet spot?  The Sitepen Blog series on picking a framework The biggest reason for using Dojo over the years is the data grid component. They also claim to have the best TypeScript web development experience. You may also want a component based system with the composition hassles of React. The composability of components where one team may write components that another uses is a big thing in Dojo where one person doesn't know the entire app you're working on. Theming systems is another selling point for Dojo. [00:34:10] Ending the framework wars Try Dojo out and try out the grid component and then export it to your Angular or React app. There are a lot of frameworks out there that do a great job for the people who use them. The focus is on how to build applications better, rather than beating out the competition. Sitepen has build apps with Dojo 2, Angular, React, Dojo + Redux, etc. [00:39:01] The Virtual DOM used by Dojo 2 years ago or so they were looking for a Virtual DOM library that was small and written in TypeScript. They settled on Maquette. The more you deal with the DOM directly, the more complex your components and libraries become. Makes things simpler for cases like server side rendering getting fleshed out in BETA 3. It also allows you to move toward something like React Native and WebVR components that aren't coupled to the DOM. They moved away from RxJS because they only wanted observables and shimmed in (or polyfilled) the ES-Next implementation instead of getting the rest of the RxJS  that they're not using. [00:46:40] What's coming next? They're finishing Dojo 2. They're polishing the system for build UI components and architecture and structuring the app. They plan to release before the end of the year. They're also wrapping up development on the Data Grid, which only renders what shows on the screen plus a little instead of millions of rows. [00:49:08] Testing They've got intern. It pulls together unit testing, functional testing, continuous integration hooks, accessibility testing, etc. It's rewritten in TypeScript to take advantage of modern JavaScript. The Dojo CLI uses intern as the default test framework. Kitson build the test-extras library to help with Dojo testing with intern. Dojo Links dojo.io github.com/dojo/meta sitepen.com/blog gitter channel github.com/dylans twitter.com/dylans twitter.com/sitepen twitter.com/dojo github.com/kitsonk twitter.com/kitsonk Picks Cory Amateur vs Professional Aimee DevFest Florida (use code 'jsjabber') Chuck Taking some time off AudioTechnica ATR2100 How to define your life purpose in 5 minutes Dylan zenhub HalfStack Conference How to choose a framework series on the Sitepen Blog Kitson Dunbar Number  

Devchat.tv Master Feed
JSJ 277: Dojo 2 with Dylan Schiemann and Kitson Kelly

Devchat.tv Master Feed

Play Episode Listen Later Sep 5, 2017 62:52


JSJ 277: Dojo 2 with Dylan Schiemann and Kitson Kelly This episode of JavaScript Jabber features panelists Aimee Knight, Cory House, and Charles Max Wood. They talk with Dylan Schiemann and Kitson Kelly about Dojo 2. [00:02:03] Introduction to Dylan Schiemann Dylan is the CEO at Sitepen and co-founder of the Dojo Toolkit. [00:02:22] Introduction to Kitson  Kitson is the CTO at Sitepen and project lead for Dojo 2. [00:02:43] Elevator Pitch for Dojo Dojo 1 has been around forever. Started back in 2004 as a way to solve the challenge of "I want to build something cool in a browser." Promises and web components were inspired by or created by Dojo. It's been a huge influence on the web development community. Dojo 2 is a ground up re-write with ES 2015, TypeScript and modern API's. It's a modernized framework for Enterprise applications. [00:04:29] How is Dojo different from other frameworks? There's a spectrum: small libraries like React with an ecosystem and community of things you add to it to Angular which is closer to the MV* framework with bi-directional data binding. Vue lands somewhere in the middle. Dojo 2 is also somewhere in the middle as well. It's written in TypeScript and has embraced the TypeScript experience. [00:06:00] Did the Angular 2 move influence the Dojo 2 development and vice-versa? Dojo 2 had moved to TypeScript and 2 days later Angular announced that they were going to TypeScript. Angular also moved very quickly through their BETA phase, which caused some challenges for the Angular community. With Dojo 2, they didn't start the public discussion and BETA until they knew much better what was and wasn't going to change. They've also been talking about Dojo 2 for 6 or 7 years. The update was held up by adoption of ES6 and other technologies. Dojo 1 was also responsible for a lot of the low-level underpinning that Angular didn't have to innovate on. Dojo 2 was built around a mature understanding of how web applications are built now. People doing Enterprise need a little more help and assistance from their framework. Dojo provides a much more feature rich set of capabilities. Angular could have pushed much more of TypeScript's power through to the developer experience. Dojo much more fully adopts it. It's also easier if all of your packages have the same version number. Call out to Angular 4 vs Angular 2. [00:12:44] AMD Modules Why use AMD instead of ES6 modules? You can use both. Dojo 2 was involved in the creation of UMD. James Burke created UMD while working on Dojo. ES6 modules and module loading systems weren't entirely baked when Dojo 2 started to reach maturity, so they went with UMD. It's only been a few months since Safari implemented the ES6 module system. Firefox and friends are still playing catchup. The Dojo CLI build tool uses webpack, so it's mostly invisible at this point. So, at this point, should I be using UMD modules? or ES6? Is there an advantage to using AMD? With TypeScript you'd use ES6 modules, but UMD modules can be loaded on the fly. [00:16:00] Are you using Grunt? Internally, for tasks we use Grunt. But for users, we have a CLI tool that wraps around Webpack. For package builds and CI, Grunt is used. [00:18:30] What is the focus on Enterprise all about? There are a lot of different challenges and complexities to building Enterprise apps. Dojo was the first framework with internationalization, large data grids, SVG charts, etc. Dojo has spend a long time getting this right. Many other systems don't handle all the edge cases. Internationalization in Angular 2 or 4 seems unfinished. Most Dojo users are building for enterprises like banks and using the features that handle large amounts of data and handle those use cases better. [00:21:05] If most application frameworks have the features you listed, is there a set of problems it excels at? The Dojo team had a hard look at whether there was a need for their framework since many frameworks allow you to build great applications. Do we want to invest into something like this? React has internationalization libraries. But you'll spend a lot of time deciding which library to use and how well it'll integrate with everything else. A tradeoff in decision fatigue. In the Enterprise, development isn't sexy. It's necessary and wants to use boring but reliable technology. They like to throw bodies at a problem and that requires reliable frameworks with easily understood decision points. Producing code right is a strong case for TypeScript and they pull that through to the end user. Many frameworks start solving a small set of problems, become popular, and then bolt on what they need to solve everything else... Dojo tried to make sure it had the entire package in a clear, easy to use way. You can build great apps with most of the big frameworks out there. Dojo has been doing this for long enough that they know where to optimize for maintainability and performance. [00:29:00] Where is Dojo's sweet spot?  The Sitepen Blog series on picking a framework The biggest reason for using Dojo over the years is the data grid component. They also claim to have the best TypeScript web development experience. You may also want a component based system with the composition hassles of React. The composability of components where one team may write components that another uses is a big thing in Dojo where one person doesn't know the entire app you're working on. Theming systems is another selling point for Dojo. [00:34:10] Ending the framework wars Try Dojo out and try out the grid component and then export it to your Angular or React app. There are a lot of frameworks out there that do a great job for the people who use them. The focus is on how to build applications better, rather than beating out the competition. Sitepen has build apps with Dojo 2, Angular, React, Dojo + Redux, etc. [00:39:01] The Virtual DOM used by Dojo 2 years ago or so they were looking for a Virtual DOM library that was small and written in TypeScript. They settled on Maquette. The more you deal with the DOM directly, the more complex your components and libraries become. Makes things simpler for cases like server side rendering getting fleshed out in BETA 3. It also allows you to move toward something like React Native and WebVR components that aren't coupled to the DOM. They moved away from RxJS because they only wanted observables and shimmed in (or polyfilled) the ES-Next implementation instead of getting the rest of the RxJS  that they're not using. [00:46:40] What's coming next? They're finishing Dojo 2. They're polishing the system for build UI components and architecture and structuring the app. They plan to release before the end of the year. They're also wrapping up development on the Data Grid, which only renders what shows on the screen plus a little instead of millions of rows. [00:49:08] Testing They've got intern. It pulls together unit testing, functional testing, continuous integration hooks, accessibility testing, etc. It's rewritten in TypeScript to take advantage of modern JavaScript. The Dojo CLI uses intern as the default test framework. Kitson build the test-extras library to help with Dojo testing with intern. Dojo Links dojo.io github.com/dojo/meta sitepen.com/blog gitter channel github.com/dylans twitter.com/dylans twitter.com/sitepen twitter.com/dojo github.com/kitsonk twitter.com/kitsonk Picks Cory Amateur vs Professional Aimee DevFest Florida (use code 'jsjabber') Chuck Taking some time off AudioTechnica ATR2100 How to define your life purpose in 5 minutes Dylan zenhub HalfStack Conference How to choose a framework series on the Sitepen Blog Kitson Dunbar Number  

JavaScript Jabber
JSJ 277: Dojo 2 with Dylan Schiemann and Kitson Kelly

JavaScript Jabber

Play Episode Listen Later Sep 5, 2017 62:52


JSJ 277: Dojo 2 with Dylan Schiemann and Kitson Kelly This episode of JavaScript Jabber features panelists Aimee Knight, Cory House, and Charles Max Wood. They talk with Dylan Schiemann and Kitson Kelly about Dojo 2. [00:02:03] Introduction to Dylan Schiemann Dylan is the CEO at Sitepen and co-founder of the Dojo Toolkit. [00:02:22] Introduction to Kitson  Kitson is the CTO at Sitepen and project lead for Dojo 2. [00:02:43] Elevator Pitch for Dojo Dojo 1 has been around forever. Started back in 2004 as a way to solve the challenge of "I want to build something cool in a browser." Promises and web components were inspired by or created by Dojo. It's been a huge influence on the web development community. Dojo 2 is a ground up re-write with ES 2015, TypeScript and modern API's. It's a modernized framework for Enterprise applications. [00:04:29] How is Dojo different from other frameworks? There's a spectrum: small libraries like React with an ecosystem and community of things you add to it to Angular which is closer to the MV* framework with bi-directional data binding. Vue lands somewhere in the middle. Dojo 2 is also somewhere in the middle as well. It's written in TypeScript and has embraced the TypeScript experience. [00:06:00] Did the Angular 2 move influence the Dojo 2 development and vice-versa? Dojo 2 had moved to TypeScript and 2 days later Angular announced that they were going to TypeScript. Angular also moved very quickly through their BETA phase, which caused some challenges for the Angular community. With Dojo 2, they didn't start the public discussion and BETA until they knew much better what was and wasn't going to change. They've also been talking about Dojo 2 for 6 or 7 years. The update was held up by adoption of ES6 and other technologies. Dojo 1 was also responsible for a lot of the low-level underpinning that Angular didn't have to innovate on. Dojo 2 was built around a mature understanding of how web applications are built now. People doing Enterprise need a little more help and assistance from their framework. Dojo provides a much more feature rich set of capabilities. Angular could have pushed much more of TypeScript's power through to the developer experience. Dojo much more fully adopts it. It's also easier if all of your packages have the same version number. Call out to Angular 4 vs Angular 2. [00:12:44] AMD Modules Why use AMD instead of ES6 modules? You can use both. Dojo 2 was involved in the creation of UMD. James Burke created UMD while working on Dojo. ES6 modules and module loading systems weren't entirely baked when Dojo 2 started to reach maturity, so they went with UMD. It's only been a few months since Safari implemented the ES6 module system. Firefox and friends are still playing catchup. The Dojo CLI build tool uses webpack, so it's mostly invisible at this point. So, at this point, should I be using UMD modules? or ES6? Is there an advantage to using AMD? With TypeScript you'd use ES6 modules, but UMD modules can be loaded on the fly. [00:16:00] Are you using Grunt? Internally, for tasks we use Grunt. But for users, we have a CLI tool that wraps around Webpack. For package builds and CI, Grunt is used. [00:18:30] What is the focus on Enterprise all about? There are a lot of different challenges and complexities to building Enterprise apps. Dojo was the first framework with internationalization, large data grids, SVG charts, etc. Dojo has spend a long time getting this right. Many other systems don't handle all the edge cases. Internationalization in Angular 2 or 4 seems unfinished. Most Dojo users are building for enterprises like banks and using the features that handle large amounts of data and handle those use cases better. [00:21:05] If most application frameworks have the features you listed, is there a set of problems it excels at? The Dojo team had a hard look at whether there was a need for their framework since many frameworks allow you to build great applications. Do we want to invest into something like this? React has internationalization libraries. But you'll spend a lot of time deciding which library to use and how well it'll integrate with everything else. A tradeoff in decision fatigue. In the Enterprise, development isn't sexy. It's necessary and wants to use boring but reliable technology. They like to throw bodies at a problem and that requires reliable frameworks with easily understood decision points. Producing code right is a strong case for TypeScript and they pull that through to the end user. Many frameworks start solving a small set of problems, become popular, and then bolt on what they need to solve everything else... Dojo tried to make sure it had the entire package in a clear, easy to use way. You can build great apps with most of the big frameworks out there. Dojo has been doing this for long enough that they know where to optimize for maintainability and performance. [00:29:00] Where is Dojo's sweet spot?  The Sitepen Blog series on picking a framework The biggest reason for using Dojo over the years is the data grid component. They also claim to have the best TypeScript web development experience. You may also want a component based system with the composition hassles of React. The composability of components where one team may write components that another uses is a big thing in Dojo where one person doesn't know the entire app you're working on. Theming systems is another selling point for Dojo. [00:34:10] Ending the framework wars Try Dojo out and try out the grid component and then export it to your Angular or React app. There are a lot of frameworks out there that do a great job for the people who use them. The focus is on how to build applications better, rather than beating out the competition. Sitepen has build apps with Dojo 2, Angular, React, Dojo + Redux, etc. [00:39:01] The Virtual DOM used by Dojo 2 years ago or so they were looking for a Virtual DOM library that was small and written in TypeScript. They settled on Maquette. The more you deal with the DOM directly, the more complex your components and libraries become. Makes things simpler for cases like server side rendering getting fleshed out in BETA 3. It also allows you to move toward something like React Native and WebVR components that aren't coupled to the DOM. They moved away from RxJS because they only wanted observables and shimmed in (or polyfilled) the ES-Next implementation instead of getting the rest of the RxJS  that they're not using. [00:46:40] What's coming next? They're finishing Dojo 2. They're polishing the system for build UI components and architecture and structuring the app. They plan to release before the end of the year. They're also wrapping up development on the Data Grid, which only renders what shows on the screen plus a little instead of millions of rows. [00:49:08] Testing They've got intern. It pulls together unit testing, functional testing, continuous integration hooks, accessibility testing, etc. It's rewritten in TypeScript to take advantage of modern JavaScript. The Dojo CLI uses intern as the default test framework. Kitson build the test-extras library to help with Dojo testing with intern. Dojo Links dojo.io github.com/dojo/meta sitepen.com/blog gitter channel github.com/dylans twitter.com/dylans twitter.com/sitepen twitter.com/dojo github.com/kitsonk twitter.com/kitsonk Picks Cory Amateur vs Professional Aimee DevFest Florida (use code 'jsjabber') Chuck Taking some time off AudioTechnica ATR2100 How to define your life purpose in 5 minutes Dylan zenhub HalfStack Conference How to choose a framework series on the Sitepen Blog Kitson Dunbar Number  

All JavaScript Podcasts by Devchat.tv
JSJ 275: Zones in Node with Austin McDaniel

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Aug 22, 2017 31:44


JSJ 275: Zones in Node with Austin McDaniel The panel for this week on JavaScript Jabber is Cory House, Aimee Knight, and Charles Max Wood. They speak with special guest Austin McDaniel about Zones in Node. Tune in to learn more about this topic! [00:01:11] Introduction to Austin Austin has worked in JavaScript for the past ten years. He currently works in Angular development and is a panelist on Angular Air. He has spent most of his career doing work in front-end development but has recently begun working with back-end development. With his move to back-end work he has incorporated front-end ideas with Angular into a back-end concept. [00:02:00] The Way it Works NodeJS is an event loop. There is no way to scope the context of a call stack. So for example, Austin makes a Node request to a server and wants to track the life cycle of that Node request. Once deep in the scope, or deep in the code, it is not easy to get the unique id. Maybe he wants to get the user from Passport JS. Other languages – Python, Java – have a concept called thread local storage. They can associate context with the thread and throughout the life cycle of that request, he can retrieve that context. There is a TC39 proposal for zones. A zone allows you to do what was just described. They can create new zones and associate data with them. Zones can also associate unique ids for requests and can associate the user so they can see who requested later in the stack. Zones also allow to scope and create a context. And then it allows scoping requests and capturing contacts all the way down. [00:05:40] Zone Uses One way Zone is being used is to capture stack traces, and associating unique ids with the requests. If there is an error, then Zone can capture a stack request and associate that back to the request that happened. Otherwise, the error would be vague. Zones are a TC39 proposal. Because it is still a proposal people are unsure how they can use it. Zones are not a new concept. Austin first saw Zones being used back when Angular 2 was first conceived. If an event happened and they wanted to isolate a component and create a scope for it, they used Zones to do so. Not a huge fan of how it worked out (quirky). He used the same library that Angular uses in his backend. It is a specific implementation for Node. Monkey patches all of the functions and creates a scope and passes it down to your functions, which does a good job capturing the information. [00:08:40] Is installing the library all you need to get this started? Yes, go to npminstallzone.js and install the library. There is a middler function for kla. To fork the zone, typing zone.current. This takes the Zone you are in and creates a new isolated Zone for that fork. A name can then be created for the Zone so it can be associated back with a call stack and assigned properties. Later, any properties can be retrieved no matter what level you are at. [00:09:50] So did you create the Zone library or did Google? The Google team created the Zone library. It was introduced in 2014 with Angular 2. It is currently used in front-end development. [00:10:12] Is the TC39 proposal based on the Zone library? While Austin has a feeling that the TC39 proposal came out of the Zone library, he cannot say for sure. [00:10:39] What stage is the proposal in right now? Zone is in Stage Zero right now. Zone JS is the most popular version because of its forced adoption to Angular. He recommends people use the Angular version because it is the most tested as it has a high number of people using it for front-end development. [00:11:50] Is there an easy way to copy the information from one thread to another? Yes. The best way would probably be to manually copy the information. Forking it may also work. [00:14:18] Is Stage Zero where someone is still looking to put it in or is it imminent? Austin believes that since it is actually in a stage, it means it is going to happen eventually but could be wrong. He assumes that it is going to be similar to the version that is out now. Aimee read that Stage Zero is the implementation stage where developers are gathering input about the product. Austin says that this basically means, “Implementation may vary. Enter at your own risk.” [00:16:21] If I’m using New Relic, is it using Zone JS under the hood? Austin is unsure but there something like that has to be done if profiling is being used. There has to be a way that you insert yourself in between calls. Zone is doing that while providing context, but probably not using Zone JS. There is a similar implementation to tracing and inserting logging in between all calls and timeouts. [00:17:22] What are the nuances? Why isn’t everybody doing this? Zone is still new in the JavaScript world, meaning everyone has a ton of ideas about what should be done. It can be frustrating to work with Zone in front-end development because it has to be manually learned. But in terms of implementation, only trying to create a context. Austin recommends Zone if people want to create direct contacts. The exception would be 100 lines of Zone traces because they can get difficult. Another issue Austin has is Node’s native basic weight. Weight hooks are still up in the air. The team is currently waiting on the Node JS community to provide additional information so that they can finish. Context can get lost sometimes if the wrong language is used. He is using Typescript and doesn’t have that problem because it is straightforward. [00:21:44:] Does this affect your ability to test your software at all? No, there have not been any issues with testing. One thing to accommodate for is if you are expecting certain contexts to be present you have to mock for those in the tests. After that happens, the tests should have no problems. Picks Cory: Apple AirPods Aimee:​ Blackmill Understanding Zones Charles: Classical Reading Playlist on Amazon Building stairs for his dad Angular Dev Summit  Austin: NGRX Library Redux  Links Twitter GitHub

JavaScript Jabber
JSJ 275: Zones in Node with Austin McDaniel

JavaScript Jabber

Play Episode Listen Later Aug 22, 2017 31:44


JSJ 275: Zones in Node with Austin McDaniel The panel for this week on JavaScript Jabber is Cory House, Aimee Knight, and Charles Max Wood. They speak with special guest Austin McDaniel about Zones in Node. Tune in to learn more about this topic! [00:01:11] Introduction to Austin Austin has worked in JavaScript for the past ten years. He currently works in Angular development and is a panelist on Angular Air. He has spent most of his career doing work in front-end development but has recently begun working with back-end development. With his move to back-end work he has incorporated front-end ideas with Angular into a back-end concept. [00:02:00] The Way it Works NodeJS is an event loop. There is no way to scope the context of a call stack. So for example, Austin makes a Node request to a server and wants to track the life cycle of that Node request. Once deep in the scope, or deep in the code, it is not easy to get the unique id. Maybe he wants to get the user from Passport JS. Other languages – Python, Java – have a concept called thread local storage. They can associate context with the thread and throughout the life cycle of that request, he can retrieve that context. There is a TC39 proposal for zones. A zone allows you to do what was just described. They can create new zones and associate data with them. Zones can also associate unique ids for requests and can associate the user so they can see who requested later in the stack. Zones also allow to scope and create a context. And then it allows scoping requests and capturing contacts all the way down. [00:05:40] Zone Uses One way Zone is being used is to capture stack traces, and associating unique ids with the requests. If there is an error, then Zone can capture a stack request and associate that back to the request that happened. Otherwise, the error would be vague. Zones are a TC39 proposal. Because it is still a proposal people are unsure how they can use it. Zones are not a new concept. Austin first saw Zones being used back when Angular 2 was first conceived. If an event happened and they wanted to isolate a component and create a scope for it, they used Zones to do so. Not a huge fan of how it worked out (quirky). He used the same library that Angular uses in his backend. It is a specific implementation for Node. Monkey patches all of the functions and creates a scope and passes it down to your functions, which does a good job capturing the information. [00:08:40] Is installing the library all you need to get this started? Yes, go to npminstallzone.js and install the library. There is a middler function for kla. To fork the zone, typing zone.current. This takes the Zone you are in and creates a new isolated Zone for that fork. A name can then be created for the Zone so it can be associated back with a call stack and assigned properties. Later, any properties can be retrieved no matter what level you are at. [00:09:50] So did you create the Zone library or did Google? The Google team created the Zone library. It was introduced in 2014 with Angular 2. It is currently used in front-end development. [00:10:12] Is the TC39 proposal based on the Zone library? While Austin has a feeling that the TC39 proposal came out of the Zone library, he cannot say for sure. [00:10:39] What stage is the proposal in right now? Zone is in Stage Zero right now. Zone JS is the most popular version because of its forced adoption to Angular. He recommends people use the Angular version because it is the most tested as it has a high number of people using it for front-end development. [00:11:50] Is there an easy way to copy the information from one thread to another? Yes. The best way would probably be to manually copy the information. Forking it may also work. [00:14:18] Is Stage Zero where someone is still looking to put it in or is it imminent? Austin believes that since it is actually in a stage, it means it is going to happen eventually but could be wrong. He assumes that it is going to be similar to the version that is out now. Aimee read that Stage Zero is the implementation stage where developers are gathering input about the product. Austin says that this basically means, “Implementation may vary. Enter at your own risk.” [00:16:21] If I’m using New Relic, is it using Zone JS under the hood? Austin is unsure but there something like that has to be done if profiling is being used. There has to be a way that you insert yourself in between calls. Zone is doing that while providing context, but probably not using Zone JS. There is a similar implementation to tracing and inserting logging in between all calls and timeouts. [00:17:22] What are the nuances? Why isn’t everybody doing this? Zone is still new in the JavaScript world, meaning everyone has a ton of ideas about what should be done. It can be frustrating to work with Zone in front-end development because it has to be manually learned. But in terms of implementation, only trying to create a context. Austin recommends Zone if people want to create direct contacts. The exception would be 100 lines of Zone traces because they can get difficult. Another issue Austin has is Node’s native basic weight. Weight hooks are still up in the air. The team is currently waiting on the Node JS community to provide additional information so that they can finish. Context can get lost sometimes if the wrong language is used. He is using Typescript and doesn’t have that problem because it is straightforward. [00:21:44:] Does this affect your ability to test your software at all? No, there have not been any issues with testing. One thing to accommodate for is if you are expecting certain contexts to be present you have to mock for those in the tests. After that happens, the tests should have no problems. Picks Cory: Apple AirPods Aimee:​ Blackmill Understanding Zones Charles: Classical Reading Playlist on Amazon Building stairs for his dad Angular Dev Summit  Austin: NGRX Library Redux  Links Twitter GitHub

Devchat.tv Master Feed
JSJ 275: Zones in Node with Austin McDaniel

Devchat.tv Master Feed

Play Episode Listen Later Aug 22, 2017 31:44


JSJ 275: Zones in Node with Austin McDaniel The panel for this week on JavaScript Jabber is Cory House, Aimee Knight, and Charles Max Wood. They speak with special guest Austin McDaniel about Zones in Node. Tune in to learn more about this topic! [00:01:11] Introduction to Austin Austin has worked in JavaScript for the past ten years. He currently works in Angular development and is a panelist on Angular Air. He has spent most of his career doing work in front-end development but has recently begun working with back-end development. With his move to back-end work he has incorporated front-end ideas with Angular into a back-end concept. [00:02:00] The Way it Works NodeJS is an event loop. There is no way to scope the context of a call stack. So for example, Austin makes a Node request to a server and wants to track the life cycle of that Node request. Once deep in the scope, or deep in the code, it is not easy to get the unique id. Maybe he wants to get the user from Passport JS. Other languages – Python, Java – have a concept called thread local storage. They can associate context with the thread and throughout the life cycle of that request, he can retrieve that context. There is a TC39 proposal for zones. A zone allows you to do what was just described. They can create new zones and associate data with them. Zones can also associate unique ids for requests and can associate the user so they can see who requested later in the stack. Zones also allow to scope and create a context. And then it allows scoping requests and capturing contacts all the way down. [00:05:40] Zone Uses One way Zone is being used is to capture stack traces, and associating unique ids with the requests. If there is an error, then Zone can capture a stack request and associate that back to the request that happened. Otherwise, the error would be vague. Zones are a TC39 proposal. Because it is still a proposal people are unsure how they can use it. Zones are not a new concept. Austin first saw Zones being used back when Angular 2 was first conceived. If an event happened and they wanted to isolate a component and create a scope for it, they used Zones to do so. Not a huge fan of how it worked out (quirky). He used the same library that Angular uses in his backend. It is a specific implementation for Node. Monkey patches all of the functions and creates a scope and passes it down to your functions, which does a good job capturing the information. [00:08:40] Is installing the library all you need to get this started? Yes, go to npminstallzone.js and install the library. There is a middler function for kla. To fork the zone, typing zone.current. This takes the Zone you are in and creates a new isolated Zone for that fork. A name can then be created for the Zone so it can be associated back with a call stack and assigned properties. Later, any properties can be retrieved no matter what level you are at. [00:09:50] So did you create the Zone library or did Google? The Google team created the Zone library. It was introduced in 2014 with Angular 2. It is currently used in front-end development. [00:10:12] Is the TC39 proposal based on the Zone library? While Austin has a feeling that the TC39 proposal came out of the Zone library, he cannot say for sure. [00:10:39] What stage is the proposal in right now? Zone is in Stage Zero right now. Zone JS is the most popular version because of its forced adoption to Angular. He recommends people use the Angular version because it is the most tested as it has a high number of people using it for front-end development. [00:11:50] Is there an easy way to copy the information from one thread to another? Yes. The best way would probably be to manually copy the information. Forking it may also work. [00:14:18] Is Stage Zero where someone is still looking to put it in or is it imminent? Austin believes that since it is actually in a stage, it means it is going to happen eventually but could be wrong. He assumes that it is going to be similar to the version that is out now. Aimee read that Stage Zero is the implementation stage where developers are gathering input about the product. Austin says that this basically means, “Implementation may vary. Enter at your own risk.” [00:16:21] If I’m using New Relic, is it using Zone JS under the hood? Austin is unsure but there something like that has to be done if profiling is being used. There has to be a way that you insert yourself in between calls. Zone is doing that while providing context, but probably not using Zone JS. There is a similar implementation to tracing and inserting logging in between all calls and timeouts. [00:17:22] What are the nuances? Why isn’t everybody doing this? Zone is still new in the JavaScript world, meaning everyone has a ton of ideas about what should be done. It can be frustrating to work with Zone in front-end development because it has to be manually learned. But in terms of implementation, only trying to create a context. Austin recommends Zone if people want to create direct contacts. The exception would be 100 lines of Zone traces because they can get difficult. Another issue Austin has is Node’s native basic weight. Weight hooks are still up in the air. The team is currently waiting on the Node JS community to provide additional information so that they can finish. Context can get lost sometimes if the wrong language is used. He is using Typescript and doesn’t have that problem because it is straightforward. [00:21:44:] Does this affect your ability to test your software at all? No, there have not been any issues with testing. One thing to accommodate for is if you are expecting certain contexts to be present you have to mock for those in the tests. After that happens, the tests should have no problems. Picks Cory: Apple AirPods Aimee:​ Blackmill Understanding Zones Charles: Classical Reading Playlist on Amazon Building stairs for his dad Angular Dev Summit  Austin: NGRX Library Redux  Links Twitter GitHub

All JavaScript Podcasts by Devchat.tv
JSJ 273: Live to Code, Don't Code to Live with 2 Frugal Dudes Sean Merron and Kevin Griffin

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Aug 8, 2017 68:49


JSJ 273: Live to Code, Don't Code to Live with 2 Frugal Dudes Sean Merron and Kevin Griffin This episode of JavaScript Jabber features panelists Aimee Knight, Cory House, and Charles Max Wood. Special guests Sean Merron and Kevin Griffin discuss how to live frugally. Tune in to hear their advice! [00:02:14] Introduction to Sean and Kevin Sean and Kevin are the hosts of the 2 Frugal Dudes Podcast. They are middle class software engineers. Sean works a 9 to 5 job, while Kevin owns a small business called Swift Kick. Swift Kick is a company that focuses on independent consulting, software development, and training companies for software development. [00:05:50] Different Types of Financial Advisors There is no legal reason that financial advisors have to work in your best interest. On the 2 Frugal Dudes Podcast, Sean and Kevin advise people to use fiduciary advisors. These types of advisors are not legally allowed to accept kickbacks from different funds. This means that they are more likely to help you to the best of their ability. They get paid for their services. Laws are currently changing so that everyone has to be a fiduciary advisor unless clients sign a specific form. [00:10:00] What do I do with money left over at the end of the month that I can’t put into a 401K and Roth IRA? They suggest that you put only the amount of money in your 401K that your company will match. Then, put the rest into a Roth IRA and max that out. Before you decide to do what next, you need to decide why you are saving money. When will you need the money? What will you need it for? Once you know the answer to these questions, you will be able to assess what your money will best be placed. For example, if you are saving to buy a house you need to put your money in a safe investment. A Roth IRA can be used as a savings vehicle or as an emergency fund. Sean believes that a Bank CD is the safest return you can get. [00:14:30] Best Way to Save  For those who are self-employed, it is a good idea to have two emergency funds – a personal and a business fund. Business emergency funds should have five months of personal salary. Kevin built his up over two or three years and uses it as self-insurance. Sean says that the employee world is different. For him, he only keeps the minimum amount in his emergency fund. He knows that he is in a field where his job is in high demand, so feels comfortable with being able to get a job quickly. For others, this may not be the case. Have to evaluate how much to save based on how long you think you may need the money.  [00:18:50] What is the first thing people should be doing for their own financial well being? Kevin follows Dave Ramsey’s advice. Basic emergency fund. He uses $1,000. Most emergencies fall under that amount of money. Get rid of all consumer debt. This includes car payments, credit cards, and student loans. Mortgage is not consumer debt. Grow an emergency fund to three or six months of expenses. Investments. Setting up retirement funds, paying for college, or mortgages. Sean values early retirement so he focuses on that. What does retirement mean to me? What does rich mean? You should always track your money through a budget. Then you can funnel money towards emergency funds and tackling debt. Self-insurance means that you don’t have to worry about funds. It helps lower your stress knowing that you have your finances in order. It is a peaceful place to be and opens up opportunities for you. If someone has stressors in their life – for example, their car breaks down – and they have no money to fix it, they now have car and money problems. This stress can then potentially lead to other problems such as marriage problems. If the money to fix the broken car would have been there, it would alleviate stress. [00:28:23] Difference between 401k, IRA, and Roth IRAs A 401k is an employer provided, long-term retirement savings account. This is where you put in money before it is taxed. With this plan you are limited with the funds you can choose from to invest in. IRAs are long-term retirement plans as well. The first type of IRA is a Traditional IRA, which is similar to a 401k. You get tax reduction for the money you put in the account. You pay taxes once you withdraw money. A Roth IRA is where you already pay taxes on money that you are putting in, but don’t have to pay taxes when withdrawing money. You can withdraw contributions at anytime without being penalized, you just can’t take out any earnings. Another thing that is potentially good for early retirement is a Roth IRA conversion ladder. This is where you take money from a 401k and convert it into a Roth IRA and use it before 60 years old to fund early retirement. Traditional IRAs are good for business owners looking for tax deductions now. An HSA (Health Savings Account) can also be used as a retirement device. It goes towards medical expenses if needed. [00:34:20] Are there tools or algorithms I can use to figure this stuff out? There are some. Portfolio Visualizer allows you to choose different portfolio mixes and put different amounts of money in each one. Portfolio Charts is similar to Portfolio Visualizer but gives nice graphics. Sean created a JavaScript website to help people use to figure out early retirement. The hardest part is calculating return because you have to estimate what your return will be each year. [00:39:00] Put Your Money Somewhere The only bad investment is not making an investment. Even making a bad investment is better than not having any at all. Inflation eats away at money that is just sitting. [00:42:05] If you get one of these advisors what advice should you be looking for? Need someone that tries to understand your particular situation. “It depends” is very true and your advisor should know that. No two people will have the same financial goals. They should want to help reach your goals in the least costly way possible. Other things they should be able to do is be honest and help you control your emotions during upswings and downswings.  [00:47:08] Why index funds? As an investor, you can buy an index fund cheaper than buying the whole index. A mutual fund will try to buy and sell the stocks in that index in order to follow the index's performance. As an investor, you have the opportunity to buy into a mutual fund that handles it for you. You don’t have to independently invest in companies either. You can invest in an index instead that will look at, for example, top performing technology companies. It is usually a better value. [00:53:33] How much do I invest in my business verses putting money into a Roth IRA or 401k? Sean thinks it comes down to retirement goals. At some point you will want money to come in passively and retire in the future. If you can passively put X amount of dollars into your company then it can be looked at as a form of investment. Kevin evaluates his business goals every quarter. He creates a business budget based off of those goals. Picks Cory Random Walk Down Wall Street by Burton Malkiel  Rich Dad, Poor Dad by Robert Kiyosaki  Ego is the Enemy by Ryan Holiday Aimee Hacker News Thread – How to Not Bring Emotions Home With You Phantogram  Charles Money Master the Game by Tony Robbins  ELPs (Endorsed Local Providers) Dave Ramsey Sean The Little Book of Common Sense Investing by John Bogle Mr. Money Mustache Blog  www.mint.com Kevin Unshakable by Tony Robbins YNABS  The Millionaire Next Door by Thomas Stanley Links 2 Frugal Dudes Twitter Sean's Twitter Kevin's Twitter www.swiftkick.in www.kevgriffin.com http://earlyretirementroadmap.com/ 2 Frugal Dudes Podcast

Devchat.tv Master Feed
JSJ 273: Live to Code, Don't Code to Live with 2 Frugal Dudes Sean Merron and Kevin Griffin

Devchat.tv Master Feed

Play Episode Listen Later Aug 8, 2017 68:49


JSJ 273: Live to Code, Don't Code to Live with 2 Frugal Dudes Sean Merron and Kevin Griffin This episode of JavaScript Jabber features panelists Aimee Knight, Cory House, and Charles Max Wood. Special guests Sean Merron and Kevin Griffin discuss how to live frugally. Tune in to hear their advice! [00:02:14] Introduction to Sean and Kevin Sean and Kevin are the hosts of the 2 Frugal Dudes Podcast. They are middle class software engineers. Sean works a 9 to 5 job, while Kevin owns a small business called Swift Kick. Swift Kick is a company that focuses on independent consulting, software development, and training companies for software development. [00:05:50] Different Types of Financial Advisors There is no legal reason that financial advisors have to work in your best interest. On the 2 Frugal Dudes Podcast, Sean and Kevin advise people to use fiduciary advisors. These types of advisors are not legally allowed to accept kickbacks from different funds. This means that they are more likely to help you to the best of their ability. They get paid for their services. Laws are currently changing so that everyone has to be a fiduciary advisor unless clients sign a specific form. [00:10:00] What do I do with money left over at the end of the month that I can’t put into a 401K and Roth IRA? They suggest that you put only the amount of money in your 401K that your company will match. Then, put the rest into a Roth IRA and max that out. Before you decide to do what next, you need to decide why you are saving money. When will you need the money? What will you need it for? Once you know the answer to these questions, you will be able to assess what your money will best be placed. For example, if you are saving to buy a house you need to put your money in a safe investment. A Roth IRA can be used as a savings vehicle or as an emergency fund. Sean believes that a Bank CD is the safest return you can get. [00:14:30] Best Way to Save  For those who are self-employed, it is a good idea to have two emergency funds – a personal and a business fund. Business emergency funds should have five months of personal salary. Kevin built his up over two or three years and uses it as self-insurance. Sean says that the employee world is different. For him, he only keeps the minimum amount in his emergency fund. He knows that he is in a field where his job is in high demand, so feels comfortable with being able to get a job quickly. For others, this may not be the case. Have to evaluate how much to save based on how long you think you may need the money.  [00:18:50] What is the first thing people should be doing for their own financial well being? Kevin follows Dave Ramsey’s advice. Basic emergency fund. He uses $1,000. Most emergencies fall under that amount of money. Get rid of all consumer debt. This includes car payments, credit cards, and student loans. Mortgage is not consumer debt. Grow an emergency fund to three or six months of expenses. Investments. Setting up retirement funds, paying for college, or mortgages. Sean values early retirement so he focuses on that. What does retirement mean to me? What does rich mean? You should always track your money through a budget. Then you can funnel money towards emergency funds and tackling debt. Self-insurance means that you don’t have to worry about funds. It helps lower your stress knowing that you have your finances in order. It is a peaceful place to be and opens up opportunities for you. If someone has stressors in their life – for example, their car breaks down – and they have no money to fix it, they now have car and money problems. This stress can then potentially lead to other problems such as marriage problems. If the money to fix the broken car would have been there, it would alleviate stress. [00:28:23] Difference between 401k, IRA, and Roth IRAs A 401k is an employer provided, long-term retirement savings account. This is where you put in money before it is taxed. With this plan you are limited with the funds you can choose from to invest in. IRAs are long-term retirement plans as well. The first type of IRA is a Traditional IRA, which is similar to a 401k. You get tax reduction for the money you put in the account. You pay taxes once you withdraw money. A Roth IRA is where you already pay taxes on money that you are putting in, but don’t have to pay taxes when withdrawing money. You can withdraw contributions at anytime without being penalized, you just can’t take out any earnings. Another thing that is potentially good for early retirement is a Roth IRA conversion ladder. This is where you take money from a 401k and convert it into a Roth IRA and use it before 60 years old to fund early retirement. Traditional IRAs are good for business owners looking for tax deductions now. An HSA (Health Savings Account) can also be used as a retirement device. It goes towards medical expenses if needed. [00:34:20] Are there tools or algorithms I can use to figure this stuff out? There are some. Portfolio Visualizer allows you to choose different portfolio mixes and put different amounts of money in each one. Portfolio Charts is similar to Portfolio Visualizer but gives nice graphics. Sean created a JavaScript website to help people use to figure out early retirement. The hardest part is calculating return because you have to estimate what your return will be each year. [00:39:00] Put Your Money Somewhere The only bad investment is not making an investment. Even making a bad investment is better than not having any at all. Inflation eats away at money that is just sitting. [00:42:05] If you get one of these advisors what advice should you be looking for? Need someone that tries to understand your particular situation. “It depends” is very true and your advisor should know that. No two people will have the same financial goals. They should want to help reach your goals in the least costly way possible. Other things they should be able to do is be honest and help you control your emotions during upswings and downswings.  [00:47:08] Why index funds? As an investor, you can buy an index fund cheaper than buying the whole index. A mutual fund will try to buy and sell the stocks in that index in order to follow the index's performance. As an investor, you have the opportunity to buy into a mutual fund that handles it for you. You don’t have to independently invest in companies either. You can invest in an index instead that will look at, for example, top performing technology companies. It is usually a better value. [00:53:33] How much do I invest in my business verses putting money into a Roth IRA or 401k? Sean thinks it comes down to retirement goals. At some point you will want money to come in passively and retire in the future. If you can passively put X amount of dollars into your company then it can be looked at as a form of investment. Kevin evaluates his business goals every quarter. He creates a business budget based off of those goals. Picks Cory Random Walk Down Wall Street by Burton Malkiel  Rich Dad, Poor Dad by Robert Kiyosaki  Ego is the Enemy by Ryan Holiday Aimee Hacker News Thread – How to Not Bring Emotions Home With You Phantogram  Charles Money Master the Game by Tony Robbins  ELPs (Endorsed Local Providers) Dave Ramsey Sean The Little Book of Common Sense Investing by John Bogle Mr. Money Mustache Blog  www.mint.com Kevin Unshakable by Tony Robbins YNABS  The Millionaire Next Door by Thomas Stanley Links 2 Frugal Dudes Twitter Sean's Twitter Kevin's Twitter www.swiftkick.in www.kevgriffin.com http://earlyretirementroadmap.com/ 2 Frugal Dudes Podcast

JavaScript Jabber
JSJ 273: Live to Code, Don't Code to Live with 2 Frugal Dudes Sean Merron and Kevin Griffin

JavaScript Jabber

Play Episode Listen Later Aug 8, 2017 68:49


JSJ 273: Live to Code, Don't Code to Live with 2 Frugal Dudes Sean Merron and Kevin Griffin This episode of JavaScript Jabber features panelists Aimee Knight, Cory House, and Charles Max Wood. Special guests Sean Merron and Kevin Griffin discuss how to live frugally. Tune in to hear their advice! [00:02:14] Introduction to Sean and Kevin Sean and Kevin are the hosts of the 2 Frugal Dudes Podcast. They are middle class software engineers. Sean works a 9 to 5 job, while Kevin owns a small business called Swift Kick. Swift Kick is a company that focuses on independent consulting, software development, and training companies for software development. [00:05:50] Different Types of Financial Advisors There is no legal reason that financial advisors have to work in your best interest. On the 2 Frugal Dudes Podcast, Sean and Kevin advise people to use fiduciary advisors. These types of advisors are not legally allowed to accept kickbacks from different funds. This means that they are more likely to help you to the best of their ability. They get paid for their services. Laws are currently changing so that everyone has to be a fiduciary advisor unless clients sign a specific form. [00:10:00] What do I do with money left over at the end of the month that I can’t put into a 401K and Roth IRA? They suggest that you put only the amount of money in your 401K that your company will match. Then, put the rest into a Roth IRA and max that out. Before you decide to do what next, you need to decide why you are saving money. When will you need the money? What will you need it for? Once you know the answer to these questions, you will be able to assess what your money will best be placed. For example, if you are saving to buy a house you need to put your money in a safe investment. A Roth IRA can be used as a savings vehicle or as an emergency fund. Sean believes that a Bank CD is the safest return you can get. [00:14:30] Best Way to Save  For those who are self-employed, it is a good idea to have two emergency funds – a personal and a business fund. Business emergency funds should have five months of personal salary. Kevin built his up over two or three years and uses it as self-insurance. Sean says that the employee world is different. For him, he only keeps the minimum amount in his emergency fund. He knows that he is in a field where his job is in high demand, so feels comfortable with being able to get a job quickly. For others, this may not be the case. Have to evaluate how much to save based on how long you think you may need the money.  [00:18:50] What is the first thing people should be doing for their own financial well being? Kevin follows Dave Ramsey’s advice. Basic emergency fund. He uses $1,000. Most emergencies fall under that amount of money. Get rid of all consumer debt. This includes car payments, credit cards, and student loans. Mortgage is not consumer debt. Grow an emergency fund to three or six months of expenses. Investments. Setting up retirement funds, paying for college, or mortgages. Sean values early retirement so he focuses on that. What does retirement mean to me? What does rich mean? You should always track your money through a budget. Then you can funnel money towards emergency funds and tackling debt. Self-insurance means that you don’t have to worry about funds. It helps lower your stress knowing that you have your finances in order. It is a peaceful place to be and opens up opportunities for you. If someone has stressors in their life – for example, their car breaks down – and they have no money to fix it, they now have car and money problems. This stress can then potentially lead to other problems such as marriage problems. If the money to fix the broken car would have been there, it would alleviate stress. [00:28:23] Difference between 401k, IRA, and Roth IRAs A 401k is an employer provided, long-term retirement savings account. This is where you put in money before it is taxed. With this plan you are limited with the funds you can choose from to invest in. IRAs are long-term retirement plans as well. The first type of IRA is a Traditional IRA, which is similar to a 401k. You get tax reduction for the money you put in the account. You pay taxes once you withdraw money. A Roth IRA is where you already pay taxes on money that you are putting in, but don’t have to pay taxes when withdrawing money. You can withdraw contributions at anytime without being penalized, you just can’t take out any earnings. Another thing that is potentially good for early retirement is a Roth IRA conversion ladder. This is where you take money from a 401k and convert it into a Roth IRA and use it before 60 years old to fund early retirement. Traditional IRAs are good for business owners looking for tax deductions now. An HSA (Health Savings Account) can also be used as a retirement device. It goes towards medical expenses if needed. [00:34:20] Are there tools or algorithms I can use to figure this stuff out? There are some. Portfolio Visualizer allows you to choose different portfolio mixes and put different amounts of money in each one. Portfolio Charts is similar to Portfolio Visualizer but gives nice graphics. Sean created a JavaScript website to help people use to figure out early retirement. The hardest part is calculating return because you have to estimate what your return will be each year. [00:39:00] Put Your Money Somewhere The only bad investment is not making an investment. Even making a bad investment is better than not having any at all. Inflation eats away at money that is just sitting. [00:42:05] If you get one of these advisors what advice should you be looking for? Need someone that tries to understand your particular situation. “It depends” is very true and your advisor should know that. No two people will have the same financial goals. They should want to help reach your goals in the least costly way possible. Other things they should be able to do is be honest and help you control your emotions during upswings and downswings.  [00:47:08] Why index funds? As an investor, you can buy an index fund cheaper than buying the whole index. A mutual fund will try to buy and sell the stocks in that index in order to follow the index's performance. As an investor, you have the opportunity to buy into a mutual fund that handles it for you. You don’t have to independently invest in companies either. You can invest in an index instead that will look at, for example, top performing technology companies. It is usually a better value. [00:53:33] How much do I invest in my business verses putting money into a Roth IRA or 401k? Sean thinks it comes down to retirement goals. At some point you will want money to come in passively and retire in the future. If you can passively put X amount of dollars into your company then it can be looked at as a form of investment. Kevin evaluates his business goals every quarter. He creates a business budget based off of those goals. Picks Cory Random Walk Down Wall Street by Burton Malkiel  Rich Dad, Poor Dad by Robert Kiyosaki  Ego is the Enemy by Ryan Holiday Aimee Hacker News Thread – How to Not Bring Emotions Home With You Phantogram  Charles Money Master the Game by Tony Robbins  ELPs (Endorsed Local Providers) Dave Ramsey Sean The Little Book of Common Sense Investing by John Bogle Mr. Money Mustache Blog  www.mint.com Kevin Unshakable by Tony Robbins YNABS  The Millionaire Next Door by Thomas Stanley Links 2 Frugal Dudes Twitter Sean's Twitter Kevin's Twitter www.swiftkick.in www.kevgriffin.com http://earlyretirementroadmap.com/ 2 Frugal Dudes Podcast

JavaScript Jabber
JSJ 269 Reusable React and JavaScript Components with Cory House

JavaScript Jabber

Play Episode Listen Later Jul 11, 2017 57:44


JSJ 269 Reusable React and JavaScript Components with Cory House On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in! [00:01:35] – Overview We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done. Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.  [00:04:50] – Browser support issue The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components. Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead. [00:07:50] – Polymer The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.    [00:14:20] – Standards are dead No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library. Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about. [00:17:05] – Libraries making reusable components There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well. As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there [00:21:20] – Why opt for reusable components Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse. As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.   [00:31:20] – Rigid component vs. flexible component As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder. We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough. Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later. [00:36:00] – Reusable components The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously. We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue. [00:42:45] – Component development on teams Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need. [00:47:45] – Mobile to web crossover Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application. [00:50:00] – Challenge Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?" Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember. Picks Cory House Creating Reusable React Components on Pluralsight Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss Joe Eames UI-Router Persistence Aimee Knight Ask HN: People who completed a boot camp 3+ years ago, what are you doing now? NgAtlanta Charles Max Wood Upwork.com JSJ 269 Reusable React and JavaScript Components with Cory House On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in! [00:01:35] – Overview We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done. Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.  [00:04:50] – Browser support issue The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components. Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead. [00:07:50] – Polymer The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.    [00:14:20] – Standards are dead No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library. Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about. [00:17:05] – Libraries making reusable components There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well. As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there [00:21:20] – Why opt for reusable components Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse. As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.   [00:31:20] – Rigid component vs. flexible component As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder. We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough. Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later. [00:36:00] – Reusable components The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously. We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue. [00:42:45] – Component development on teams Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need. [00:47:45] – Mobile to web crossover Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application. [00:50:00] – Challenge Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?" Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember. Picks Cory House Creating Reusable React Components on Pluralsight Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss Joe Eames UI-Router Persistence Aimee Knight Ask HN: People who completed a boot camp 3+ years ago, what are you doing now? NgAtlanta Charles Max Wood Upwork.com

All JavaScript Podcasts by Devchat.tv
JSJ 269 Reusable React and JavaScript Components with Cory House

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jul 11, 2017 57:44


JSJ 269 Reusable React and JavaScript Components with Cory House On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in! [00:01:35] – Overview We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done. Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.  [00:04:50] – Browser support issue The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components. Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead. [00:07:50] – Polymer The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.    [00:14:20] – Standards are dead No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library. Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about. [00:17:05] – Libraries making reusable components There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well. As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there [00:21:20] – Why opt for reusable components Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse. As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.   [00:31:20] – Rigid component vs. flexible component As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder. We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough. Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later. [00:36:00] – Reusable components The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously. We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue. [00:42:45] – Component development on teams Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need. [00:47:45] – Mobile to web crossover Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application. [00:50:00] – Challenge Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?" Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember. Picks Cory House Creating Reusable React Components on Pluralsight Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss Joe Eames UI-Router Persistence Aimee Knight Ask HN: People who completed a boot camp 3+ years ago, what are you doing now? NgAtlanta Charles Max Wood Upwork.com JSJ 269 Reusable React and JavaScript Components with Cory House On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in! [00:01:35] – Overview We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done. Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.  [00:04:50] – Browser support issue The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components. Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead. [00:07:50] – Polymer The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.    [00:14:20] – Standards are dead No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library. Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about. [00:17:05] – Libraries making reusable components There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well. As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there [00:21:20] – Why opt for reusable components Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse. As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.   [00:31:20] – Rigid component vs. flexible component As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder. We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough. Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later. [00:36:00] – Reusable components The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously. We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue. [00:42:45] – Component development on teams Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need. [00:47:45] – Mobile to web crossover Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application. [00:50:00] – Challenge Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?" Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember. Picks Cory House Creating Reusable React Components on Pluralsight Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss Joe Eames UI-Router Persistence Aimee Knight Ask HN: People who completed a boot camp 3+ years ago, what are you doing now? NgAtlanta Charles Max Wood Upwork.com

Devchat.tv Master Feed
JSJ 269 Reusable React and JavaScript Components with Cory House

Devchat.tv Master Feed

Play Episode Listen Later Jul 11, 2017 57:44


JSJ 269 Reusable React and JavaScript Components with Cory House On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in! [00:01:35] – Overview We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done. Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.  [00:04:50] – Browser support issue The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components. Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead. [00:07:50] – Polymer The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.    [00:14:20] – Standards are dead No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library. Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about. [00:17:05] – Libraries making reusable components There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well. As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there [00:21:20] – Why opt for reusable components Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse. As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.   [00:31:20] – Rigid component vs. flexible component As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder. We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough. Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later. [00:36:00] – Reusable components The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously. We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue. [00:42:45] – Component development on teams Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need. [00:47:45] – Mobile to web crossover Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application. [00:50:00] – Challenge Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?" Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember. Picks Cory House Creating Reusable React Components on Pluralsight Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss Joe Eames UI-Router Persistence Aimee Knight Ask HN: People who completed a boot camp 3+ years ago, what are you doing now? NgAtlanta Charles Max Wood Upwork.com JSJ 269 Reusable React and JavaScript Components with Cory House On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in! [00:01:35] – Overview We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done. Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue.  [00:04:50] – Browser support issue The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components. Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead. [00:07:50] – Polymer The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.    [00:14:20] – Standards are dead No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library. Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about. [00:17:05] – Libraries making reusable components There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well. As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there [00:21:20] – Why opt for reusable components Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse. As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.   [00:31:20] – Rigid component vs. flexible component As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder. We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough. Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later. [00:36:00] – Reusable components The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously. We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue. [00:42:45] – Component development on teams Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need. [00:47:45] – Mobile to web crossover Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application. [00:50:00] – Challenge Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?" Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember. Picks Cory House Creating Reusable React Components on Pluralsight Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss Joe Eames UI-Router Persistence Aimee Knight Ask HN: People who completed a boot camp 3+ years ago, what are you doing now? NgAtlanta Charles Max Wood Upwork.com

All JavaScript Podcasts by Devchat.tv

My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

My JavaScript Story
MJS #022 Cory House

My JavaScript Story

Play Episode Listen Later Jun 21, 2017 46:31


My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

Devchat.tv Master Feed
MJS #022 Cory House

Devchat.tv Master Feed

Play Episode Listen Later Jun 21, 2017 46:31


My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

Devchat.tv Master Feed
JSJ 255 Docker for Developers with Derick Bailey

Devchat.tv Master Feed

Play Episode Listen Later Mar 28, 2017 80:22


On today's JavaScript Jabber Show, Charles Max Wood, AJ O'neal, Aimee Knight, Joe Eames, and Cory House discuss Docker for Developers with Derick Bailey. Derick is currently into Docker and has been doing a series on it at WatchMeCode. He is also writing an ebook titled Docker Recipes for Node.js Development which aims to provide solutions for things that concern Node.js. Stay tuned to learn more about Docker and the ebook which Derick is working on!

All JavaScript Podcasts by Devchat.tv
JSJ 255 Docker for Developers with Derick Bailey

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Mar 28, 2017 80:22


On today's JavaScript Jabber Show, Charles Max Wood, AJ O'neal, Aimee Knight, Joe Eames, and Cory House discuss Docker for Developers with Derick Bailey. Derick is currently into Docker and has been doing a series on it at WatchMeCode. He is also writing an ebook titled Docker Recipes for Node.js Development which aims to provide solutions for things that concern Node.js. Stay tuned to learn more about Docker and the ebook which Derick is working on!

JavaScript Jabber
JSJ 255 Docker for Developers with Derick Bailey

JavaScript Jabber

Play Episode Listen Later Mar 28, 2017 80:22


On today's JavaScript Jabber Show, Charles Max Wood, AJ O'neal, Aimee Knight, Joe Eames, and Cory House discuss Docker for Developers with Derick Bailey. Derick is currently into Docker and has been doing a series on it at WatchMeCode. He is also writing an ebook titled Docker Recipes for Node.js Development which aims to provide solutions for things that concern Node.js. Stay tuned to learn more about Docker and the ebook which Derick is working on!

JavaScript Jabber
JSJ Special Episode: Azure with Jonathan Carter

JavaScript Jabber

Play Episode Listen Later Mar 17, 2017 53:52


On today's episode, Aimee Knight, AJ O'Neal, Cory House, Joe Eames, and Charles Max Wood discuss Azure with Jonathan Carter. Jonathan has been working at Microsoft for 10 years. He currently focuses on Node.js and Azure. Tune in to learn how you can use Azure in building applications and services.

microsoft azure node charles max wood jonathan carter aimee knight joe eames cory house
Devchat.tv Master Feed
JSJ Special Episode: Azure with Jonathan Carter

Devchat.tv Master Feed

Play Episode Listen Later Mar 17, 2017 53:52


On today's episode, Aimee Knight, AJ O'Neal, Cory House, Joe Eames, and Charles Max Wood discuss Azure with Jonathan Carter. Jonathan has been working at Microsoft for 10 years. He currently focuses on Node.js and Azure. Tune in to learn how you can use Azure in building applications and services.

microsoft azure node charles max wood jonathan carter aimee knight joe eames cory house
All JavaScript Podcasts by Devchat.tv
JSJ Special Episode: Azure with Jonathan Carter

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Mar 17, 2017 53:52


On today's episode, Aimee Knight, AJ O'Neal, Cory House, Joe Eames, and Charles Max Wood discuss Azure with Jonathan Carter. Jonathan has been working at Microsoft for 10 years. He currently focuses on Node.js and Azure. Tune in to learn how you can use Azure in building applications and services.

microsoft azure node charles max wood jonathan carter aimee knight joe eames cory house
Devchat.tv Master Feed
JSJ 247 Building a Development Environment with Cory House

Devchat.tv Master Feed

Play Episode Listen Later Jan 31, 2017 65:53


On today's episode, Charles Max Wood, AJ O'neal, Joe Eames, and Aimee Knight discuss Building a Development Environment with Cory House. Pluralsight recently added a course on this. Tune in to know more!

JavaScript Jabber
JSJ 247 Building a Development Environment with Cory House

JavaScript Jabber

Play Episode Listen Later Jan 31, 2017 65:53


On today's episode, Charles Max Wood, AJ O'neal, Joe Eames, and Aimee Knight discuss Building a Development Environment with Cory House. Pluralsight recently added a course on this. Tune in to know more!

All JavaScript Podcasts by Devchat.tv
JSJ 247 Building a Development Environment with Cory House

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jan 31, 2017 65:53


On today's episode, Charles Max Wood, AJ O'neal, Joe Eames, and Aimee Knight discuss Building a Development Environment with Cory House. Pluralsight recently added a course on this. Tune in to know more!

The Hello World Podcast
Episode 81: Cory House

The Hello World Podcast

Play Episode Listen Later Jan 30, 2017 39:31


Cory is an international speaker, Pluralsight author, Microsoft MVP, Software Architect, independent consultant, and teacher. He has trained over 10,000 software developers at conferences worldwide on front-end development, testing, and software architecture. He currently specializes in front-end development using React. Cory is author of multiple Pluralsight courses and is active on Twitter as @housecor.

.NET Rocks!
JavaScript Development Environments with Cory House

.NET Rocks!

Play Episode Listen Later Dec 14, 2016 52:18


How many different decisions do you need to make before starting web development? Carl and Richard talk to Cory House about picking out a JavaScript development environment. Cory talks about his own experiences getting into the groove with the React stack, but that is certainly not the only way to build a web application. When you think more broadly about building web apps, the number of decisions can be daunting, and hence the increase in starter kits and other tools like the JavaScript Services toolkit for making it easier to get all your tools together. Lots of great links in the show notes for different tools you can use!Support this podcast at — https://redcircle.com/net-rocks/donations

.NET Rocks!
JavaScript Development Environments with Cory House

.NET Rocks!

Play Episode Listen Later Dec 14, 2016 52:17


How many different decisions do you need to make before starting web development? Carl and Richard talk to Cory House about picking out a JavaScript development environment. Cory talks about his own experiences getting into the groove with the React stack, but that is certainly not the only way to build a web application. When you think more broadly about building web apps, the number of decisions can be daunting, and hence the increase in starter kits and other tools like the JavaScript Services toolkit for making it easier to get all your tools together. Lots of great links in the show notes for different tools you can use!Support this podcast at — https://redcircle.com/net-rocks/donations

react environments javascript cory house javascript development
Developer On Fire
Episode 154 | Cory House - Life, the Universe, and Everything

Developer On Fire

Play Episode Listen Later Aug 8, 2016 56:35


Guest: Cory House @housecor Full show notes are at https://developeronfire.com/podcast/episode-154-cory-house-life-the-universe-and-everything

Eat Sleep Code Podcast

On this episode of Eat Sleep Code, guest Cory House talks about ReactJS. We discuss the pros and cons of ReactJS and how different React is from other front-end frameworks.

Developer On Fire
Episode 050 | Cory House - Out of His Shell

Developer On Fire

Play Episode Listen Later Oct 23, 2015 39:14


Guest: Cory House @housecor Full show notes are at https://developeronfire.com/podcast/episode-050-cory-house-out-of-his-shell

.NET Rocks!
ReactJS in Web Apps with Cory House

.NET Rocks!

Play Episode Listen Later Sep 9, 2015 54:47


Ready to React? Carl and Richard talk to Cory House about his experiences building applications using Facebook's React library. The conversation digs into the philosophical differences to web page design that React is focused on - and how they upset a lot of folks! Cory describes React as an approach for building UI components, which means combining HTML, Javascript and even CSS together! He also digs into the challenges of assembling the right tool stack - React is not an all-in-one library, you have some choices to make. The conversation also digs into Flux and it's alternatives as approaches to your overall web page architecture. Lots of options!Support this podcast at — https://redcircle.com/net-rocks/donations

.NET Rocks!
ReactJS in Web Apps with Cory House

.NET Rocks!

Play Episode Listen Later Sep 9, 2015 54:46


Ready to React? Carl and Richard talk to Cory House about his experiences building applications using Facebook's React library. The conversation digs into the philosophical differences to web page design that React is focused on - and how they upset a lot of folks! Cory describes React as an approach for building UI components, which means combining HTML, Javascript and even CSS together! He also digs into the challenges of assembling the right tool stack - React is not an all-in-one library, you have some choices to make. The conversation also digs into Flux and it's alternatives as approaches to your overall web page architecture. Lots of options!Support this podcast at — https://redcircle.com/net-rocks/donations

.NET Rocks!
Web Components with Cory House

.NET Rocks!

Play Episode Listen Later Feb 4, 2015 55:32


Are you ready to build web pages with web components? Cory House is! Carl and Richard talk to Cory House about the web component specification and what that will look like in your modern web development. As Cory explains, the key idea behind web components is to provide a framework for Javascript library extensibility that doesn't force you to own the library yourself. While the standard is still being discussed, Cory mentions some libraries that have already gone ahead and implemented a variation of this extensibility, such as Steve Sanderson's amazing KnockoutJS. Web components make Javascript that much better to use!Support this podcast at — https://redcircle.com/net-rocks/donations

.NET Rocks!
Web Components with Cory House

.NET Rocks!

Play Episode Listen Later Feb 4, 2015 55:31


Are you ready to build web pages with web components? Cory House is! Carl and Richard talk to Cory House about the web component specification and what that will look like in your modern web development. As Cory explains, the key idea behind web components is to provide a framework for Javascript library extensibility that doesn't force you to own the library yourself. While the standard is still being discussed, Cory mentions some libraries that have already gone ahead and implemented a variation of this extensibility, such as Steve Sanderson's amazing KnockoutJS. Web components make Javascript that much better to use!Support this podcast at — https://redcircle.com/net-rocks/donations

.NET Rocks!
Real World Single Page Apps with Cory House

.NET Rocks!

Play Episode Listen Later Jun 18, 2014 46:37


While at NDC, Carl and Richard chat with Cory House about his experiences building Single Page Applications for the automotive industry. Cory talks about the challenges of the industry, including supporting both IE7 and IE8 running on Windows XP and iPad devices. Quite a span of technology there! The conversation digs into UI design, the integration of third party services and meeting the expectations of a customer that is not all that focused on technology. Cory digs into the idea of SPA as a classic desktop application replacement - it can be done!Support this podcast at — https://redcircle.com/net-rocks/donations

.NET Rocks!
Real World Single Page Apps with Cory House

.NET Rocks!

Play Episode Listen Later Jun 18, 2014 46:36


While at NDC, Carl and Richard chat with Cory House about his experiences building Single Page Applications for the automotive industry. Cory talks about the challenges of the industry, including supporting both IE7 and IE8 running on Windows XP and iPad devices. Quite a span of technology there! The conversation digs into UI design, the integration of third party services and meeting the expectations of a customer that is not all that focused on technology. Cory digs into the idea of SPA as a classic desktop application replacement - it can be done!Support this podcast at — https://redcircle.com/net-rocks/donations

spa ipads real world ui windows xp ndc ie8 single page apps cory house ie7