Podcasts about guest how

Panel: Lucas Reis Justin Bennett Charles Max Wood Special Guest: Kent C. Dodds In this episode, the panelist talk with today’s guest, Kent C. Dodds who works for PayPal, is an instructor, and works through open source! Kent lives in Utah with his wife and four children. Kent and the panel talk today about testing – check it out! Show Topics: 0:00 – Kendo UI 0:32 – Chuck: Hello! My new show is TheDevRev – please go check it out! 1:35 – Panel: I want all of it! 1:43 – Chuck: Our guest is Kent C. Dodds! You were on the show for a while and then you got busy. 2:06 – Guest.  3:09 – Panel: The kid part is impressive. 3:20 – Guest: Yeah it’s awesome, but the kid part is my wife!  4:09 – Panel: 10 years ago we weren’t having any tests and then now we are thinking about how to write better tests. It’s the next step on that subject. What is your story with tests and what sparked these ideas? 4:50 – Guest. 7:25 – Panel: We have a bunch of tests at my work. “There is no such thing as too many tests” are being said a lot! Then we started talking about unit tests and there was this shift. The tests, for me, felt cumbersome. How do I know that this suite of tests are actually helping me and not hurting me? 8:32 – Guest: I think that is a valuable insight. 11:03 – Panel: What is the make-up of a good test? 11:13 – Guest: Test every line – everything! No. 11:19 – Chuck: “Look at everything!” I don’t know where to start, man! 11:30 – Guest: How do you avoid those false negatives and false positives. 15:38 – Panel: The end user is going to be like more of integration test, and the developer user will be more like a unit tester? 16:01 – Guest: I don’t care too much of the distinction between unit and integration tests. 18:36 – Panel: I have worked in testing in the past. One of the big things that fall on the users’ flow is that it’s difficult b/c maybe a tool like Selenium: when will things render? Are you still testing things in isolation? 19:33 – Guest: It depends. When I talk about UI integration testing I am still mocking the backend. 23:10 – Chuck: I am curious, where do you decide these are expensive (so I don’t want to do too many of them), but at what point is it worth it to do it? 23:30 – Guest mentions the testing pyramid. 28:14 – Chuck: Why do you care about confidence? What is confidence and what does it matter? 28:35 – FreshBooks! 29:50 – Guest. 32:20 – Panel: I have something to add about the testing pyramid. Lucas talks about tooling, Mocha, JS Dong, and more! 33:44 – Guest: I think the testing pyramid is outdated and I have created my own. Guest talks about static testing, LINT, Cypress, and more! 35:32 – Chuck: When I was a new developer, people talked about using tests to track down bugs. What if it’s a hairy bug? 36:07 – Guest: If you can, you can use this methodical approach... 39:46 – Panel: Let’s talk about the React library for a little bit? Panel: Part of the confidence of the tests we write we ask ourselves “will it stand the test of time?” How does the React Testing library go about to solve that? 41:05 – Guest. 47:51 – Panel: A few more questions. When you are getting something and testing and grabbing the label by its text have you found that to be fragile? Is it reasonably reliable? 48:57 – Guest: Yeah this is a concern and it relies on content. 53:06 – Panel: I like this idea of having a different library. Sometimes we think that a powerful tool is better, but after spending some time with other tools that’s not always the case. 54:16 – Guest: “You tie your hands to free your mind.” It does less but what it does less it does better. 55:42 – Panel: I think that with Cypress, too? 55:51 – Guest: Yeah that’s why Cypress is great to use. 57:17 – Panel: I wrote a small library here at work and it deals with metrics. I automated all of those small clicks – write a bit – click a bit – and it was really good. I felt quite efficient. Those became the tests. 57:58 – Panel: One more question: What about react Native? That comes up a lot. At looking at testing libraries we try to keep parody between the two. Do you have any thoughts on that? 58:34 – Guest talks about React Native. 1:00:22 – Panel: Anything else? It’s fascinating to talk about and dive-into these topics. When we talk about confidence that is very powerful, too. 1:01:02 – Panelist asks the last question! 1:01:38 – Guest: You could show them the coverage support. Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job Enzyme React Testing Library Cypress.io Hillel Wayne Testing JavaScript with Kent C. Dodds Kent Dodds’ News Kent Dodds’ Blog Egghead.io – Kent C. Dodds Ready to Write a Novel? Practical TLA+ GitHub: Circleci-queue GitHub: sstephenson / bats Todoist Discord Kent’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI   Picks: Lucas Hillel Wayne Practical TLA+ Justin Circle CI Queue Bats Todoists Charles MFCEO Project Podcast The DevRev Kent Discord Devs Who Write Finding your Why! TestingJavaScript.com kcd.im/news kcd.i./hooks-and-suspense NaNoWriMo

Panel: Lucas Reis Justin Bennett Charles Max Wood Special Guest: Kent C. Dodds In this episode, the panelist talk with today’s guest, Kent C. Dodds who works for PayPal, is an instructor, and works through open source! Kent lives in Utah with his wife and four children. Kent and the panel talk today about testing – check it out! Show Topics: 0:00 – Kendo UI 0:32 – Chuck: Hello! My new show is TheDevRev – please go check it out! 1:35 – Panel: I want all of it! 1:43 – Chuck: Our guest is Kent C. Dodds! You were on the show for a while and then you got busy. 2:06 – Guest.  3:09 – Panel: The kid part is impressive. 3:20 – Guest: Yeah it’s awesome, but the kid part is my wife!  4:09 – Panel: 10 years ago we weren’t having any tests and then now we are thinking about how to write better tests. It’s the next step on that subject. What is your story with tests and what sparked these ideas? 4:50 – Guest. 7:25 – Panel: We have a bunch of tests at my work. “There is no such thing as too many tests” are being said a lot! Then we started talking about unit tests and there was this shift. The tests, for me, felt cumbersome. How do I know that this suite of tests are actually helping me and not hurting me? 8:32 – Guest: I think that is a valuable insight. 11:03 – Panel: What is the make-up of a good test? 11:13 – Guest: Test every line – everything! No. 11:19 – Chuck: “Look at everything!” I don’t know where to start, man! 11:30 – Guest: How do you avoid those false negatives and false positives. 15:38 – Panel: The end user is going to be like more of integration test, and the developer user will be more like a unit tester? 16:01 – Guest: I don’t care too much of the distinction between unit and integration tests. 18:36 – Panel: I have worked in testing in the past. One of the big things that fall on the users’ flow is that it’s difficult b/c maybe a tool like Selenium: when will things render? Are you still testing things in isolation? 19:33 – Guest: It depends. When I talk about UI integration testing I am still mocking the backend. 23:10 – Chuck: I am curious, where do you decide these are expensive (so I don’t want to do too many of them), but at what point is it worth it to do it? 23:30 – Guest mentions the testing pyramid. 28:14 – Chuck: Why do you care about confidence? What is confidence and what does it matter? 28:35 – FreshBooks! 29:50 – Guest. 32:20 – Panel: I have something to add about the testing pyramid. Lucas talks about tooling, Mocha, JS Dong, and more! 33:44 – Guest: I think the testing pyramid is outdated and I have created my own. Guest talks about static testing, LINT, Cypress, and more! 35:32 – Chuck: When I was a new developer, people talked about using tests to track down bugs. What if it’s a hairy bug? 36:07 – Guest: If you can, you can use this methodical approach... 39:46 – Panel: Let’s talk about the React library for a little bit? Panel: Part of the confidence of the tests we write we ask ourselves “will it stand the test of time?” How does the React Testing library go about to solve that? 41:05 – Guest. 47:51 – Panel: A few more questions. When you are getting something and testing and grabbing the label by its text have you found that to be fragile? Is it reasonably reliable? 48:57 – Guest: Yeah this is a concern and it relies on content. 53:06 – Panel: I like this idea of having a different library. Sometimes we think that a powerful tool is better, but after spending some time with other tools that’s not always the case. 54:16 – Guest: “You tie your hands to free your mind.” It does less but what it does less it does better. 55:42 – Panel: I think that with Cypress, too? 55:51 – Guest: Yeah that’s why Cypress is great to use. 57:17 – Panel: I wrote a small library here at work and it deals with metrics. I automated all of those small clicks – write a bit – click a bit – and it was really good. I felt quite efficient. Those became the tests. 57:58 – Panel: One more question: What about react Native? That comes up a lot. At looking at testing libraries we try to keep parody between the two. Do you have any thoughts on that? 58:34 – Guest talks about React Native. 1:00:22 – Panel: Anything else? It’s fascinating to talk about and dive-into these topics. When we talk about confidence that is very powerful, too. 1:01:02 – Panelist asks the last question! 1:01:38 – Guest: You could show them the coverage support. Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job Enzyme React Testing Library Cypress.io Hillel Wayne Testing JavaScript with Kent C. Dodds Kent Dodds’ News Kent Dodds’ Blog Egghead.io – Kent C. Dodds Ready to Write a Novel? Practical TLA+ GitHub: Circleci-queue GitHub: sstephenson / bats Todoist Discord Kent’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI   Picks: Lucas Hillel Wayne Practical TLA+ Justin Circle CI Queue Bats Todoists Charles MFCEO Project Podcast The DevRev Kent Discord Devs Who Write Finding your Why! TestingJavaScript.com kcd.im/news kcd.i./hooks-and-suspense NaNoWriMo

Panel: Charles Max Wood Guest: Travis Tidwell This week on My Angular Story, Charles speaks with Travis Tidwell (Dallas, TX) who is CTO and co-founder of Form_IO! Chuck and Travis talk about his background, open source struggles, and more. Check it out! In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 0:49 – Chuck: Welcome! We had you on Episode 125. A lot has changed huh? The nice thing, though, about these changes is that we seem to be tackling different problems. 1:42 – Guest: They are stabilizing on the same on the same design patterns. I think that’s refreshing. Back in the day, everyone had their own way of doing it. It was difficult to find which one is the RIGHT one. 2:05 – Chuck: Yes, I agree. Gives us your background, please! 2:20 – Guest: I am still doing Form IO, and the co-founder and CTO of the company. My Angular Story is MY story on how the company evolved. 3:05 – Chuck: How did you get into programming? 3:09 – Guest: I am going to be 40-years old in May! I am getting up there. Everyone who I am talking to (in my age) it seems like we have the same story. We have this story of having that REALLY old computer. Parents bring home the IBM or the Commodore 64 and that really is my story. At the time, the only thing you could learn with it was to program – there weren’t any video games, etc. A book that I geeked-out about was: “DOS for Dummies.” The guest talks about his senior year in college and how he came to fall in-love with programming. 6:28 – Guest: After college, I got a job for working for a company that used C++ code. People ask: How the heck did you get into Web? My background, too, was tap dancing and in the arts. Most people don’t know that. I was giving these tap lessons to kids – and around that time YouTube was just for cat videos. At the time, I thought it would be great to teach these tap video lessons online. I found a CMS at the time that would help me with my teaching intent. Drupal took me into the frontend libraries. PHP is a backend language, and Drupal was based entirely on PHP. There was this huge paradigm-shift within my career. I really got into these tools not knowing that it would change my career. My open source has taken me to tutorial videos. Eventually, a light bulb went off and I found a solution that needed to be solved within Angular. 12:21 – Guest.  12:28 – Chuck: I love the side hustle description: I saw a need out there and we solved it! 12:40 – Guest: Side hustle is great to talk about. Open source is a bit of a struggle (at that time) it was really hard to maintain open source and providing for your family at the same time. Open source is hard b/c you work your butt off, but you aren’t getting paid for it. It’s really, really difficult. I’ve had ups-and-downs actually with open source. You have to get innovative with it. I am really big on and supportive of people who are monetizing off of open source. 14:58 – Chuck: Open source – for me – I got burned out in June. Sometimes you are putting in a lot of time and not seeing any benefit from it. You have all of these things and something changes, something is different – I can’t take another night not seeing my kids. 16:06 – Guest: You have this original motivation as an open source developer – and you build something rally cool. You share with the world, but a lot of people don’t realize the tail of it. Come to realize it worked well for you – but not for everyone! It makes your stock price go out – contributing to open source – especially if you have a popular open source library. Most of the jobs I would apply to I would just give them my GitHub repertoire. People are figuring out ways they can support themselves and monetize. The ones that can figure that out don’t burnout. 19:44 – Chuck: Babel – Henry Zhu. (See his Patreon account.) 20:08 – Guest: How does he do it? 20:20 – Chuck: It’s mostly contributions. 20:35 – Guest: I see that you are on Patreon. I urge people to go there and help support those open source people. It’s such a great thing and it’s becoming a trend. That’s one thing that drew me away from Drupal b/c at the time it had this negative connotation of monetizing on your open source. The spirit of the open source is THAT. It gives support to open source folks in order to provide for their families. 22:00 – Chuck: I talk a lot with Eric through CodeFund. It’s important to know these options. 22:24 – Guest: That is my road of open source and in creating IO. 24:01 – Chuck: You are the CTO and not the CEO. How did you wind up and forming IO? 24:15 – Guest: There were a lot of pain points. It all started with the prototype. The guest talks about the background. Travis mentions FormBuilder among other things. 30:00 – Chuck: What are you working on now? 30:05 – Guest: The Vanilla Core Renderer! It doesn’t care what framework it gets attached to. We are working on a new template engine.  31:55 – Chuck: I wish I had more time to code. 31:58 – Guest. 33:08 – Chuck: How can people find you? 33:10 – Guest: GitHub! Training YouTube Videos! Twitter! 34:56 – Fresh Books! END – CacheFly Links: jQuery Angular JavaScript Vue React Chuck’s Twitter Chuck’s E-mail: chuck@devchat.tv Travis Tidwell’s Book: Flash With Drupal “How to Build a M.E.A.N. Web Application” by Travis Tidwell Angular-Formly Angular Angular – FormBuilder Patreon Travis’ YouTube Videos Episode 125 with Travis! Travis’ LinkedIn Sponsors: Get A Coder Job Fresh Books Cache Fly Picks: Travis Technology: Minio.io T.V. Show: Rick & Morty AI Movie (listen for title) Chuck T.V. Show: Last Man Standing

Panel: Charles Max Wood Guest: Travis Tidwell This week on My Angular Story, Charles speaks with Travis Tidwell (Dallas, TX) who is CTO and co-founder of Form_IO! Chuck and Travis talk about his background, open source struggles, and more. Check it out! In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 0:49 – Chuck: Welcome! We had you on Episode 125. A lot has changed huh? The nice thing, though, about these changes is that we seem to be tackling different problems. 1:42 – Guest: They are stabilizing on the same on the same design patterns. I think that’s refreshing. Back in the day, everyone had their own way of doing it. It was difficult to find which one is the RIGHT one. 2:05 – Chuck: Yes, I agree. Gives us your background, please! 2:20 – Guest: I am still doing Form IO, and the co-founder and CTO of the company. My Angular Story is MY story on how the company evolved. 3:05 – Chuck: How did you get into programming? 3:09 – Guest: I am going to be 40-years old in May! I am getting up there. Everyone who I am talking to (in my age) it seems like we have the same story. We have this story of having that REALLY old computer. Parents bring home the IBM or the Commodore 64 and that really is my story. At the time, the only thing you could learn with it was to program – there weren’t any video games, etc. A book that I geeked-out about was: “DOS for Dummies.” The guest talks about his senior year in college and how he came to fall in-love with programming. 6:28 – Guest: After college, I got a job for working for a company that used C++ code. People ask: How the heck did you get into Web? My background, too, was tap dancing and in the arts. Most people don’t know that. I was giving these tap lessons to kids – and around that time YouTube was just for cat videos. At the time, I thought it would be great to teach these tap video lessons online. I found a CMS at the time that would help me with my teaching intent. Drupal took me into the frontend libraries. PHP is a backend language, and Drupal was based entirely on PHP. There was this huge paradigm-shift within my career. I really got into these tools not knowing that it would change my career. My open source has taken me to tutorial videos. Eventually, a light bulb went off and I found a solution that needed to be solved within Angular. 12:21 – Guest.  12:28 – Chuck: I love the side hustle description: I saw a need out there and we solved it! 12:40 – Guest: Side hustle is great to talk about. Open source is a bit of a struggle (at that time) it was really hard to maintain open source and providing for your family at the same time. Open source is hard b/c you work your butt off, but you aren’t getting paid for it. It’s really, really difficult. I’ve had ups-and-downs actually with open source. You have to get innovative with it. I am really big on and supportive of people who are monetizing off of open source. 14:58 – Chuck: Open source – for me – I got burned out in June. Sometimes you are putting in a lot of time and not seeing any benefit from it. You have all of these things and something changes, something is different – I can’t take another night not seeing my kids. 16:06 – Guest: You have this original motivation as an open source developer – and you build something rally cool. You share with the world, but a lot of people don’t realize the tail of it. Come to realize it worked well for you – but not for everyone! It makes your stock price go out – contributing to open source – especially if you have a popular open source library. Most of the jobs I would apply to I would just give them my GitHub repertoire. People are figuring out ways they can support themselves and monetize. The ones that can figure that out don’t burnout. 19:44 – Chuck: Babel – Henry Zhu. (See his Patreon account.) 20:08 – Guest: How does he do it? 20:20 – Chuck: It’s mostly contributions. 20:35 – Guest: I see that you are on Patreon. I urge people to go there and help support those open source people. It’s such a great thing and it’s becoming a trend. That’s one thing that drew me away from Drupal b/c at the time it had this negative connotation of monetizing on your open source. The spirit of the open source is THAT. It gives support to open source folks in order to provide for their families. 22:00 – Chuck: I talk a lot with Eric through CodeFund. It’s important to know these options. 22:24 – Guest: That is my road of open source and in creating IO. 24:01 – Chuck: You are the CTO and not the CEO. How did you wind up and forming IO? 24:15 – Guest: There were a lot of pain points. It all started with the prototype. The guest talks about the background. Travis mentions FormBuilder among other things. 30:00 – Chuck: What are you working on now? 30:05 – Guest: The Vanilla Core Renderer! It doesn’t care what framework it gets attached to. We are working on a new template engine.  31:55 – Chuck: I wish I had more time to code. 31:58 – Guest. 33:08 – Chuck: How can people find you? 33:10 – Guest: GitHub! Training YouTube Videos! Twitter! 34:56 – Fresh Books! END – CacheFly Links: jQuery Angular JavaScript Vue React Chuck’s Twitter Chuck’s E-mail: chuck@devchat.tv Travis Tidwell’s Book: Flash With Drupal “How to Build a M.E.A.N. Web Application” by Travis Tidwell Angular-Formly Angular Angular – FormBuilder Patreon Travis’ YouTube Videos Episode 125 with Travis! Travis’ LinkedIn Sponsors: Get A Coder Job Fresh Books Cache Fly Picks: Travis Technology: Minio.io T.V. Show: Rick & Morty AI Movie (listen for title) Chuck T.V. Show: Last Man Standing

Panel: Charles Max Wood Guest: Travis Tidwell This week on My Angular Story, Charles speaks with Travis Tidwell (Dallas, TX) who is CTO and co-founder of Form_IO! Chuck and Travis talk about his background, open source struggles, and more. Check it out! In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 0:49 – Chuck: Welcome! We had you on Episode 125. A lot has changed huh? The nice thing, though, about these changes is that we seem to be tackling different problems. 1:42 – Guest: They are stabilizing on the same on the same design patterns. I think that’s refreshing. Back in the day, everyone had their own way of doing it. It was difficult to find which one is the RIGHT one. 2:05 – Chuck: Yes, I agree. Gives us your background, please! 2:20 – Guest: I am still doing Form IO, and the co-founder and CTO of the company. My Angular Story is MY story on how the company evolved. 3:05 – Chuck: How did you get into programming? 3:09 – Guest: I am going to be 40-years old in May! I am getting up there. Everyone who I am talking to (in my age) it seems like we have the same story. We have this story of having that REALLY old computer. Parents bring home the IBM or the Commodore 64 and that really is my story. At the time, the only thing you could learn with it was to program – there weren’t any video games, etc. A book that I geeked-out about was: “DOS for Dummies.” The guest talks about his senior year in college and how he came to fall in-love with programming. 6:28 – Guest: After college, I got a job for working for a company that used C++ code. People ask: How the heck did you get into Web? My background, too, was tap dancing and in the arts. Most people don’t know that. I was giving these tap lessons to kids – and around that time YouTube was just for cat videos. At the time, I thought it would be great to teach these tap video lessons online. I found a CMS at the time that would help me with my teaching intent. Drupal took me into the frontend libraries. PHP is a backend language, and Drupal was based entirely on PHP. There was this huge paradigm-shift within my career. I really got into these tools not knowing that it would change my career. My open source has taken me to tutorial videos. Eventually, a light bulb went off and I found a solution that needed to be solved within Angular. 12:21 – Guest.  12:28 – Chuck: I love the side hustle description: I saw a need out there and we solved it! 12:40 – Guest: Side hustle is great to talk about. Open source is a bit of a struggle (at that time) it was really hard to maintain open source and providing for your family at the same time. Open source is hard b/c you work your butt off, but you aren’t getting paid for it. It’s really, really difficult. I’ve had ups-and-downs actually with open source. You have to get innovative with it. I am really big on and supportive of people who are monetizing off of open source. 14:58 – Chuck: Open source – for me – I got burned out in June. Sometimes you are putting in a lot of time and not seeing any benefit from it. You have all of these things and something changes, something is different – I can’t take another night not seeing my kids. 16:06 – Guest: You have this original motivation as an open source developer – and you build something rally cool. You share with the world, but a lot of people don’t realize the tail of it. Come to realize it worked well for you – but not for everyone! It makes your stock price go out – contributing to open source – especially if you have a popular open source library. Most of the jobs I would apply to I would just give them my GitHub repertoire. People are figuring out ways they can support themselves and monetize. The ones that can figure that out don’t burnout. 19:44 – Chuck: Babel – Henry Zhu. (See his Patreon account.) 20:08 – Guest: How does he do it? 20:20 – Chuck: It’s mostly contributions. 20:35 – Guest: I see that you are on Patreon. I urge people to go there and help support those open source people. It’s such a great thing and it’s becoming a trend. That’s one thing that drew me away from Drupal b/c at the time it had this negative connotation of monetizing on your open source. The spirit of the open source is THAT. It gives support to open source folks in order to provide for their families. 22:00 – Chuck: I talk a lot with Eric through CodeFund. It’s important to know these options. 22:24 – Guest: That is my road of open source and in creating IO. 24:01 – Chuck: You are the CTO and not the CEO. How did you wind up and forming IO? 24:15 – Guest: There were a lot of pain points. It all started with the prototype. The guest talks about the background. Travis mentions FormBuilder among other things. 30:00 – Chuck: What are you working on now? 30:05 – Guest: The Vanilla Core Renderer! It doesn’t care what framework it gets attached to. We are working on a new template engine.  31:55 – Chuck: I wish I had more time to code. 31:58 – Guest. 33:08 – Chuck: How can people find you? 33:10 – Guest: GitHub! Training YouTube Videos! Twitter! 34:56 – Fresh Books! END – CacheFly Links: jQuery Angular JavaScript Vue React Chuck’s Twitter Chuck’s E-mail: chuck@devchat.tv Travis Tidwell’s Book: Flash With Drupal “How to Build a M.E.A.N. Web Application” by Travis Tidwell Angular-Formly Angular Angular – FormBuilder Patreon Travis’ YouTube Videos Episode 125 with Travis! Travis’ LinkedIn Sponsors: Get A Coder Job Fresh Books Cache Fly Picks: Travis Technology: Minio.io T.V. Show: Rick & Morty AI Movie (listen for title) Chuck T.V. Show: Last Man Standing

Panel: Lucas Reis Justin Bennett Special Guests: Alexey Ivanov and Andy Barnov In this episode, the panelists talk with Alexey Ivanov and Andy Barnov. They all discuss Alexey’s article titled: “Optimizing React Virtual DOM.” Listen to today’s episode to hear all the details about this article, the guests’ backgrounds and much, much more! Show Topics: 0:32 – Panel: Thanks for joining us and talking about this article. 0:52 – Guest: Thanks for having us on your podcast! The guest talks about his community of developers and the offices are in San Francisco, Russia and other places. He talks about how the company helps their customers and how they can scale. Some of their companies are Groupon and Ebay. 2:39 – Alexey. 3:09 – Panel: The article is here. What is JSX how does it boil down to? It’s all supposed to help people and help them understand. 3:45 – Alexey: It’s about how to structure your state, etc. 4:15 – Panel: This keeps things small. He said when I have one idea I write a song and when I have 2 ideas I write 2 songs. If you try to put too many ideas into one post it maybe won’t go too far. 4:48 – Alexey. 5:50 – Panel. 5:56 – Panel: That’s a topic for another episode. The article is interesting in that the large percentage don’t think about rendering performance, so it’s a needed piece of content. Let’s talk about – what is the React Virtual DOM? 6:32 – Alexey goes into detail with his answer to the panelist’s question. 8:50 – Panel: What I like about this article is that you go through a good progression: here is the JSX that you would write and here is the trans piled function is. And you show the virtual DOM pre-presentation is. I think that is a helpful thing. Let’s talk about that. How does React change to those things when it’s rendering? 9:50 – Alexey. 12:58 – Panel: Okay to recap...when you are rendering an element you write some JSX and the first thing (component) that will map over to the type property is for the Virtual DOM object? And then all of that is compared – when does that happen, the comparison? 13:28 – Alexey: You have React and you create... 15:20 – Panel: So it’s both React and set state these are the only 2 things that triggered state or is there anything else out there? 15:31 – Alexey. 15:47 – Panel: Interesting. You talked about the imperative way we did it before – and it’s much simpler to say what you want, but a question is that is there any world case where it does not work well? What are the trade-offs? Have you ever encountered one? 16:34 – Alexey: If you have changes in the browse, implementations...it’s simplest and easiest way. You just need to have some little changes... 17:53 – Panel: If it’s basic then you don’t have to do manual updates. 18:03 – Alexey. Alexey: To make it work you need competence in your bundle. 18:36 – Panel: I’ve heard – haven’t worked with – when we have these projects that are really web time based, hundreds of elements in real time on a screen, on a Virtual DOM it’s too slow. You have to be precise. They had performance issues, I’m sure 98.99% of the applications probably perform better with the Virtual DOM.  19:46 – Alexey. 21:38 – Panel: That is to reduce the amount of state changes so you are reducing the amount of time it renders – right? 21:50 – Alexey. 22:03 – FRESH BOOKS! 23:11 – Panel: We talked about how type is the first thing that is checked. It does equal comparison to compare these types. What was really interesting is that class components are the same thing but not so. Is it always going to re-render for those components? 24:24 – Alexey: We have to talk about 2 things about this first. In my article... 27:49 – Panel: That is a beneficial tool too to control your rendering. You talked about tools to show updates and we will include the link to the article in the links, also I would read it and check out that particular function. It’s cool to see HOW it’s actually rendering. 28:29 – Panel: Apparently sometimes things help us in principle cause we need performance. We need to open the tools and understand what is happening? Is it really a bottleneck like I think it is? One of those Twitter things I saw a few months ago... 30:52 – Alexey: Yes, do what makes sense to you at the time. 32:08 – Panel: We talked about render performance and the pure component and not creating functions...you have a big quote in your article... I have a big question for me: You have a component, and there is a child / parent component. I am curious about that pattern – will it re-render every time? Tell us your thoughts, please. 33:16 – Alexey. 34:11 – Panel: My only issue with the render props is not a performance issue it’s more of an architectural issue. Sometimes we want things to be interjected. I want to have access to this or that. Sometimes we want to access those on a life cycle. The higher the component makes it easier to add a... That’s my only complaint about render comps. 35:35 – Alexey. 36:00 – Panel: Like composing consumers? 36:06 – Alexey: What we are talking about is... 37:00 – Panel: I agree. There are some interesting cases with that pattern when you have a lot of those chained together – function, function, etc. – there are some components that will help you compose... 37:34 – Panel: It’s like callback hell all over again. Everything is a tradeoff somewhere. After the tree it looks clean with render props. I like it even with the drawbacks. 38:25 – Panel: You spent some time talking about lists of children and how you (if one of the children are removed) then it ends up re rendering all the children cause it’s comparing their positions. You mentioned key is one way to deal with that. Let’s talk about keys. When people use keys they are using an array of an index. It seems like it defeats the purpose of it – is that right? 39:20 – Alexey: Yes, you are right.  40:19 – Panel: I think that continually and it’s a smaller known thing but people want this key error to go away and they just shove something in there. To some extent it’s good to know if your tool requires something it’s good to know WHY it requires that. 40:52 – Panel: Last question. Is that the person to program and be a web developer and they are learning React. This is the tool and they are learning how to use React for an app then when we are throwing articles at them. If they are learning React and these articles are at them I think it’s a cognitive overload. What are your thoughts / advice? 42:07 – Guest: How beginner should you be before you learn React? Ideally you should be aware of JavaScript, right? Sometimes people do this to catch up to something shiny. This is just my 2 cents.  43:03 – Alexey. 44:49 – Panel: When you are going to hire someone to do something or choose a framework always try to do a little bit of work without it. Try to build an application w/o React, and then React is introduced to you, you will only see the benefits that they are brining. One thing that happens inside the React world is that people don’t write an application... Start with the basic building blocks – that makes sense to me. 46:05 – Panel: Let’s go to picks! 46:13 – Advertisement – Get A Coder Job! Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub React: The Virtual DOM Elixir and Phoenix Bootcamp Alexey Ivanov’s Twitter Andy Barnov’s Twitter Rob Pike’s YouTube Video Understanding Comics Understanding Comics – Book Get A Coder Job Charles Max Wood’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Lucas Check your room for sound Andy Go Programming Language Alexey Understanding comics Justin The Complete Elixir and Phoenix Bootcamp

Panel: Lucas Reis Justin Bennett Special Guests: Alexey Ivanov and Andy Barnov In this episode, the panelists talk with Alexey Ivanov and Andy Barnov. They all discuss Alexey’s article titled: “Optimizing React Virtual DOM.” Listen to today’s episode to hear all the details about this article, the guests’ backgrounds and much, much more! Show Topics: 0:32 – Panel: Thanks for joining us and talking about this article. 0:52 – Guest: Thanks for having us on your podcast! The guest talks about his community of developers and the offices are in San Francisco, Russia and other places. He talks about how the company helps their customers and how they can scale. Some of their companies are Groupon and Ebay. 2:39 – Alexey. 3:09 – Panel: The article is here. What is JSX how does it boil down to? It’s all supposed to help people and help them understand. 3:45 – Alexey: It’s about how to structure your state, etc. 4:15 – Panel: This keeps things small. He said when I have one idea I write a song and when I have 2 ideas I write 2 songs. If you try to put too many ideas into one post it maybe won’t go too far. 4:48 – Alexey. 5:50 – Panel. 5:56 – Panel: That’s a topic for another episode. The article is interesting in that the large percentage don’t think about rendering performance, so it’s a needed piece of content. Let’s talk about – what is the React Virtual DOM? 6:32 – Alexey goes into detail with his answer to the panelist’s question. 8:50 – Panel: What I like about this article is that you go through a good progression: here is the JSX that you would write and here is the trans piled function is. And you show the virtual DOM pre-presentation is. I think that is a helpful thing. Let’s talk about that. How does React change to those things when it’s rendering? 9:50 – Alexey. 12:58 – Panel: Okay to recap...when you are rendering an element you write some JSX and the first thing (component) that will map over to the type property is for the Virtual DOM object? And then all of that is compared – when does that happen, the comparison? 13:28 – Alexey: You have React and you create... 15:20 – Panel: So it’s both React and set state these are the only 2 things that triggered state or is there anything else out there? 15:31 – Alexey. 15:47 – Panel: Interesting. You talked about the imperative way we did it before – and it’s much simpler to say what you want, but a question is that is there any world case where it does not work well? What are the trade-offs? Have you ever encountered one? 16:34 – Alexey: If you have changes in the browse, implementations...it’s simplest and easiest way. You just need to have some little changes... 17:53 – Panel: If it’s basic then you don’t have to do manual updates. 18:03 – Alexey. Alexey: To make it work you need competence in your bundle. 18:36 – Panel: I’ve heard – haven’t worked with – when we have these projects that are really web time based, hundreds of elements in real time on a screen, on a Virtual DOM it’s too slow. You have to be precise. They had performance issues, I’m sure 98.99% of the applications probably perform better with the Virtual DOM.  19:46 – Alexey. 21:38 – Panel: That is to reduce the amount of state changes so you are reducing the amount of time it renders – right? 21:50 – Alexey. 22:03 – FRESH BOOKS! 23:11 – Panel: We talked about how type is the first thing that is checked. It does equal comparison to compare these types. What was really interesting is that class components are the same thing but not so. Is it always going to re-render for those components? 24:24 – Alexey: We have to talk about 2 things about this first. In my article... 27:49 – Panel: That is a beneficial tool too to control your rendering. You talked about tools to show updates and we will include the link to the article in the links, also I would read it and check out that particular function. It’s cool to see HOW it’s actually rendering. 28:29 – Panel: Apparently sometimes things help us in principle cause we need performance. We need to open the tools and understand what is happening? Is it really a bottleneck like I think it is? One of those Twitter things I saw a few months ago... 30:52 – Alexey: Yes, do what makes sense to you at the time. 32:08 – Panel: We talked about render performance and the pure component and not creating functions...you have a big quote in your article... I have a big question for me: You have a component, and there is a child / parent component. I am curious about that pattern – will it re-render every time? Tell us your thoughts, please. 33:16 – Alexey. 34:11 – Panel: My only issue with the render props is not a performance issue it’s more of an architectural issue. Sometimes we want things to be interjected. I want to have access to this or that. Sometimes we want to access those on a life cycle. The higher the component makes it easier to add a... That’s my only complaint about render comps. 35:35 – Alexey. 36:00 – Panel: Like composing consumers? 36:06 – Alexey: What we are talking about is... 37:00 – Panel: I agree. There are some interesting cases with that pattern when you have a lot of those chained together – function, function, etc. – there are some components that will help you compose... 37:34 – Panel: It’s like callback hell all over again. Everything is a tradeoff somewhere. After the tree it looks clean with render props. I like it even with the drawbacks. 38:25 – Panel: You spent some time talking about lists of children and how you (if one of the children are removed) then it ends up re rendering all the children cause it’s comparing their positions. You mentioned key is one way to deal with that. Let’s talk about keys. When people use keys they are using an array of an index. It seems like it defeats the purpose of it – is that right? 39:20 – Alexey: Yes, you are right.  40:19 – Panel: I think that continually and it’s a smaller known thing but people want this key error to go away and they just shove something in there. To some extent it’s good to know if your tool requires something it’s good to know WHY it requires that. 40:52 – Panel: Last question. Is that the person to program and be a web developer and they are learning React. This is the tool and they are learning how to use React for an app then when we are throwing articles at them. If they are learning React and these articles are at them I think it’s a cognitive overload. What are your thoughts / advice? 42:07 – Guest: How beginner should you be before you learn React? Ideally you should be aware of JavaScript, right? Sometimes people do this to catch up to something shiny. This is just my 2 cents.  43:03 – Alexey. 44:49 – Panel: When you are going to hire someone to do something or choose a framework always try to do a little bit of work without it. Try to build an application w/o React, and then React is introduced to you, you will only see the benefits that they are brining. One thing that happens inside the React world is that people don’t write an application... Start with the basic building blocks – that makes sense to me. 46:05 – Panel: Let’s go to picks! 46:13 – Advertisement – Get A Coder Job! Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub React: The Virtual DOM Elixir and Phoenix Bootcamp Alexey Ivanov’s Twitter Andy Barnov’s Twitter Rob Pike’s YouTube Video Understanding Comics Understanding Comics – Book Get A Coder Job Charles Max Wood’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Lucas Check your room for sound Andy Go Programming Language Alexey Understanding comics Justin The Complete Elixir and Phoenix Bootcamp

Panel: Aimee Knight Charles Max Wood (DevChat TV) Christopher Ferdinandi (Boston) Cory House (Kansas City) Joe Eames Special Guests: Nicholas Zakas In this episode, the panel talks with Nicholas Zakas who writes on his site, Human Who Codes. He is the creator of ESLint, also the author of several books, and he blogs, too. He was employed through Box and today he talks about ESLint in full detail! Check it out!  Show Topics: 0:05 – Advertisement: KENDO UI 0:37 – Hello! The panel is...(Chuck introduces everyone). 1:04 – Nicholas who are you? 1:17 – Nicholas: Yeah it’s been about 5 years and then you invited me again, but I couldn’t come on to talk about ESLint back then. That’s probably what people know me most for at this point. I created ESLint and I kicked that off and now a great team of people is maintaining it. 1:58 – Chuck: What is it? 2:04 – It’s a Linter for JavaScript. It falls into the same category as JSLint. The purpose of ESLint is to help you find problems with your code. It has grown quite a bit since I’ve created it. It can help with bugs and enforcing style guides and other things. 2:53 – Where did it come from? 2:57 – Guest: The idea popped into my head when I worked at Pop. One of my teammates was working on a bug and at that time we were using... Nothing was working and after investigating someone had written a JavaScript code that was using a native code to make an Ajax request. It wasn’t the best practice for the company at the time. For whatever reason the person was unaware of that. When using that native XML...there was a little bit of trickiness to it because it was a wrapper around the... We used a library to work around those situations and add a line (a Linter) for all JavaScript files. It was a text file and when you tried to render code through the process it would run and run the normal expression and it would fail if any of the...matched. I am not comfortable using normal expressions to write code for this. You could be matching in side of a string and it’s not a good way to be checking code for problems. I wanted to find a better way. 6:04 – Why did you choose to create a product vs. using other options out there? 6:15 – Guest: Both of those weren’t around. JSHint was pretty much the defector tool that everyone was using. My first thought was if JSHint could help with this problem? I went back to look at JSHint and I saw that on their roadmap you could create your own rules, and I thought that’s what we need. Why would I build something new? I didn’t see anything on GitHub and didn’t see the status of that. I wanted to see what the plan was, and they weren’t going to get to it. I said that I really needed this tool and I thought it would be helpful to others, too. 8:04 – My history was only back when it was customizable. 8:13 – Aimee: It’s interesting to see that they are basing it on regular expressions. 8:32 – Guest: Interesting thing at Box was that there was...I am not sure but one of the engineers at Box wrote... 9:03 – Aimee: I was going to ask in your opinion what do you think ES Lint is the standard now? 9:16 – Guest: How easy it is to plug things in. That was always my goal because I wanted the tool not to be boxed in – in anyway. The guest continues to talk about how pluggable ESLint is and the other features of this tool. 13:41 – One thing I like about ESLint is that it can be an educational tool for a team. Did you see that being an educational tool? 14:24 – Guest: How do you start introducing new things to a team that is running at full capacity? That is something that I’ve wondered throughout my career. As a result of that, I found that a new team there were some problems I the code base that were really hard to get resolved, because when one person recognizes it there isn’t a god way to share that information within a team in a non-confrontational way. It’s better to get angry at a tool rather than a person. Guest goes into what this can teach people. 18:07 – Panelist: I am not surprised. Is there a best practice to get a team to start with ESLint? Do you get the whole team in a room and show them the options or take the best guess and turn it on? 18:34 – Guest: The thing I recommend is that first and foremost get ESLint in your system with zero rules on. It starts that mindset into your development process. We can do something to automatically check... Get Syntax checking and you will se improvements on the number of bugs that are getting out of production. I recommend using the default the ESLint configuration. This has all of the things that we have found that are most likely errors and runtime errors vs. syntax errors. You can go through with those and sometimes it is easier to run that check with... Using those ESLint rules will clean up a lot of problems that you didn’t know you had with your code. There are too many problems with those rules. I recommend instead of turning them off then put the severity to warning and not error. That is something we started with in the beginning. We turned on as many rules as we could and it drove people crazy. They didn’t feel like when they were committing to a file why should I be... The idea with the different scenario levels you don’t’ want to turn off rules so people don’t know there is a problem. There can be a rule on so people will know that there is a problem, but... Doing that alone will give you a lot of benefit in using ESLint. How do you decide as a team on the rules that are maybe not for finding errors but for stylistic in error? Do we use four spaces, semi-colons, etc. To figure that out I am a big component on finding a pre-existing style guide and adapting it. Get everyone to agree. There is no right or wrong when it comes to stylistic preferences. It really is just getting everyone to do the same thing. I think it was Crawford that said: Whether you drive on the right side of the left side of the road – it doesn’t matter as long as everyone is dong the same thing. I agree with that and it applies to style guides. It can get heated but for the best thing for the team is stick with a guide and work together. 24:36 – Aimee: I can go through the options to pick one of the style guides out there and then it will automatically create my configuration for me is helpful. Question: If you had to pick 2 or 3 rules that you are super helpful what would they be? 25:30 – Guest: To touch briefly on indentation. Whether you like four spaces or whether you are wild and like tabs, I think the indent rule is very helpful. Just for wiping out and eliminating that discussion through your team. Have your editor setup however they want but on the pre-hook... But my favorite rules I tend to lean towards the ones that saved me. The Guest goes through his favorite rules with ESLint. Check it out! 26:51 – Guest mentions his second favorite rule, here! 28:24 – Guest mentions his third favorite rule, here! 29:03 – Guest mentions the rule that makes him giggle a lot, here! 30:07 – Advertisement – Sentry! 31:22 – What is your take on running Fix? Does it make sense to run Fix? 32:00 – Guest: It depends and the idea behind Fix is the idea of doing a one time (at the start) fix everything that it can find wrong b/c I don’t want to do it by hand. It morphed into a more of a tool that people are using all the time. I too have mixed feelings about it. I think the greatest value you get out of Fix is that when you first install it or when you enable a new rule. I think in those situations you get a lot of value out of Fix. I think that when people were getting aggressive with their code styles it took us down a path where we... As a pre-commit hook it could be to fix things and part of the built system you wouldn’t want... People are probably wondering: Why doesn’t ESLint doesn’t fix all the time? It can be a team decision: do you want to run Fix at the point that the developer is writing the code, do you want to use Fix as running it as a build when you are bundling? It really seems more of a personal preference. I am on the fence about it. Even though I am leaning more towards... 35:16 – Do you run Premier? 35:20 – Guest: No I don’t. I don’t have anything against Premier but I think Prettier uses a very interesting space. 37:50 – Chuck: What is next for ESLint and what is next for you? 37:55 – Guest: Well, to be honest I am not sure what is next for ESLint. I haven’t been involved with keeping it maintained for the last few years. I do help out with feedback with decisions. But in general the ESLint the direction is that let’s add tings that help people avoid language hazards and make sure that ESLint is still pluggable. Lastly, that we will be there to help people and the community. There is this virtuosic cycle and tools like Babble and then tools like ESLint introducing rules adapting new rules and features better. For myself, and the future, I haven’t been involved with ESLint because I am focusing on my health. I was diagnosed with Lyme Disease and it meant that I needed to focus on my health. That’s why, too, I wasn’t able to join a few years ago. I am doing better but I am a few years away for working fulltime and writing books and blogging, again. The trajectory is upward. I want to stress that you need to take care of yourself. There is interesting stuff that we are doing and I love it, but make sure you take care of yourself! If you don’t have your health then nothing will really matter. I want to encourage you all to take care of yourselves better. This industry can take a toll on your body b/c it is high-stressed. If you are stressed your immune system will shut down. For a lot of us we are working too much and there isn’t an off-switch. I would like to encourage people to examine their life and their time. When you take time to turn off your analytic brain, and work on your creative brain then the pathways will connect better. Please save your money! Lyme disease is spread through tick bites. 44:30 – Aimee: Thank you for sharing that! 44:38 – Chuck: It’s encouraging to me that you are still trying to come back even after this disease. I think we take things for granted sometimes. You can’t always count on things going the way you want it to go. 45:19 – Guest: What happened to me was I left work and one Friday afternoon I had a normal weekend. My health was on the decline, and I rested all weekend. And Monday I couldn’t get out of bed. That started this whole period where I stopped leaving the house completely. That’s how quickly things can change for you. I harp on people a lot to save their money. If I didn’t have savings there would be a very different end to my story. I want to encourage people to save. 46:33 – Chuck: I think on that note let’s go to picks. Where can people find you? 46:45 – Guest: My blog is Human Who Codes. 47:10 – Chuck: Anything people can do to help you? Check out his books you won’t regret it! 47:33 – Guest: Buying books is always helpful. I would say that if you can spend some time contributing to ESLint that is always a great help. Anything you can do to help them will help me. I want to make sure that those folks are happy, healthy and productive. For me, personally, I love when people Tweet at me and say HI! I love hearing other people’s stories of how they have overcome past diseases or illnesses. If you want to send monetary gifts – donate to a wonderful organization that helps children with Lyme disease. I would encourage you to support if you feel inclined. 50:49 – Chuck: We appreciate it, and I appreciate you being so open about your personal story. 51:11 – Advertisement – eBook: Get a coder job! Links: JavaScript jQuery React Elixir Elm Vue GitHub – Prettier GitHub – Premier Lyme Light Foundation Inclusive Components ESLint – Disallow Specific Imports State of JS Learn JavaScript Book: Total Recall Goodbye Redux YouTube Channel – Sideways Human Who Codes – Nicholas Zakas Nicholas’ Books Nicholas’ Twitter Nicholas’ GitHub Nicholas’ LinkedIn Sponsors: Kendo UI Sentry Cache Fly Get a Coder Job Picks: Aimee Technical debt Professional JavaScript for Web Developers Chris Inclusive Components Blog CSS Cascade JS Jabber - code Cory No Restricted Imports State of JS Total Recall Charles My JavaScript Story Joe Thought bubbles... Goodbye Redux Sideways Channel Nicholas The Brain that Changes Its Self Ghost Boy Tip - Turn off your Wi-Fi before Bed

Panel: Aimee Knight Charles Max Wood (DevChat TV) Christopher Ferdinandi (Boston) Cory House (Kansas City) Joe Eames Special Guests: Nicholas Zakas In this episode, the panel talks with Nicholas Zakas who writes on his site, Human Who Codes. He is the creator of ESLint, also the author of several books, and he blogs, too. He was employed through Box and today he talks about ESLint in full detail! Check it out!  Show Topics: 0:05 – Advertisement: KENDO UI 0:37 – Hello! The panel is...(Chuck introduces everyone). 1:04 – Nicholas who are you? 1:17 – Nicholas: Yeah it’s been about 5 years and then you invited me again, but I couldn’t come on to talk about ESLint back then. That’s probably what people know me most for at this point. I created ESLint and I kicked that off and now a great team of people is maintaining it. 1:58 – Chuck: What is it? 2:04 – It’s a Linter for JavaScript. It falls into the same category as JSLint. The purpose of ESLint is to help you find problems with your code. It has grown quite a bit since I’ve created it. It can help with bugs and enforcing style guides and other things. 2:53 – Where did it come from? 2:57 – Guest: The idea popped into my head when I worked at Pop. One of my teammates was working on a bug and at that time we were using... Nothing was working and after investigating someone had written a JavaScript code that was using a native code to make an Ajax request. It wasn’t the best practice for the company at the time. For whatever reason the person was unaware of that. When using that native XML...there was a little bit of trickiness to it because it was a wrapper around the... We used a library to work around those situations and add a line (a Linter) for all JavaScript files. It was a text file and when you tried to render code through the process it would run and run the normal expression and it would fail if any of the...matched. I am not comfortable using normal expressions to write code for this. You could be matching in side of a string and it’s not a good way to be checking code for problems. I wanted to find a better way. 6:04 – Why did you choose to create a product vs. using other options out there? 6:15 – Guest: Both of those weren’t around. JSHint was pretty much the defector tool that everyone was using. My first thought was if JSHint could help with this problem? I went back to look at JSHint and I saw that on their roadmap you could create your own rules, and I thought that’s what we need. Why would I build something new? I didn’t see anything on GitHub and didn’t see the status of that. I wanted to see what the plan was, and they weren’t going to get to it. I said that I really needed this tool and I thought it would be helpful to others, too. 8:04 – My history was only back when it was customizable. 8:13 – Aimee: It’s interesting to see that they are basing it on regular expressions. 8:32 – Guest: Interesting thing at Box was that there was...I am not sure but one of the engineers at Box wrote... 9:03 – Aimee: I was going to ask in your opinion what do you think ES Lint is the standard now? 9:16 – Guest: How easy it is to plug things in. That was always my goal because I wanted the tool not to be boxed in – in anyway. The guest continues to talk about how pluggable ESLint is and the other features of this tool. 13:41 – One thing I like about ESLint is that it can be an educational tool for a team. Did you see that being an educational tool? 14:24 – Guest: How do you start introducing new things to a team that is running at full capacity? That is something that I’ve wondered throughout my career. As a result of that, I found that a new team there were some problems I the code base that were really hard to get resolved, because when one person recognizes it there isn’t a god way to share that information within a team in a non-confrontational way. It’s better to get angry at a tool rather than a person. Guest goes into what this can teach people. 18:07 – Panelist: I am not surprised. Is there a best practice to get a team to start with ESLint? Do you get the whole team in a room and show them the options or take the best guess and turn it on? 18:34 – Guest: The thing I recommend is that first and foremost get ESLint in your system with zero rules on. It starts that mindset into your development process. We can do something to automatically check... Get Syntax checking and you will se improvements on the number of bugs that are getting out of production. I recommend using the default the ESLint configuration. This has all of the things that we have found that are most likely errors and runtime errors vs. syntax errors. You can go through with those and sometimes it is easier to run that check with... Using those ESLint rules will clean up a lot of problems that you didn’t know you had with your code. There are too many problems with those rules. I recommend instead of turning them off then put the severity to warning and not error. That is something we started with in the beginning. We turned on as many rules as we could and it drove people crazy. They didn’t feel like when they were committing to a file why should I be... The idea with the different scenario levels you don’t’ want to turn off rules so people don’t know there is a problem. There can be a rule on so people will know that there is a problem, but... Doing that alone will give you a lot of benefit in using ESLint. How do you decide as a team on the rules that are maybe not for finding errors but for stylistic in error? Do we use four spaces, semi-colons, etc. To figure that out I am a big component on finding a pre-existing style guide and adapting it. Get everyone to agree. There is no right or wrong when it comes to stylistic preferences. It really is just getting everyone to do the same thing. I think it was Crawford that said: Whether you drive on the right side of the left side of the road – it doesn’t matter as long as everyone is dong the same thing. I agree with that and it applies to style guides. It can get heated but for the best thing for the team is stick with a guide and work together. 24:36 – Aimee: I can go through the options to pick one of the style guides out there and then it will automatically create my configuration for me is helpful. Question: If you had to pick 2 or 3 rules that you are super helpful what would they be? 25:30 – Guest: To touch briefly on indentation. Whether you like four spaces or whether you are wild and like tabs, I think the indent rule is very helpful. Just for wiping out and eliminating that discussion through your team. Have your editor setup however they want but on the pre-hook... But my favorite rules I tend to lean towards the ones that saved me. The Guest goes through his favorite rules with ESLint. Check it out! 26:51 – Guest mentions his second favorite rule, here! 28:24 – Guest mentions his third favorite rule, here! 29:03 – Guest mentions the rule that makes him giggle a lot, here! 30:07 – Advertisement – Sentry! 31:22 – What is your take on running Fix? Does it make sense to run Fix? 32:00 – Guest: It depends and the idea behind Fix is the idea of doing a one time (at the start) fix everything that it can find wrong b/c I don’t want to do it by hand. It morphed into a more of a tool that people are using all the time. I too have mixed feelings about it. I think the greatest value you get out of Fix is that when you first install it or when you enable a new rule. I think in those situations you get a lot of value out of Fix. I think that when people were getting aggressive with their code styles it took us down a path where we... As a pre-commit hook it could be to fix things and part of the built system you wouldn’t want... People are probably wondering: Why doesn’t ESLint doesn’t fix all the time? It can be a team decision: do you want to run Fix at the point that the developer is writing the code, do you want to use Fix as running it as a build when you are bundling? It really seems more of a personal preference. I am on the fence about it. Even though I am leaning more towards... 35:16 – Do you run Premier? 35:20 – Guest: No I don’t. I don’t have anything against Premier but I think Prettier uses a very interesting space. 37:50 – Chuck: What is next for ESLint and what is next for you? 37:55 – Guest: Well, to be honest I am not sure what is next for ESLint. I haven’t been involved with keeping it maintained for the last few years. I do help out with feedback with decisions. But in general the ESLint the direction is that let’s add tings that help people avoid language hazards and make sure that ESLint is still pluggable. Lastly, that we will be there to help people and the community. There is this virtuosic cycle and tools like Babble and then tools like ESLint introducing rules adapting new rules and features better. For myself, and the future, I haven’t been involved with ESLint because I am focusing on my health. I was diagnosed with Lyme Disease and it meant that I needed to focus on my health. That’s why, too, I wasn’t able to join a few years ago. I am doing better but I am a few years away for working fulltime and writing books and blogging, again. The trajectory is upward. I want to stress that you need to take care of yourself. There is interesting stuff that we are doing and I love it, but make sure you take care of yourself! If you don’t have your health then nothing will really matter. I want to encourage you all to take care of yourselves better. This industry can take a toll on your body b/c it is high-stressed. If you are stressed your immune system will shut down. For a lot of us we are working too much and there isn’t an off-switch. I would like to encourage people to examine their life and their time. When you take time to turn off your analytic brain, and work on your creative brain then the pathways will connect better. Please save your money! Lyme disease is spread through tick bites. 44:30 – Aimee: Thank you for sharing that! 44:38 – Chuck: It’s encouraging to me that you are still trying to come back even after this disease. I think we take things for granted sometimes. You can’t always count on things going the way you want it to go. 45:19 – Guest: What happened to me was I left work and one Friday afternoon I had a normal weekend. My health was on the decline, and I rested all weekend. And Monday I couldn’t get out of bed. That started this whole period where I stopped leaving the house completely. That’s how quickly things can change for you. I harp on people a lot to save their money. If I didn’t have savings there would be a very different end to my story. I want to encourage people to save. 46:33 – Chuck: I think on that note let’s go to picks. Where can people find you? 46:45 – Guest: My blog is Human Who Codes. 47:10 – Chuck: Anything people can do to help you? Check out his books you won’t regret it! 47:33 – Guest: Buying books is always helpful. I would say that if you can spend some time contributing to ESLint that is always a great help. Anything you can do to help them will help me. I want to make sure that those folks are happy, healthy and productive. For me, personally, I love when people Tweet at me and say HI! I love hearing other people’s stories of how they have overcome past diseases or illnesses. If you want to send monetary gifts – donate to a wonderful organization that helps children with Lyme disease. I would encourage you to support if you feel inclined. 50:49 – Chuck: We appreciate it, and I appreciate you being so open about your personal story. 51:11 – Advertisement – eBook: Get a coder job! Links: JavaScript jQuery React Elixir Elm Vue GitHub – Prettier GitHub – Premier Lyme Light Foundation Inclusive Components ESLint – Disallow Specific Imports State of JS Learn JavaScript Book: Total Recall Goodbye Redux YouTube Channel – Sideways Human Who Codes – Nicholas Zakas Nicholas’ Books Nicholas’ Twitter Nicholas’ GitHub Nicholas’ LinkedIn Sponsors: Kendo UI Sentry Cache Fly Get a Coder Job Picks: Aimee Technical debt Professional JavaScript for Web Developers Chris Inclusive Components Blog CSS Cascade JS Jabber - code Cory No Restricted Imports State of JS Total Recall Charles My JavaScript Story Joe Thought bubbles... Goodbye Redux Sideways Channel Nicholas The Brain that Changes Its Self Ghost Boy Tip - Turn off your Wi-Fi before Bed

Panel: Aimee Knight Charles Max Wood (DevChat TV) Christopher Ferdinandi (Boston) Cory House (Kansas City) Joe Eames Special Guests: Nicholas Zakas In this episode, the panel talks with Nicholas Zakas who writes on his site, Human Who Codes. He is the creator of ESLint, also the author of several books, and he blogs, too. He was employed through Box and today he talks about ESLint in full detail! Check it out!  Show Topics: 0:05 – Advertisement: KENDO UI 0:37 – Hello! The panel is...(Chuck introduces everyone). 1:04 – Nicholas who are you? 1:17 – Nicholas: Yeah it’s been about 5 years and then you invited me again, but I couldn’t come on to talk about ESLint back then. That’s probably what people know me most for at this point. I created ESLint and I kicked that off and now a great team of people is maintaining it. 1:58 – Chuck: What is it? 2:04 – It’s a Linter for JavaScript. It falls into the same category as JSLint. The purpose of ESLint is to help you find problems with your code. It has grown quite a bit since I’ve created it. It can help with bugs and enforcing style guides and other things. 2:53 – Where did it come from? 2:57 – Guest: The idea popped into my head when I worked at Pop. One of my teammates was working on a bug and at that time we were using... Nothing was working and after investigating someone had written a JavaScript code that was using a native code to make an Ajax request. It wasn’t the best practice for the company at the time. For whatever reason the person was unaware of that. When using that native XML...there was a little bit of trickiness to it because it was a wrapper around the... We used a library to work around those situations and add a line (a Linter) for all JavaScript files. It was a text file and when you tried to render code through the process it would run and run the normal expression and it would fail if any of the...matched. I am not comfortable using normal expressions to write code for this. You could be matching in side of a string and it’s not a good way to be checking code for problems. I wanted to find a better way. 6:04 – Why did you choose to create a product vs. using other options out there? 6:15 – Guest: Both of those weren’t around. JSHint was pretty much the defector tool that everyone was using. My first thought was if JSHint could help with this problem? I went back to look at JSHint and I saw that on their roadmap you could create your own rules, and I thought that’s what we need. Why would I build something new? I didn’t see anything on GitHub and didn’t see the status of that. I wanted to see what the plan was, and they weren’t going to get to it. I said that I really needed this tool and I thought it would be helpful to others, too. 8:04 – My history was only back when it was customizable. 8:13 – Aimee: It’s interesting to see that they are basing it on regular expressions. 8:32 – Guest: Interesting thing at Box was that there was...I am not sure but one of the engineers at Box wrote... 9:03 – Aimee: I was going to ask in your opinion what do you think ES Lint is the standard now? 9:16 – Guest: How easy it is to plug things in. That was always my goal because I wanted the tool not to be boxed in – in anyway. The guest continues to talk about how pluggable ESLint is and the other features of this tool. 13:41 – One thing I like about ESLint is that it can be an educational tool for a team. Did you see that being an educational tool? 14:24 – Guest: How do you start introducing new things to a team that is running at full capacity? That is something that I’ve wondered throughout my career. As a result of that, I found that a new team there were some problems I the code base that were really hard to get resolved, because when one person recognizes it there isn’t a god way to share that information within a team in a non-confrontational way. It’s better to get angry at a tool rather than a person. Guest goes into what this can teach people. 18:07 – Panelist: I am not surprised. Is there a best practice to get a team to start with ESLint? Do you get the whole team in a room and show them the options or take the best guess and turn it on? 18:34 – Guest: The thing I recommend is that first and foremost get ESLint in your system with zero rules on. It starts that mindset into your development process. We can do something to automatically check... Get Syntax checking and you will se improvements on the number of bugs that are getting out of production. I recommend using the default the ESLint configuration. This has all of the things that we have found that are most likely errors and runtime errors vs. syntax errors. You can go through with those and sometimes it is easier to run that check with... Using those ESLint rules will clean up a lot of problems that you didn’t know you had with your code. There are too many problems with those rules. I recommend instead of turning them off then put the severity to warning and not error. That is something we started with in the beginning. We turned on as many rules as we could and it drove people crazy. They didn’t feel like when they were committing to a file why should I be... The idea with the different scenario levels you don’t’ want to turn off rules so people don’t know there is a problem. There can be a rule on so people will know that there is a problem, but... Doing that alone will give you a lot of benefit in using ESLint. How do you decide as a team on the rules that are maybe not for finding errors but for stylistic in error? Do we use four spaces, semi-colons, etc. To figure that out I am a big component on finding a pre-existing style guide and adapting it. Get everyone to agree. There is no right or wrong when it comes to stylistic preferences. It really is just getting everyone to do the same thing. I think it was Crawford that said: Whether you drive on the right side of the left side of the road – it doesn’t matter as long as everyone is dong the same thing. I agree with that and it applies to style guides. It can get heated but for the best thing for the team is stick with a guide and work together. 24:36 – Aimee: I can go through the options to pick one of the style guides out there and then it will automatically create my configuration for me is helpful. Question: If you had to pick 2 or 3 rules that you are super helpful what would they be? 25:30 – Guest: To touch briefly on indentation. Whether you like four spaces or whether you are wild and like tabs, I think the indent rule is very helpful. Just for wiping out and eliminating that discussion through your team. Have your editor setup however they want but on the pre-hook... But my favorite rules I tend to lean towards the ones that saved me. The Guest goes through his favorite rules with ESLint. Check it out! 26:51 – Guest mentions his second favorite rule, here! 28:24 – Guest mentions his third favorite rule, here! 29:03 – Guest mentions the rule that makes him giggle a lot, here! 30:07 – Advertisement – Sentry! 31:22 – What is your take on running Fix? Does it make sense to run Fix? 32:00 – Guest: It depends and the idea behind Fix is the idea of doing a one time (at the start) fix everything that it can find wrong b/c I don’t want to do it by hand. It morphed into a more of a tool that people are using all the time. I too have mixed feelings about it. I think the greatest value you get out of Fix is that when you first install it or when you enable a new rule. I think in those situations you get a lot of value out of Fix. I think that when people were getting aggressive with their code styles it took us down a path where we... As a pre-commit hook it could be to fix things and part of the built system you wouldn’t want... People are probably wondering: Why doesn’t ESLint doesn’t fix all the time? It can be a team decision: do you want to run Fix at the point that the developer is writing the code, do you want to use Fix as running it as a build when you are bundling? It really seems more of a personal preference. I am on the fence about it. Even though I am leaning more towards... 35:16 – Do you run Premier? 35:20 – Guest: No I don’t. I don’t have anything against Premier but I think Prettier uses a very interesting space. 37:50 – Chuck: What is next for ESLint and what is next for you? 37:55 – Guest: Well, to be honest I am not sure what is next for ESLint. I haven’t been involved with keeping it maintained for the last few years. I do help out with feedback with decisions. But in general the ESLint the direction is that let’s add tings that help people avoid language hazards and make sure that ESLint is still pluggable. Lastly, that we will be there to help people and the community. There is this virtuosic cycle and tools like Babble and then tools like ESLint introducing rules adapting new rules and features better. For myself, and the future, I haven’t been involved with ESLint because I am focusing on my health. I was diagnosed with Lyme Disease and it meant that I needed to focus on my health. That’s why, too, I wasn’t able to join a few years ago. I am doing better but I am a few years away for working fulltime and writing books and blogging, again. The trajectory is upward. I want to stress that you need to take care of yourself. There is interesting stuff that we are doing and I love it, but make sure you take care of yourself! If you don’t have your health then nothing will really matter. I want to encourage you all to take care of yourselves better. This industry can take a toll on your body b/c it is high-stressed. If you are stressed your immune system will shut down. For a lot of us we are working too much and there isn’t an off-switch. I would like to encourage people to examine their life and their time. When you take time to turn off your analytic brain, and work on your creative brain then the pathways will connect better. Please save your money! Lyme disease is spread through tick bites. 44:30 – Aimee: Thank you for sharing that! 44:38 – Chuck: It’s encouraging to me that you are still trying to come back even after this disease. I think we take things for granted sometimes. You can’t always count on things going the way you want it to go. 45:19 – Guest: What happened to me was I left work and one Friday afternoon I had a normal weekend. My health was on the decline, and I rested all weekend. And Monday I couldn’t get out of bed. That started this whole period where I stopped leaving the house completely. That’s how quickly things can change for you. I harp on people a lot to save their money. If I didn’t have savings there would be a very different end to my story. I want to encourage people to save. 46:33 – Chuck: I think on that note let’s go to picks. Where can people find you? 46:45 – Guest: My blog is Human Who Codes. 47:10 – Chuck: Anything people can do to help you? Check out his books you won’t regret it! 47:33 – Guest: Buying books is always helpful. I would say that if you can spend some time contributing to ESLint that is always a great help. Anything you can do to help them will help me. I want to make sure that those folks are happy, healthy and productive. For me, personally, I love when people Tweet at me and say HI! I love hearing other people’s stories of how they have overcome past diseases or illnesses. If you want to send monetary gifts – donate to a wonderful organization that helps children with Lyme disease. I would encourage you to support if you feel inclined. 50:49 – Chuck: We appreciate it, and I appreciate you being so open about your personal story. 51:11 – Advertisement – eBook: Get a coder job! Links: JavaScript jQuery React Elixir Elm Vue GitHub – Prettier GitHub – Premier Lyme Light Foundation Inclusive Components ESLint – Disallow Specific Imports State of JS Learn JavaScript Book: Total Recall Goodbye Redux YouTube Channel – Sideways Human Who Codes – Nicholas Zakas Nicholas’ Books Nicholas’ Twitter Nicholas’ GitHub Nicholas’ LinkedIn Sponsors: Kendo UI Sentry Cache Fly Get a Coder Job Picks: Aimee Technical debt Professional JavaScript for Web Developers Chris Inclusive Components Blog CSS Cascade JS Jabber - code Cory No Restricted Imports State of JS Total Recall Charles My JavaScript Story Joe Thought bubbles... Goodbye Redux Sideways Channel Nicholas The Brain that Changes Its Self Ghost Boy Tip - Turn off your Wi-Fi before Bed

Panel: Charles Max Wood Mark Eriksen Eric Berry Special Guest: Andrew Summers In this episode of Elixir Mix, the panel talks to Andrew Summers who lives in Chicago, currently. Working on Elixir development, and here to talk about how he wrote the dialyzer pretty printer. He is a software engineer for Albert.io, makes cool stuff every day, loves punk music, and Philadelphia sports. The panel talks about the Dialyzer pretty printing, Elixir, code writing, and more! Show Topics: 1:07 – Why are you famous? 1:11 – Andrew: Answers the question. 1:34 – Chuck: Nice. Is the dialyzer printer complete pretty printing or is it more than that? 1:45 – Andrew talks. He mentions the background information on this specific printer, which was written a decade ago. 4:13 – Panel: One thing that is helpful is that it is a static code analysis. In the Elixir we are writing these spec statements. For nothing else than this type is coming out. Then this looks at the code, and your spec says you are returning this, but I can tell that you are also returning X, Y, or Z. So it is helping us see what we are declaring a code to do, and that’s really what the code is doing. 5:28 – Guest: Yes, exactly. To continue that topic here is what else it’s saying... 6:08 – Panel: Our panelist is not here, but he has had to fix code before with that problem. With Dialect Dialyzer – how do we say this library is out-of-date? The code is out-of-date. How do I get my stuff to pass – to clean up my site? 6:54 – Guest: Containing that warning. Guest goes into further detail how to problem-solve this issue. 8:02 – Panel: So you are saying that I can funnel. 8:20 – Panel & Guest go back-and-forth talking about this topic. 9:49 – Panel: I am still diving into the system. Haven’t really used the printer, yet. Panelist asks Guest a question. 10:04 – Guest: At the forefront there are some configurations to help with that. 11:16 – Panel: Why would someone not want to use this? What are the cons? 11:23 – Guest: It would have to do more with CI than anything (one con). 13:06 – Panel: Lots of people are coming to Elixir New. Great. What is the selling point? Why should someone invest his or her time in this project? 13:33 – Guest: I find looking for a type spec is one more piece of information that could help the reader that would tell them what the code should be doing. Any information from the original author to be passed down is great. Having the machine to check that, whenever you push code, it’s an imperfect check (as we were saying). If it can tell you that you did something wrong, then why not? It gives you that extra red flag. There are huge benefits to that. Same reason we write unit tests. 15:20 – Panel: You are learning Elixir right, Chuck? Panelist talks about tech specs, code writing, and learning projects. 16:25 – Panel: Here is a tip to learning. One thing that I did I came to an existing project and writing a sub-system ( as series of modules) Writing the tech specs. As they are interacting with each other, then writing Dial Elixir, and grab the output to the file path to where my code is. Within my own code find where I am inconsistent. Andrew – you could get pages of output, right? Any tips for users? 17:37 – Guest: Isolate portions of your code base. 19:27 – Chuck: I do like the idea of the umbrella. Phoenix app out into an umbrella. A sub apps and they are more centered, smaller sized. Then, yeah. Start with Dialyzer on just that project. Isolate it, and this app in the umbrella. The output is much smaller, and good success with that. Now, one of the new features you added was the language / the code that it reports is an ERLANG term. That is not familiar to most Elixir developers. Especially if you are new to it. If you are turning this into a friendly Elixir thing, then you had to learn other programs. How did you get into this path? 21:00 – Andrew: Whenever there was complicated “something” at work – I was the person to go to. As I started to do it more and more I saw patterns in the output. Things were kind of predictable, and how to format things. It synchronizes weird. What would I do to write this task? Researched. There are 2 tools = LEEX and YECC. If you have 2 files in your source directory... 22:56 – Advertisement – Digital Ocean 23:39 – Panel: It’s cool. 23:58 – Guest: It brought me back to some courses from school. I thought that was funny. They are pretty contained tools. 24:36 – Panel: Part of your motivation was from Jose. 24:49 – Guest: Yes, definitely. 25:39 – Did you have any questions for Jose? 26:35 – Panel: You added the feature of... CREDO is pretty well-known. 27:28 – Guest: Sure, I guess I did skip some of that. Andrew talked about different libraries, ERLANG modules, and so on. 28:38 – Panel: What else are you doing? 28:45 – Getting error messages fixed for version 1.0. Trying to close-up the residual things. 30:18 – Guest keeps talking about support and other bugs. Andrew: If you see something, say something. 31:00 - Panel: There are languages that run on the beam. Something to create something more standard so different languages can depend on. Is there anything like that? To help you with your tooling? 31:40 – Andrew: Good question! Some of the things that happen at the Dialyzer level, stuff just gets dropped. 33:47 – Guest: How this works all together... 35:15 – Chuck: How to contribute to Dialyxir? 35:30 – Guest: Around error messages – is the best place to look. If you have a good editor hand, good place for that. If you are further into the compiler land – might want to play with that. 36:29 – Guest: ERLEX 36:43 – Chuck: What did you learn about building these libraries? 36:55 – Guest: I learned a lot about the construction of Elixir. Guest dives into this more. 38:25 – Chuck: The principle that you cannot bind... 38:51 – Guest: ...this area of my code-base... it would be nice to turn off those features. When I really do need it – I need it, but not so if I don’t need it. 39:39 – Panel: I want to point someone to a resource: TypeSpecs. 39:54 – Guest: I used that so much! Wonderful resource, I learned so much stuff! I stole all the output from that. I didn’t know that language had that?! 40:20 – Panel chimes in about this resource some more. 41:02 – Guest: We really do have a simple language. There are some weird things, but not a lot of constructs under the hood. Only a few data structures. It could have been more complicated. I was worried about that – but that never happened, because... 41:41 – Panel: Thanks for adding that. Very true. 42:51 – Guest talks about other things that are very simple, too. 44:35 – Panel: Are you doing fulltime with Elixir for programming? 44:35 – Guest: Yes, we are using other Elixir and JS App. In another life I used... They all can teach you something. Sometimes the journey of going there and realizing WHY you don’t want to be there is sometimes worth the journey! 45:20 – Panel asks guest a question. 45:25 – Guest answers question. Andrew: We have enjoyed our time in Elixir. It’s nice. 46:27 – Panel: Anything else? 46:33 – Panel: Where can people find you online? 46:40 – Guest: Elixir Slack, Twitter, GitHub. 47:01 – Picks! 47:05 – Advertisement – Code Badges Links: Andrew Summers’ Twitter Credo Erlang Dialyxir LEEX YECC Credo ERLEX TypeSpecs Curated Dev News for Busy Developers EX_JSON_SCHEMA React – Jsonschema – form Announcing Distillery 2.0 Distillery’s documentation! MKDocs EX_Json_Schema Sponsors: Get a Coder Job Digital Ocean Code Badges Cache Fly Picks: Eric Chrome Extension for News Mark Announcing Distillery 2.0 MKdocs https://hexdocs.pm/distillery/home.html. Charles  Launch by Jeff Walker Downcast Andrew Ex json Schema React json schema from

Panel: Charles Max Wood Mark Eriksen Eric Berry Special Guest: Andrew Summers In this episode of Elixir Mix, the panel talks to Andrew Summers who lives in Chicago, currently. Working on Elixir development, and here to talk about how he wrote the dialyzer pretty printer. He is a software engineer for Albert.io, makes cool stuff every day, loves punk music, and Philadelphia sports. The panel talks about the Dialyzer pretty printing, Elixir, code writing, and more! Show Topics: 1:07 – Why are you famous? 1:11 – Andrew: Answers the question. 1:34 – Chuck: Nice. Is the dialyzer printer complete pretty printing or is it more than that? 1:45 – Andrew talks. He mentions the background information on this specific printer, which was written a decade ago. 4:13 – Panel: One thing that is helpful is that it is a static code analysis. In the Elixir we are writing these spec statements. For nothing else than this type is coming out. Then this looks at the code, and your spec says you are returning this, but I can tell that you are also returning X, Y, or Z. So it is helping us see what we are declaring a code to do, and that’s really what the code is doing. 5:28 – Guest: Yes, exactly. To continue that topic here is what else it’s saying... 6:08 – Panel: Our panelist is not here, but he has had to fix code before with that problem. With Dialect Dialyzer – how do we say this library is out-of-date? The code is out-of-date. How do I get my stuff to pass – to clean up my site? 6:54 – Guest: Containing that warning. Guest goes into further detail how to problem-solve this issue. 8:02 – Panel: So you are saying that I can funnel. 8:20 – Panel & Guest go back-and-forth talking about this topic. 9:49 – Panel: I am still diving into the system. Haven’t really used the printer, yet. Panelist asks Guest a question. 10:04 – Guest: At the forefront there are some configurations to help with that. 11:16 – Panel: Why would someone not want to use this? What are the cons? 11:23 – Guest: It would have to do more with CI than anything (one con). 13:06 – Panel: Lots of people are coming to Elixir New. Great. What is the selling point? Why should someone invest his or her time in this project? 13:33 – Guest: I find looking for a type spec is one more piece of information that could help the reader that would tell them what the code should be doing. Any information from the original author to be passed down is great. Having the machine to check that, whenever you push code, it’s an imperfect check (as we were saying). If it can tell you that you did something wrong, then why not? It gives you that extra red flag. There are huge benefits to that. Same reason we write unit tests. 15:20 – Panel: You are learning Elixir right, Chuck? Panelist talks about tech specs, code writing, and learning projects. 16:25 – Panel: Here is a tip to learning. One thing that I did I came to an existing project and writing a sub-system ( as series of modules) Writing the tech specs. As they are interacting with each other, then writing Dial Elixir, and grab the output to the file path to where my code is. Within my own code find where I am inconsistent. Andrew – you could get pages of output, right? Any tips for users? 17:37 – Guest: Isolate portions of your code base. 19:27 – Chuck: I do like the idea of the umbrella. Phoenix app out into an umbrella. A sub apps and they are more centered, smaller sized. Then, yeah. Start with Dialyzer on just that project. Isolate it, and this app in the umbrella. The output is much smaller, and good success with that. Now, one of the new features you added was the language / the code that it reports is an ERLANG term. That is not familiar to most Elixir developers. Especially if you are new to it. If you are turning this into a friendly Elixir thing, then you had to learn other programs. How did you get into this path? 21:00 – Andrew: Whenever there was complicated “something” at work – I was the person to go to. As I started to do it more and more I saw patterns in the output. Things were kind of predictable, and how to format things. It synchronizes weird. What would I do to write this task? Researched. There are 2 tools = LEEX and YECC. If you have 2 files in your source directory... 22:56 – Advertisement – Digital Ocean 23:39 – Panel: It’s cool. 23:58 – Guest: It brought me back to some courses from school. I thought that was funny. They are pretty contained tools. 24:36 – Panel: Part of your motivation was from Jose. 24:49 – Guest: Yes, definitely. 25:39 – Did you have any questions for Jose? 26:35 – Panel: You added the feature of... CREDO is pretty well-known. 27:28 – Guest: Sure, I guess I did skip some of that. Andrew talked about different libraries, ERLANG modules, and so on. 28:38 – Panel: What else are you doing? 28:45 – Getting error messages fixed for version 1.0. Trying to close-up the residual things. 30:18 – Guest keeps talking about support and other bugs. Andrew: If you see something, say something. 31:00 - Panel: There are languages that run on the beam. Something to create something more standard so different languages can depend on. Is there anything like that? To help you with your tooling? 31:40 – Andrew: Good question! Some of the things that happen at the Dialyzer level, stuff just gets dropped. 33:47 – Guest: How this works all together... 35:15 – Chuck: How to contribute to Dialyxir? 35:30 – Guest: Around error messages – is the best place to look. If you have a good editor hand, good place for that. If you are further into the compiler land – might want to play with that. 36:29 – Guest: ERLEX 36:43 – Chuck: What did you learn about building these libraries? 36:55 – Guest: I learned a lot about the construction of Elixir. Guest dives into this more. 38:25 – Chuck: The principle that you cannot bind... 38:51 – Guest: ...this area of my code-base... it would be nice to turn off those features. When I really do need it – I need it, but not so if I don’t need it. 39:39 – Panel: I want to point someone to a resource: TypeSpecs. 39:54 – Guest: I used that so much! Wonderful resource, I learned so much stuff! I stole all the output from that. I didn’t know that language had that?! 40:20 – Panel chimes in about this resource some more. 41:02 – Guest: We really do have a simple language. There are some weird things, but not a lot of constructs under the hood. Only a few data structures. It could have been more complicated. I was worried about that – but that never happened, because... 41:41 – Panel: Thanks for adding that. Very true. 42:51 – Guest talks about other things that are very simple, too. 44:35 – Panel: Are you doing fulltime with Elixir for programming? 44:35 – Guest: Yes, we are using other Elixir and JS App. In another life I used... They all can teach you something. Sometimes the journey of going there and realizing WHY you don’t want to be there is sometimes worth the journey! 45:20 – Panel asks guest a question. 45:25 – Guest answers question. Andrew: We have enjoyed our time in Elixir. It’s nice. 46:27 – Panel: Anything else? 46:33 – Panel: Where can people find you online? 46:40 – Guest: Elixir Slack, Twitter, GitHub. 47:01 – Picks! 47:05 – Advertisement – Code Badges Links: Andrew Summers’ Twitter Credo Erlang Dialyxir LEEX YECC Credo ERLEX TypeSpecs Curated Dev News for Busy Developers EX_JSON_SCHEMA React – Jsonschema – form Announcing Distillery 2.0 Distillery’s documentation! MKDocs EX_Json_Schema Sponsors: Get a Coder Job Digital Ocean Code Badges Cache Fly Picks: Eric Chrome Extension for News Mark Announcing Distillery 2.0 MKdocs https://hexdocs.pm/distillery/home.html. Charles  Launch by Jeff Walker Downcast Andrew Ex json Schema React json schema from

Justin Schenck has been named a Top 8 Podcaster to watch in 2018 by INC.com and chosen as an ‘Icon of Influence’ in the new media space. He not only speaks to organizations on how to overcome adversity and utilize podcasting to grow your business but he helps others launch and grow their own podcasts with www.beginpodcastingnow.com. His vision? To teach the world how to live happy no matter where they are today. He teaches people that “It’s about the journey not the destination.”   Quotes To Remember: “It’s about the journey not the destination.” “At any given time in this world, there’s 75,000 people that may be hearing your message from you.” “If you are able to give a 100% of yourself to everybody, no matter who they are, you will always win.” “The important part is keeping the people that you need to keep.” “What’s not growing is dead.” “All we can worry about is right now.” What You’ll Learn: Essentials for Laying Down a Strong Podcast Foundation How To Stay Yourself When Interviewing a Guest How to Get More People to Help Out Promoting Our Episodes Getting Listeners to Stick Around and Continue Listening to Podcast Episodes   Key Links From The Show: Justin’s SitePreston Smiles Interview about Abundance School of Greatness Podcast   Recommended Books: Who Moved My Cheese? by Spencer Johnson The Secret by Rhonda Byrne The Last Lecture by Jeffrey Zaslow and Randy Pausch   Support Breakthrough Success On Patreon Please consider supporting Breakthrough Success on Patreon. I publish five episodes per week which I carefully prepare for, and I choose to not run ads in my podcast to enhance the listener experience. I offer my patrons various perks, and even a donation as small as $1/mo would make a big difference for growing and maintaining Breakthrough Success. You can support Breakthrough Success by going here.