Podcasts about react rally

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

Video: https://youtu.be/Cxaf8E00GMMSlides: https://docs.google.com/presentation/d/1sJSqNy-t-kVxzrWlqMTp_03nI7Zo8Znr7k0f0C6L9ig/edit?usp=sharingTimestamps:[00:00:00] Intro[00:02:17] Part 1 - Components: Code Organization for Real Apps [00:04:26] What we learned from React [00:07:46] Part 2 - Architecture: Choreography vs Orchestration [00:13:05] Retries and Timeouts [00:14:37] Part 3 - Time: React vs Temporal[00:16:34] Elevator Pitch [00:17:13] Programming Model [00:18:44] Comparing React and Temporal Principles [00:19:11] Live Demo: Amazon One Click Button [00:23:49] Talk Recap [00:24:16] React and Temporal Full Comparison [00:24:42] Conclusion: EnablementTranscript [00:00:00] Once again, I want to thank you all for tuning in and joining, React New York 2021 without further ado, I'll pass it on to Shawn. All right, so hi everyone. Hello, React new York. It is my home town in the U S and I miss everyone back in New York. I am currently based in Seattle, but I'm here to talk about React for the Backend. In 2020 I actually thought that I had given my last React talk because I was all tapped out. I had said everything I wanted to say, and then React New York came by and said, do you want to speak? And I was like, oh, I really wanted to speak for React New York. So here's my presentation about what I've been working on and what I think the parallels have been for React. And I think there's some generalizable lessons, even if you don't end up using Temporal. So, the inspiration for this talk came from Guillermo Rauch, the creator of Next.js. And he was the first person to point out that Temporal.io, does to backend and infra what React did to frontend. Temporal engine is quite complex, much like React, but the surface exposed to developers a beautiful render function and I'm a bit upset because he realized there's before me and I have been working on Temporal for a few months now. So important caveats before I start this talk. What I'm presenting to you is alpha for TypeScript. Temporal is typically a goal or Java based application, but we're developing TypeScript and hopefully launching it soon. And then finally "React for the backend" is an analogy, not a design goal.  The way I treat this is like, it's a, it's basically like crabs. And one of the most entertaining facts that I've ever found is that nature has apparently tried to evolve crabs five independent times. And in fact, there's a word in evolutionary biology for it called Carcinization. And of course, this is really good for a lot of memes. So tired convergent evolution is not uncommon, especially when species have similar selecting pressures in their environments, wired. Everything is Crab. And perhaps everything is React, because we have similar design space problems. So I'll tell a little bit of the story through three parts there's Components, and we'll tell it through the story of Uber, talk about architecture, we'll talk through the story of YouTube, and Time will tell you through the story of Amazon. So a lot to cover, I'm going to try to go really fast. Don't worry. I'll share the slides on my Twitter later on. Okay.  [00:02:17] Part 1 - Components: Code Organization for Real Apps  So part one is about components. You see this a lot on YouTube. Probably you're watching now on YouTube or live streaming. And yeah, you know, like three hour live stream and that's it. Very cool. I think we, we know how to break things down and React has really helped us be more productive by being able to break things down into the components and knowing how to compose them together in a predictable way. But there's a lot of things unanswered in things like this in, in full stack, clones of major well-known apps, which is the hard parts. What like a typical Uber trip, we'll have all these steps like search pricing match. Pick-up drop-off rating tipping, payment, email, uh, and so on and so forth. And typically the naive way of organizing all this is basically one after the other, right? Like this is search goes to pricing, goes to matching, goes to pick upgoes to dropoff goes to rating goes to tipping goes to payment, goes to email, imagine that these are all managed by separate teams and scaled independently. Then you realize, like, this is only the happy path. Then you have to throw in a whole bunch of things that can happen along the way. An Uber trip is basically a long running process with humans in the loop and humans are very, very messy by nature. So how would you write an Uber clone? good luck with a lot of data technologies that you would typically reach for just naively, because you will have to discover all these systems and all these use cases and edge cases along the way. So when people say full stack, they often really mean like this half drawn horse meme. I think this is particularly funny so I take every opportunity I can get to show it, but to be honest, a lot of us front end developers are probably the other way the half-drawn Dragon where we're frontend a very good and in the backend, we'll just like, you know, stick some stuff on Firebase and something. And in reality, if you look at the backend systems, most companies, especially at scale, go towards some form of very complex micro service, system. I don't have the chart for Uber, but Hail-0 is probably a good comparison. Netflix, Twitter, and It's not really avoidable. If you want to scale a company to any significant size, you probably have to break them up into independent services because you're going to ship your org chart anyway. [00:04:26] What we learned from React  The thing I realized as a React developer, as a front end developer, is that actually we had a pretty good run in the past seven, eight years of React in terms of the fact that front end developers know how to organize code at least in terms of the component level. So we moved from the jQuery era where everything was just kind of spaghetti all over the place to at least something more organized where event handlers are strongly tied, locally tied with renders, but essentially managed by React's runtime.  So a few key lessons from React that I personally draw [00:05:00] is that you want to have a component and a renderer model. Like, so essentially the user or the developer writes components. And then the react core team writes the render and that handles a lot of the boilerplate that you might typically forget. And this is everything to do with on mounting or having local states. And it gives you a very nice, non-leaky abstraction that you can write. Second, you can also guarantee work and correctness, which is originally what drew Jordan walk to make something like React because he was working on Facebook messenger and there was a lot of inconsistent state within Facebook manager because of the spaghetti code. So correctness, meaning that we embrace functional programming to produce a virtual DOM view is a pure function of state. If you look at the old enough React talks, you will see a lot of v = f(d), so view as a pure function of data. And finally the programming model. We like to say that it's just JavaScript. There's no custom syntax with templating syntax to learn. I think all these three lessons , there are actually a lot more, but all of these three lessons are where I'm going to focus on for this talk. And I think whenever you tackle any programming paradigm, any framework, any design question, you might want to run it through some of these ideas. So whenever I talk about React principles, I always like to bring up the fact that there's this often overlooked repo called react-basic. And it's actually in the official React organization on GitHub. And this is Sebastian Markbage, who is the tech lead of React. And he wrote down six years ago, his principles on what he thinks makes up React on a fundamental basis? No, JSX just like, what are the principles that we're designing for? We are designing for a simple, pure transformation, abstraction, composition, state, memoization. The words that he uses are very theoretical sometimes, but you feel it every single day when you write React. So there's a lot of things else apart from that, that reacts has done for front end programming. Apart from deterministic renders, we have useState with a reduction of boiler plate with unmounting, child components in con in the very careful design composition, um, side effects where, you know, we have used effect or use memo. And actually a lot of people don't know. I don't, I forget my source. I think it's Sophie Alpert, but, one-third of the React code base is actually just normalization of events across browsers. So you don't even have to worry about it. And creating synthetic events for that. They also produce a dev tool and manage a central scheduler and obviously the success of React over the past five, six years has really shown Testament to how great all these decisions have been.  If you want to learn more about the talks that I've done and my perspectives on some of these React principles, I've done three talks. One is at React Rally. The second at JSConf and the third, ,at React Summit. So you can check out my YouTube for more conversations on that. I don't have time here. Okay.  [00:07:46] Part 2 - Architecture: Choreography vs Orchestration  So that was part one where we talked about Components and the React revolution. So part two, we're going to talk about architecture. So a bit, one level higher than just components. And I'm going to motivate this question with a question of how would you write YouTube. And again, if you look on YouTube for how to write YouTube tutorials, you can get full-stack clones of YouTube, which is pretty impressive, you know, write YouTube in three hours using Firebase. That's very impressive. Unfortunately the hard parts of YouTube also come in. And there are a bunch of Googlers actually who actually went and interviewed YouTube engineers on how YouTube works on the backend. There's a bunch of work that goes on in the background. So you need to upload your file. You need to analyze for metadata. You need to split it up into chunks. You need to process these chunks in parallel, and then you need to stitch it back. And by the way, processing, you have to produce an array of formats, right? From like, 240 P to like 1400 P or something like that. And then you have to stitch all these chunks back into the continuous videos that you actually see in stream. You need to notify subscribers, you need to produce automatic captions and you need to produce thumbnails. And that is again, just the happy path. Right. So, what about all these other features? It's. For example, YouTube premiere is a scheduled release of a YouTube video or feeding into the recommendation algorithm. That must be the most craziest batch job in the world. And you need to scale this process, whatever, whatever you design for 30,000 hours of video uploaded every hour. That's the sheer amount of volume that's going on YouTube today, which is just insane. Like, like any design that you make at scale is going to break in some respect. So I think, I think that's, that's really interesting to consider. And I learned about this actually, and I thought more about this because I interviewed one of our users who is Descript (hi! I'm editing this transcript in Descript rn lol). Descript is a audio transcription platform and their entire business is transcribing audio and then making it easy for you to edit audio. I do it for my podcast every single day and millions of people use it. I think it's really cool.  So their problem was that when a user hits transcribe, it kicks off asynchronous multi-stage and parallelized process that involves reading, encoding audio, chunk splitting. external API calls, merging results that may potentially arrive out of order and then verifying their alignment. So there's a lot of [00:10:00] nuance here that can get really tricky. And if any part of the process fails, you need to try it again. So, this is typically the kind of architectures that people build up incrementally over time, as they discover all these use cases and then find holes and patch them because it's too late to rewrite something. There's a lot of decisions that goes into here. And this is normal. This is natural. I think you run into basically the eight fallacies of distributed computing, which has actually discussed or discovered back in 1994 by people at Sun Microsystems. I love these cartoons but it can be a little bit hard to read. So here's a more organized version of them. At the bare minimum, don't forget distributed computing fallacy number one, which is that the network may or may not be reliable or compute may or may not be reliable. So, what that means in practice is that when you're calling system a, B, C, D E F G you may actually need to introduce hardening layers because at every point and you cross system boundaries, you have a chance of failure and that multiplies exponentially, as you have more and more services tied up in your systems like we saw for the Uber example, like we saw for the YouTube example. You need to add in timeouts and retries. And what that means is that you need to persist the number of times you timed out, when you timed out, what jobs you timed up. So you need a database every single time, and then you need a scheduler or a timer to say when the next time is going out, I'm going to try this again. And you need to write this for every service. If the ma the maintainer for every service needs to maintain both the code and the infrastructure for this. This is a lot of how I was talking about things when I was exploring the serverless world. So here's a real life example from the AWS blog where they said that you were using dead letter queues to replay messages when such things as failures occur. This is a fine looking example until you try to scale it. And again it looks like a complete mess, complete track, and it's very hard to keep in your head, and pretty soon when you're explaining this to your CTO you look like the Pepe Silvia meme.  So the solution that I found is really to have a central orchestrator, right? Instead of every single system maintainer writing their own API hardening layer, which is a production requirements, as you find more and more of these bugs, you should centralize it with a centralized team that takes care of the orchestration of all these different services. And that's in the business, what we call choreography, which is A to B to C versus orchestration, which is a central orchestrator coordinating the dance between AB and C, and then storing both the infrastructure and the code for the scheduler and the database. So there's a really good article on this by Yan Cui in the burningmonk.com so I highly recommend checking it out where he talks about choreography versus orchestration, with real life examples that people use in AWS, but also it's not specific to any cloud. It's a architecture design pattern, which I think fundamentally, if you start off with this, it's really hard to rearchitect to this. I mean, it's, it's possible because people are doing it, but also it's a conscious, architectural choice that you might not know that you're making if you don't know about it. So, I guess a lot of my message here is to tell you that orchestration is a thing.  [00:13:05] Retries and Timeouts  Also, so you want to declaratively put into your framework retries and timeouts, so for example, this is actually our API. You want to be able to say, all right, here's the default retry policy. Whenever I fire off an activity, an activity is just like an external API call, for example. So when I fire up an activity, I want it to be retried every second. If it fails, I need a backoff coefficient, like exponential backoff. This is very similar to the TCP protocol so that if the endpoint is failing or getting rate limited, I don't keep retrying, and then building up a DDoS attack on myself, I actually back off and put more and more intervals in between until some maximum interval, let's say a hundred seconds. And then I give myself a maximum attempt, so I can say like, all right. I don't want any retries. I can just say have a maximum attempt of one. Or let's say, I want a linear back off and not an exponential for whatever reason. And I want to try to a maximum of five times - you want to have this all declarative so that you can tweak this as you understand your system and you scale your system. Right? So I think this is a really interesting programming model that just puts retries into the code that you write. And that's only possible when you have your centralized orchestrator, no matter what system, not just Temporal.  Okay. So the case that I'm making is really for choreography versus orchestration. And I, the analogy that I make for front end versus the back end is that it's kind of like vanilla or jQuery versus react. React has a react as the central orchestrator, orchestrating all the components. And I think that's a really interesting architectural analogy that you can make and learn from React. All right.  [00:14:37] Part 3 - Time  Part three - Time. I'm doing very good on time. I think better than I thought, which means that we'll have time for a live demo, which is really awesome. So let's talk a little bit about Temporal.  [00:14:45] What is Temporal?  What is Temporal? Temporal is the open source platform for orchestrating highly reliable mission-critical applications at scale. I love talking a little bit about the history, the reason because our CEO started at Amazon as the tech lead for what became Amazon SQS. Our [00:15:00] CTO was at Microsoft and it was the principal architect of the Durable Task Framework, which became a Microsoft's version of Durable Functions, and then finally they joined Uber and worked on Cadence, which is the open-source version of their workflow orchestration platform and Cadence became so popular that they spun out and became Temporal. And since then it's been adopted by a lot of well-known household name companies, especially in the developer world. There are a lot of people hiring for Temporal developers, which I really like to see because it's not just being used, but also it's creating jobs for people and it's becoming a desirable skillset. And most recently last week we had Netflix presenting about how they used Temporal for their CI/CD.  Temporal has three components or produces three products that are used in sync. The main star is Temporal server, which is comparable to the React runtime that you might see, then there's Devtools, which is the UI that you might want to inspect the state of things. And then the SDK is, which is what you use to code. So I think all those are really comparable to what we have in React and having been in the React world for while, like, it's really amazing to see the analogies that we have. We have exactly the same thing. For me, the really sort of the seal of approval comes from Mitchell Hashimoto who, created Hashi Corp, saying that without Temporal, we would have spent a significant amount of time rebuilding Temporal, which actually to me is the best form of validation because Mitchell is one of the best developers in distributed systems and he says it's hard and he says it does it well.   All right. Enough social proof you want actual facts? I would just give it straight to you.  [00:16:34] Elevator Pitch  So because your workloads like the YouTube encoding, or like the Uber journey and this technology was developed at Uber i s long running and it ties together multiple services. You want to standardize timeouts and retries and you want to make it easy for every team to have production grade retries and timeouts.  Because this work is so important. You must never drop any work. You must log all progress. In other words, you must use event sourcing. And then finally, because this work is so complex, you want to use generic programming languages, instead of Domain specific languages. So you want to model a dynamic, asynchronous logic, and then you want to reuse, test, version and migrated it.  So that's the pitch in one screen. But I'll just break it down for what it means, and then we'll go into a demo.  [00:17:13] Programming Model  So to me, The, the closest analogy to React is the programming model, because React spends a lot of time on API design and in the workflow orchestration world there are a lot of JSON or DAG based domain specific languages. So you, you write a bunch of JSON or you do boxes and arrows boxes and arrows boxes and arrows, sometimes you've even write XML, which is very interesting as well. What I find with all these is that they're actually really good for manipulating visually. But they get very tricky when you need to do programming language constructs, like variables, functions, loops, branching statements and all the things that we've invented in programming languages over the past few years. So if you use "just JavaScript" or "just programming languages", you have all the tooling available. You can use all the libraries that are available. You can use all the testing and code version, quality controls available. If you write your own, you have to rebuild all this dev tooling from scratch for yourself. So that's essentially what this is. Here's an example from one of the big clouds where this is their workflow orchestrator model, where you write Jason and it's really hard. It actually goes off the screen and I couldn't really fit everything on one screen. And with Temporal literal just JavaScript you call an endpoint you use that the result of that end point to call other end points, for example. It's a very simple example, but in built here is default retry policies that have been worked out. So both of these handle reliability on rails, it's just, we differ in the programming model and the engineering that it takes to maintain one of these SDKs is I'm learning. It's very, very immense. So it's really interesting. [00:18:44] Comparing React and Temporal Principles  So, again, back to the core principles that we talked about early on from React. React d ecided on using a framework, decided on correctness and decided on a programming model, and Temporal, in a very similar way. The developer writes workflows and the Temporal core team writes the orchestrator, which is Temporal server. In terms of correctness, React insists on functional programming, Temporal insists on event sourcing in deterministic workflows and then programming model, you want "just JavaScript" or just programming languages, not any custom DSL syntax.  [00:19:11] Live Demo: Amazon One Click Button  So the final example that I'm gonna motivate is which is like, I'm, I've been trying to re progressively reduce the complexity of my examples. So we met from Uber, which is like a super long running, a lot of humans in the loop to YouTube, which is not so much humans in the loop. You upload it once and then everything else takes over from there.  Now I just want to build one feature, which is a one-click buy button in React or in front end. It's actually super easy. It's a button. That's the literal simplest thing you can possibly do. You put an onclick handler. You're done. If you want to do a one-click buy, you do a setTimeout, and then say like, okay, if you want to cancel this within some window, with Amazon is 30 minutes, we can cancel it. But if you want to persist it, imagine if some person clicks, closes the browser and then changes their mind, opens the browser again, and it's gone. You're screwed. You don't have any other way to implement one-click [00:20:00] purchases. You need to implement timers on the backend to do this. I was watching this old talk from Joel Spolsky where he talks about the engineering for the one-click buy button. And I put it up on my YouTube because this is such an old talk. And I was afraid to link to the timestamp, but you can check it out as it's just a three minute video where he tells the story about how Amazon moved from shopping cart to one-click buy I mean they still have a shopping cart but it's that important because in online e-commerce actually even up to today the abandonment rate for shopping carts is 70%. So imagine if you implement this one feature, you improve your sales by I don't what's the inverse of 70%, three times. That's really amazing. So I think it's just fascinating and it's not just about Amazon. It's not about one click buy. It's about user experience. It's about making things easy and intuitive and that often involves turning synchronous things into asynchronous things and in persisting them so that they persist in the background. So I have a little demo here. I'm going to go really, really fast, but you can check out the code in temporalio/samples-node.  There's the specific path this year but it's basically a Next.js demo where I have a Next.js folder here. This is going to be pretty standard for a lot of React developers. Hopefully you're familiar with Next.js, so you can learn it. It's got some pages and an API routes where I have serverless functions that call and send signals to my workflow functions. I have also a Temporal folder where I have written my workflows and activities. The activities are just a little logs obviously, cause they don't interact with any backends, but they could. And then the workflow coordinates the states in the background of all of these.  So I can show you the code, but essentially I kick off a one-click buy with a purchase and then I set a timer and promise.race with a five second wait. So if I receive a cancel signal during that timer then that cancels if not, it goes through and the purchase is confirmed. Obviously I can. And what's fascinating about Temporal is that every single step is persisted in automatically saved. So in other words, I can sleep for 30 days. I can sleep for a year. I can sleep for five years and it doesn't matter because it's all persisted and wakes up automatically. So the compute the, this serverless function can be. The worker or a Temporal server itself can go down. You can just bring you back up again and it carries on as though nothing happened because of event sourcing. So, I'm gonna, I'm going to go ahead and run this. I think it's uh, demos I'm always stressed out about live demos. Okay. I mean, I did test it before the talk. It's just that whenever I'm streaming, like it adds an extra latency thing and that goes haywire. So, Let's see if I have this demo available. All right. So I also want to pull this out, which is the UI layer. These are the my test runs. But I have here at one-click purchase UI, and literally, I, you know, I, I want to implement this without a shopping cart, but I want to be able to cancel within some certain amount of time. So if I click buy, uh, it clicks, it handles it's. It sends a workflow. And that workflow starts in starts in the background and it's running, right. It's waiting for the timer to proceed. So I'm going to hit the timer, uh, and you can see that a timer started and time of ended, uh, within that five second window that I specified, obviously I should make it longer if I, if I really wanted to show this along the way. Um, so, uh, this, this is, this is as is purchased, um, and we can, uh, and now we've confirmed it. Um, but if I ever want to click buy, and then I can click the. That also fires off a different workflow, uh, where it sees that it receives the cancel signal from me. Uh, so, so I signaled it to cancel. And that's a very useful model as well. So this actually shows off a lot of the core principles of Temporal, which is you kick off a workflow, you can set durable timers, you can send it human signals and you can get out data as well with queries. There's a lot of interesting elements behind that, but that's the core demo that I wanted to show off. So maybe I'll write a YouTube example and then I'll go on to an Uber example and be a billionaire.  [00:23:49] Talk Recap  So ultimately I just want it to recap again, what we covered. We covered components, we covered architecture we covered time, and these are all the three elements I wanted to compare reacts and Temporal, and explain a little bit of how we think about doing the hard parts of making clones of very popular projects. Why is it so interesting? It's a little bit like the crabs story, you know. Obviously the founders of Temporal are not front end developers. They didn't even know react at all.  [00:24:16] React and Temporal Full Comparison  But they independently evolved a lot of the same principles and this that's, I haven't even gone into like the full comparison. So we talked a little bit about deterministic functions and local state and composition, but we haven't talked about normalization and how that compares dev tools. Testing is also super interesting thing as well as the central runtime. So there's a lot here, which I think. And fascinated by, and I'm obsessed by applying the lessons from React to things that are not React. [00:24:42] Conclusion: Enablement And I think overall, when I asked my CEO, like, what is the core message that we want to deliver is actually about enablements. Like we enable people to do things that they're not formally trained to do because we wrapped it up rapid all in a central runtime or central framework. So, uh, I always loved the Alfred north Whitehead quote that [00:25:00] civilization advances by extending the numberof things that we can do without thinking about it.   So for me, my version of it is that B2B software advances by extending the number of jobs we can perform without formal training. And the message overall here is that Temporal lets backend developers or, just general full stack developers do distributed systems right? So that's it.  I blasted through that. I only took 26 minutes. Really great for me, cause I was worried that it would take 50 and I'm happy to answer any questions you can hit me up on Twitter at Swyx. You can read my long form blog posts about why Temporal and then you can join our mailing list, YouTube or Slack. Thank you. Alright, thank you very much things. So I think that was a really, really nice. And you did, uh, went through that quite quickly. Uh, when I see the comments, people love the, like the most right there, because I could fail because I could fail. It's always like that. So, uh, yeah. Um, the nice thank you for the presentation. With this talk, I think it's actually the last talk of the event and I want to thanks everyone for joining us and thanks to everyone, thanks to all the speakers, of course, for being part of this event, uh, React New York 2021 and the sponsors. Um, I think this would be a good afternoon, I guess, or good night, depending on where we are in the world. Right. Have a good one. Everyone. 

Every few months, I like to explore professions that are adjacent to programming. Today we're exploring captioning and its impact on our industry. Our guide for this industry is the fabulously giften Norma Miller of White Coat Captioning. I was captivated by her work at last year's React Rally and wanted to share with you what I learned from her. Her company does primarily technical events, which gives her an interesting vantage point into tech conference culture. We talk about typing in excess of 300 words a minute with 98% accuracy, The $6000 keyboards that make it little easier, And the open source that powers it. I think you love this chat, as we learn how captioners are making our technical events more multi-cultural, accessible, and inclusive.

Self-Follow-Up, React Rally, Apple Rumors, and lots of people to follow on Twitter!

This week we talk Jamison Dance about the parts of programming that are distinctly non-technical. We talk about the perfect TLD, working with a team, finding psychological safety, the organization of React Rally, and how to recycle batteries. Jamison is co-host of the podcast Soft Skills Engineering where he and Dave Smith answer non-technical questions for technical folks. It's a great show that I highly recommend. check it out at softskills.audio

Dave and Jamison host the Soft Skills Engineering podcast. Jamison talks about how he got into coding, and they talk about how they met and why they started the podcast, as well as the Dunning–Kruger effect, and React Rally.

Panel: Charles Max Wood Lucas Reis Justin Bennett (guest host) Special Guests: Gant Laborde In this episode, the panel talks with Gant who has been programming for twenty years. In the past, he has been an adjunct professor and loves to teach. Finally, he talks at conferences and enjoys sharing his ideas. The panel talks about the React State Museum, among many other topics, such as: React Native, Flux, Redux, Agile, and XState. Show Topics: 1:24 – Chuck: What do you do? 2:02 – Chuck and Gant: We met at React Rally at 2016. 2:17 – Gant: I have my own sticker branding with a friend in Japan who is genius. She draws all these characters. They are my business card now. 2:41 – Chuck: React State Museum- talk about its brief history and what it is? 2:54 – Gant: React is this beautiful thing of passing these functional capsules around and managing them. Once you start creating another component, the question is how do you actually manage all of these components? We are all so happy to be on the cutting edge, but state management systems come up and die so fast. For like Facebook, there are 2 people who understand Flux. What happens is Redux is the one thing that shows up and... 6:34 – Chuck: I want to say...I think we need to change the topic. You said that JavaScript USED to be bad at classes, but it’s still bad at classes! 6:52 – Gant: Yep. 7:21 – Chuck: Typescript gets us close-ish. 7:31 – Chuck: Do you get feedback on the library? 8:12 – Gant: The requests that I’ve got - it’s from people who are better at (that0 than me. I wanted to test the lines of code. But that’s unfair because there are a lot of things to do. It really was a plan but what happens is – components that are used in this example is that in this node module... 9:41 – Panel: This is an interesting topic. When you assess any technology...if you are not a technology expert than you really can’t say. That’s interesting that you are doing this an open-source way. 10:25 – Gant: I am a huge fan of this vs. that. I am okay with say “this” one wins and “that” one looses. I don’t declare a winner cause it’s more like a Rosetta Stone. I had to find pitfalls and I respect that for the different perspectives. At the end of the day I do have opinions. But there is no winner. They are all the same and they are all extremely different. Are you trying to teach someone in one day? I learned Redux in 2 different days. 12:00 – Panel: Is there a library that helps with X, Y, Z, etc. 12:16 – Gant: I love for teaching and giving people a great start. I just set state and live life. I had to show what X is like. 13:59 – Chuck: Like this conversation about frameworks and which framework to use. Everyone was using Redux, because it was more or less what we wanted it to do. But at the time it cleaned up a bunch of code. Now we have all these other options. We are figuring out... How to write JavaScript if web assembly really took off? Do I write React with X or with Y. And how does this affect all of this? We had all of these conversations but we haven’t settled on the absolute best way to do this. 15:50 – Panel: This is great, and I think this is from the community as a whole. 17:20 – Chuck: I need to ask a question. Is this because the requirements on the frontend has changed? Or... I think we are talking about these state management systems, and this is what Lucas is talking about. 17:45 – Gant: I think it’s both. 18:43 – Panel: Websites have gotten bigger. We have always been pushing CSS. Panelist mentions Facebook Blue, among other things. What does your state look like? What does your validation look like? We are on so many different devices, and so on. 20:00 – Gant: I agree to echo everything that you all have said. I think the expectations are tighter now; that we have less drift. People are being more cognoscente and asking what is our brand. And it’s about brand consistency. And we are expecting more out of our technology, too. We keep pushing the envelope. What about these features? We want to be feature rich, and pushing these envelopes – how can we build more faster with less complexity while building it. You have to put that complexity somewhere. It’s interesting to watch. 22:00 – Chuck: How do we use this React State Museum...where are we going next? 22:19 – Gant: It’s a loaded question. Being able to ID new and interesting concepts. If you had a terrible version and Redux comes along, Redux is great for some companies but not all. You won’t see bugs that are crazy, there is a middle-wear, and maybe for your team going into Redux will make things more manageable. 25:25 – Advertisement – Digital Ocean 26:05 – Panel: Understanding your problem is the first thing to do. Talking about evolutionary architecture – to build your software to evolve. What does tha fit really well? So if you have to pick something new you are in a good position. What are my needs? Don’t look too much forward or 27:38 – Chuck: Advice on looking at your problem-sets? 27:52 – Panel: We have gone from planning too much to not planning at all. I don’t need to plan for too much or else it will “hurt” me. 28:42 – Chuck comments and mentions Agile. 29:29 – Panel and Guest chime in. 29:39 – Panel: I worked on a project (3 months) we needed to do a big change. I asked them why didn’t we take that into consideration. And their answer was... 30:30 – Gant: You might get away with... 30:55 – Chuck: What are some of the knobs on this? If I turn this know Redux is looking good, but if I do this... 31:12 – Gant: There are a lot of attractive knobs. Using app sync, not using app sync. 32:33 – Gant: Is your app really effective? That’s your first important question. How much state do I need on the frontend. And vice versa. 34:02 – Gant: How easy will this be to test? Can I teach someone how to do this? If I cannot teach it then it won’t do my team any good. 34:35 – Panel adds in comments. 35:08 – Gant: Looking at tests. 37:25 – Panel: If you have a great backend team then you can move the work across the team. You have a strong team to move that work along that line – normally you can’t cross that sort of thing. 38:03 – Chuck: There are so many options, too. I see Apollo getting reach here. I don’t see it as a statement tool instead I see it as... 38:31 – Panel: Apollo State – seems like they are pushing the envelope. It’s interesting to watch. 38:54 – Chuck. 39:12 – Gant: I am going to go ahead and use this tool – I am not going to worry about it. But now you are being held accountable. 39:29 – Panel: Question for folks: React not having a blessed ecosystem can hold people back in some ways? You have the freedom to use what you want. Here are the tools that you can use. Do you tink it be better if the Facebook team could do... 40:20 – Gant: I find that I don’t like (being told) this is what you will be using. I am a person with idea. We’d all be using Flux and all be very upset. 41:00 –Then there would be 3 people who don’t understand it. 41:17 – Gant: I loved Google Wave. Fool on my once and shame on me twice... Google Video! Google comes out and says here is BLESSED and you don’t have any choice. But it’s any author for themselves. It’s a little bit silly 0 I would like a beacon from Facebook saying: Here is a guide. It seems that they can’t focus. They are running a large company; I would like to keep it open – friendly energy. 42:24 – Chuck: I am mixed feelings about this. It only plays as far as people play into it. IN a React community there are so many voices. They all have opinions on what you should/shouldn’t use. The one thing that I like about a blessed / recommended stack – brand new person – it’s a good place to art. After that if they realize that Flux is hard then they can go and try other options. There are other things out there; there is a good balance there. 43:36 – Panel: That is the Angular way right? 43:38 – Chuck: Yes but Angular is more opinionated. It’s a different feel. 44:38 - Panel + Guest continue this conversation. 45:00 – The book DRIVE is mentioned. 45:21 – Gant: ... we need more recommendations. 45:43 – Chuck: Let’s talk about Repot and how to use this? If you go and get Repot – Google React State Museum it’s really easy. How should people come to this and pick it up? 46:18 – Gant: The table that comes in there – it links to the main Repot. A lot of people showed up and contributed. First of all show up. Gant mentions a sandbox link – and he talks about getting your hands dirty. React Native is mentioned, too. 48:10 – Gant: There are many opportunities for contributors. I could use my links. Typos, documentations, etc. - anything friendly is accepted here. 49:20 – Gant continues this conversation. 50:33 – Chuck: Anything else to dive into? 50:41 – Panel: I think there could be other things you can bubble up 51:26 – Gant: I would love some help with that. I did have some contributors write some tests. I wrote a test – 4 hours later – and it tells me if it passed or not. It has to go into a new directory, and work in Android, etc. It’s insane testing library. Then there are some checks to see if there is a link in the README. Animation if there is anyone who wants to do some cool stuff – like modules. Maybe it’s apple to oranges comparisons there. I would like to identify that for people. We would like some outside feedback out there. The more the merrier to help with the data is out there. Sanity check complete – yes! 53:24 – How to do that? 53:31 – File a ticket to help contribute. So you can say: I will do this. If you do it in a reasonable amount of time, then heck yes. If you do some open source...Do 10 (I think) and you get a free t-shirt? 54:28 – Advertisement. Links: Kendo UI Ruby on Rails Angular Get A Coder Job Redux Agile A Philosophy of Software Design – book XState Book: Spellmonger Did Someone Steal the Declaration of Independence Again? Book: The Culture Code Gant Laborde’s Twitter Lucas Reis’ Email: lucasmreis@gmail.com Charles Max Wood’s Twitter Sponsors: Kendo UI Digital Ocean Get A Coder Job Picks: Charles My journey – it’s been a rough year – with my dad passing. Willing to think it and process it, and it’s a healthy thing. Book: The Traveler’s Gift by Andy Andrews Book: The Shack by William Paul Young Gant Book: Harry Potter - Methods of Rationality Magicians XState is amazing! Culture Code - especially if you work remote. The pains that can happen by working remotely. Helps you identify those issues. Talk in Poland – Secret project. Lose the Declaration of Independence. “Where’s Waldo?” I am going to find Nicholas Cage in the audience and he will have the Declaration of Independence in backpack. Fake government website. Justin XState – Not Reactive specific Spellmonger: Book One of the... by Terry Mancour Book: Building Evolutionary Architectures Lucas Book: A Philosophy of Software Design by John Ousterhout

Panel: Charles Max Wood Lucas Reis Justin Bennett (guest host) Special Guests: Gant Laborde In this episode, the panel talks with Gant who has been programming for twenty years. In the past, he has been an adjunct professor and loves to teach. Finally, he talks at conferences and enjoys sharing his ideas. The panel talks about the React State Museum, among many other topics, such as: React Native, Flux, Redux, Agile, and XState. Show Topics: 1:24 – Chuck: What do you do? 2:02 – Chuck and Gant: We met at React Rally at 2016. 2:17 – Gant: I have my own sticker branding with a friend in Japan who is genius. She draws all these characters. They are my business card now. 2:41 – Chuck: React State Museum- talk about its brief history and what it is? 2:54 – Gant: React is this beautiful thing of passing these functional capsules around and managing them. Once you start creating another component, the question is how do you actually manage all of these components? We are all so happy to be on the cutting edge, but state management systems come up and die so fast. For like Facebook, there are 2 people who understand Flux. What happens is Redux is the one thing that shows up and... 6:34 – Chuck: I want to say...I think we need to change the topic. You said that JavaScript USED to be bad at classes, but it’s still bad at classes! 6:52 – Gant: Yep. 7:21 – Chuck: Typescript gets us close-ish. 7:31 – Chuck: Do you get feedback on the library? 8:12 – Gant: The requests that I’ve got - it’s from people who are better at (that0 than me. I wanted to test the lines of code. But that’s unfair because there are a lot of things to do. It really was a plan but what happens is – components that are used in this example is that in this node module... 9:41 – Panel: This is an interesting topic. When you assess any technology...if you are not a technology expert than you really can’t say. That’s interesting that you are doing this an open-source way. 10:25 – Gant: I am a huge fan of this vs. that. I am okay with say “this” one wins and “that” one looses. I don’t declare a winner cause it’s more like a Rosetta Stone. I had to find pitfalls and I respect that for the different perspectives. At the end of the day I do have opinions. But there is no winner. They are all the same and they are all extremely different. Are you trying to teach someone in one day? I learned Redux in 2 different days. 12:00 – Panel: Is there a library that helps with X, Y, Z, etc. 12:16 – Gant: I love for teaching and giving people a great start. I just set state and live life. I had to show what X is like. 13:59 – Chuck: Like this conversation about frameworks and which framework to use. Everyone was using Redux, because it was more or less what we wanted it to do. But at the time it cleaned up a bunch of code. Now we have all these other options. We are figuring out... How to write JavaScript if web assembly really took off? Do I write React with X or with Y. And how does this affect all of this? We had all of these conversations but we haven’t settled on the absolute best way to do this. 15:50 – Panel: This is great, and I think this is from the community as a whole. 17:20 – Chuck: I need to ask a question. Is this because the requirements on the frontend has changed? Or... I think we are talking about these state management systems, and this is what Lucas is talking about. 17:45 – Gant: I think it’s both. 18:43 – Panel: Websites have gotten bigger. We have always been pushing CSS. Panelist mentions Facebook Blue, among other things. What does your state look like? What does your validation look like? We are on so many different devices, and so on. 20:00 – Gant: I agree to echo everything that you all have said. I think the expectations are tighter now; that we have less drift. People are being more cognoscente and asking what is our brand. And it’s about brand consistency. And we are expecting more out of our technology, too. We keep pushing the envelope. What about these features? We want to be feature rich, and pushing these envelopes – how can we build more faster with less complexity while building it. You have to put that complexity somewhere. It’s interesting to watch. 22:00 – Chuck: How do we use this React State Museum...where are we going next? 22:19 – Gant: It’s a loaded question. Being able to ID new and interesting concepts. If you had a terrible version and Redux comes along, Redux is great for some companies but not all. You won’t see bugs that are crazy, there is a middle-wear, and maybe for your team going into Redux will make things more manageable. 25:25 – Advertisement – Digital Ocean 26:05 – Panel: Understanding your problem is the first thing to do. Talking about evolutionary architecture – to build your software to evolve. What does tha fit really well? So if you have to pick something new you are in a good position. What are my needs? Don’t look too much forward or 27:38 – Chuck: Advice on looking at your problem-sets? 27:52 – Panel: We have gone from planning too much to not planning at all. I don’t need to plan for too much or else it will “hurt” me. 28:42 – Chuck comments and mentions Agile. 29:29 – Panel and Guest chime in. 29:39 – Panel: I worked on a project (3 months) we needed to do a big change. I asked them why didn’t we take that into consideration. And their answer was... 30:30 – Gant: You might get away with... 30:55 – Chuck: What are some of the knobs on this? If I turn this know Redux is looking good, but if I do this... 31:12 – Gant: There are a lot of attractive knobs. Using app sync, not using app sync. 32:33 – Gant: Is your app really effective? That’s your first important question. How much state do I need on the frontend. And vice versa. 34:02 – Gant: How easy will this be to test? Can I teach someone how to do this? If I cannot teach it then it won’t do my team any good. 34:35 – Panel adds in comments. 35:08 – Gant: Looking at tests. 37:25 – Panel: If you have a great backend team then you can move the work across the team. You have a strong team to move that work along that line – normally you can’t cross that sort of thing. 38:03 – Chuck: There are so many options, too. I see Apollo getting reach here. I don’t see it as a statement tool instead I see it as... 38:31 – Panel: Apollo State – seems like they are pushing the envelope. It’s interesting to watch. 38:54 – Chuck. 39:12 – Gant: I am going to go ahead and use this tool – I am not going to worry about it. But now you are being held accountable. 39:29 – Panel: Question for folks: React not having a blessed ecosystem can hold people back in some ways? You have the freedom to use what you want. Here are the tools that you can use. Do you tink it be better if the Facebook team could do... 40:20 – Gant: I find that I don’t like (being told) this is what you will be using. I am a person with idea. We’d all be using Flux and all be very upset. 41:00 –Then there would be 3 people who don’t understand it. 41:17 – Gant: I loved Google Wave. Fool on my once and shame on me twice... Google Video! Google comes out and says here is BLESSED and you don’t have any choice. But it’s any author for themselves. It’s a little bit silly 0 I would like a beacon from Facebook saying: Here is a guide. It seems that they can’t focus. They are running a large company; I would like to keep it open – friendly energy. 42:24 – Chuck: I am mixed feelings about this. It only plays as far as people play into it. IN a React community there are so many voices. They all have opinions on what you should/shouldn’t use. The one thing that I like about a blessed / recommended stack – brand new person – it’s a good place to art. After that if they realize that Flux is hard then they can go and try other options. There are other things out there; there is a good balance there. 43:36 – Panel: That is the Angular way right? 43:38 – Chuck: Yes but Angular is more opinionated. It’s a different feel. 44:38 - Panel + Guest continue this conversation. 45:00 – The book DRIVE is mentioned. 45:21 – Gant: ... we need more recommendations. 45:43 – Chuck: Let’s talk about Repot and how to use this? If you go and get Repot – Google React State Museum it’s really easy. How should people come to this and pick it up? 46:18 – Gant: The table that comes in there – it links to the main Repot. A lot of people showed up and contributed. First of all show up. Gant mentions a sandbox link – and he talks about getting your hands dirty. React Native is mentioned, too. 48:10 – Gant: There are many opportunities for contributors. I could use my links. Typos, documentations, etc. - anything friendly is accepted here. 49:20 – Gant continues this conversation. 50:33 – Chuck: Anything else to dive into? 50:41 – Panel: I think there could be other things you can bubble up 51:26 – Gant: I would love some help with that. I did have some contributors write some tests. I wrote a test – 4 hours later – and it tells me if it passed or not. It has to go into a new directory, and work in Android, etc. It’s insane testing library. Then there are some checks to see if there is a link in the README. Animation if there is anyone who wants to do some cool stuff – like modules. Maybe it’s apple to oranges comparisons there. I would like to identify that for people. We would like some outside feedback out there. The more the merrier to help with the data is out there. Sanity check complete – yes! 53:24 – How to do that? 53:31 – File a ticket to help contribute. So you can say: I will do this. If you do it in a reasonable amount of time, then heck yes. If you do some open source...Do 10 (I think) and you get a free t-shirt? 54:28 – Advertisement. Links: Kendo UI Ruby on Rails Angular Get A Coder Job Redux Agile A Philosophy of Software Design – book XState Book: Spellmonger Did Someone Steal the Declaration of Independence Again? Book: The Culture Code Gant Laborde’s Twitter Lucas Reis’ Email: lucasmreis@gmail.com Charles Max Wood’s Twitter Sponsors: Kendo UI Digital Ocean Get A Coder Job Picks: Charles My journey – it’s been a rough year – with my dad passing. Willing to think it and process it, and it’s a healthy thing. Book: The Traveler’s Gift by Andy Andrews Book: The Shack by William Paul Young Gant Book: Harry Potter - Methods of Rationality Magicians XState is amazing! Culture Code - especially if you work remote. The pains that can happen by working remotely. Helps you identify those issues. Talk in Poland – Secret project. Lose the Declaration of Independence. “Where’s Waldo?” I am going to find Nicholas Cage in the audience and he will have the Declaration of Independence in backpack. Fake government website. Justin XState – Not Reactive specific Spellmonger: Book One of the... by Terry Mancour Book: Building Evolutionary Architectures Lucas Book: A Philosophy of Software Design by John Ousterhout

Chantastic talks with Kent C Dodds about his adventures in React development and why we should be optimizing code for delete-ability. They discuss React Rally, managing your career, taming your ego, keeping healthy and happy on Twitter, tools for composing components well and when to use them, and what’s next for React.

Chantastic talks with Devon about her adventures in web development and why she organizes the ReactJS San Francisco Bay Area meetup. They discuss how to foster vibrant and inclusive communities, why React Rally is so special, and what it means that Apple is sponsoring a React conference.

Guest: Saron Yitbarek: @saronyitbarek | bloggytoons | CodeNewbie | @CodeNewbies In this episode, Charles and Sam talk to Saron Yitbarek about her idea of mentorship, ideas for distributed learning for businesses to promote individual and company growth, and why it's important to take "digital sabbaths" on the regular. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: SAM: Hey, everyone. Welcome to Episode 110 of The Frontside Podcast. My name is Sam Keathley. I'm a developer here at the Frontside and I will be your episode host. Today, we're here with Saron Yitbarek, discussing mentoring. She is the founder of CodeNewbie and the host of the CodeNewbie Podcast. Also with me as a co-host is Charles Lowell, who is also a developer at Frontside. Welcome Saron and welcome Charles. How are you guys doing? SARON: Thanks for having me. I'm doing pretty well. CHARLES: Hello. SAM: Today is going to be an interesting take on the mentoring talk. I mostly want to know first off, Saron, how do you feel about mentoring? What are your opinions on the mentor-mentee relationship or the value there? SARON: Yeah. I have lots of opinions on this topic. I think that the traditional structure of mentorship was usually looks like someone with less experience going to someone who has a lot more experience and say, "Will you be my mentor?" kind of like the children's book, 'Are You My Mother?' like 'Are you my mentor?' and then that person, that mother figure, that mentor looks after them and checks in on them and they have regular coffees and lunches and kind of steers them in the right, usually career-related direction. I don't think that's very realistic, to be honest. I think about why that might be. There's many different reasons. I think the fact that we're so, so, so networked and there's just so many different ways to get in contact with people and build relationships is a big reason but I think that that traditional mentorship model, that kind of one directional way of doing things is just not really needed and kind of overrated. I think that mentorship nowadays looks more like a mutually beneficial relationship, where I might reach out to someone who has more experience than me, for example in drawing, in art, not something I want to get to do but I know a crap-ton about podcasting, so I help you, you're my mentor in this specific area, in this specific topic but then, I get to be a mentor in this other thing that I'm really good at. I think it's those types of very focused topic-oriented, ideally two-way relationships that are more accurate and frankly, a more effective way of doing mentorship. SAM: Yeah, I actually agree with that. I am pretty new myself to development, only really been in this career for about a year now and I always kind of consider that mentoring relationship as a regression back to school days, where you have these -- SARON: Yeah, yeah. SAM: -- considered superior over you in some way, well, that's really not true in this community of developers and no matter where you are in development, it's all about working together and pairing. Working here has really showed me that value in paring, rather than like I have to look up to someone and regress back to feeling like a teenager in high school, like this person so good at this thing and they're the only one who can teach me. I definitely share that view of mentoring. I went to a boot camp one day when they were telling you like, "Oh, you got to find a mentor. You got to find a mentor," and I was like, "Well, but why? Why do [inaudible] together?" SARON: It's also a huge responsibility, a huge burden on the mentor too. Having to be, in a lot of ways, responsible for someone's career and trajectory and direction, that's a big responsibility. We don't have time for that, you know? On both ends, whether it's feeling like you're back in school or feeling like you have this huge responsibility, I think the traditional model isn't really the best model for either party. I think this idea of let's all learn together, let's be really focused on topics and problems that are very particular to what I'm doing, what I'm learning, what I'm trying to do. I think that works out. It feels healthier for both people. SAM: Absolutely. CHARLES: I wonder also too, it seems like it might be a little bit of a throwback to the days when people would spend 30 years in a single company or 30, 35 years in a single career where you have these people who are really these reservoirs of this intense tribal knowledge. It seems like people move around a lot more in their careers, not only in the company that they work for but also in the things that they're literally doing. I might be podcasting one day and producing a bunch of content and then, I might move into music or writing or other things like that. The careers seem to be broken apart a little bit more is one of the reasons why older models of advancement in those careers might not be as good a fit as they once were. SARON: Yes, absolutely. I'm obviously very biased because I'm in tech but when you think about the different roles that people have in tech, I feel like we're always wearing so many different hats. We have to, obviously code and be technical in that sense but we have to be really good communicators, a lot of us are speakers, we host podcasts, we organize conferences, we go to meetups, we're bloggers, we do so many other things, that this idea of, "I'm going to have a mentor who can help me in my role of being a developer," is just too big. You kind of meet people who are good at those individual pieces and those individual skills to get me to where I want to go. SAM: The whole idea of mentoring to me always reminded me of that whole Mr Miyagi relationship where you have this master of something and you're trying to learn from them. But in software development, I've learned that really no one is a master of anything because it's just changing so much and everything is so different. SARON: Yup, absolutely. CHARLES: The question is obviously, it seems like the idea that you're going to find one person who's going to represent the ideal confluence of every single skill set that you could hope to want, to be at some point in your career. That's looking more and more ludicrous. Is there a model where you can try and distribute those things, where you single out a large range of individuals? I guess the kind of what you were hinting at the beginning is that it is a lot more broken up, a lot more distributed but how do you pursue that, even if it is in a distributed manner? SARON: Yeah, that's a great question. One of the moments where I realize that the distributed model is really the only way that makes sense is, I think it was three years ago maybe. We thought about doing some kind of mentorship program in CodeNewbies, some type of way for people to link up and find people who can be there and guide in a way and we had people fill out this survey that basically said what do you want out of a mentor, what do you look for, what do you hope for to achieve but also asked how do you see yourself. Do you see yourself as a mentor, a mentee or both? It was really surprising that most people checked off both, which I thought was so interesting. It was so interesting to me that the same people who said, "I need help," with the same people who also said, "I also have help to give," and to me, that was such an amazing moment because I said, "Wow, it really isn't about this idea of I am the guide and I'm going to guide you." It's really about, "I have information expertise in one area and not in others." What I realize is there really isn't a mentor model. I think it's more of a culture of being helpful, which probably sounds really cheesy but it's true. I really think it's about saying, "I know how to do a thing. I'm going to go on Stack Overflow and answer questions. I'm going to go on Twitter and answer questions. I'm going to write blog post and share with the world." I think the real model, the real distributed mentoring model is us as individuals saying, "I just learned how to do a thing," or, "I just figured out how to do a thing well. Let me capture that. Let me capture it in a response, in an answer, in a forum, in a post and let me share that," and the more we do that as individuals, the more we have this huge amazing aggregate of knowledge that can serve as mentorship for all of us. SAM: I like the touch on that. That's kind of the idea behind Codeland Conference, where everybody thought they might be new to development and everyone is just sharing their knowledge. You might feel you really knew about it but you know a lot more than you think you do and you could still help. SARON: Yup, exactly and that's the whole idea, even the Twitter chats. When we first started, I don't have all the answers, I don't claim to, I don't really want that responsibility but I know there are a lot of people who do and I know a lot of people who have resources and opinions and who can help out. One thing that people do is they'll DM us and say, "I'm having a hard time with this." Sometimes, it's a very technical problems. Sometimes, it's a general 'I'm having a hard time getting a job,' which I do like high level question and I never answer them. I always say, "Tweet us and we'll retweet it and we'll get the whole community involved and we can have a rich conversation around it," and that's really been our motto, our philosophy. I see what they do with mentorship. If you have a mentor, you're not obligated, I guess to listen to them but the idea is kind of that you should. There is one person and you should listen to them because they know more than you. I think that's just not really fair and instead, I like to think that there are lots of different ways to do things and it's up to you to decide what's best for you and in order for you to decide, you have to have a lot of options. With Codeland, with the Twitter chats, no matter what skill level you're at, no matter how confident you feel in your coding abilities, you do have something to offer. Let's pull that out. Let's put it on the table and let's see who you can help today. SAM: That's a perfect way of introducing someone to the idea of helping or getting help from a community, rather than an individual because you never want to take one person's word as gospel on something you just know nothing about. SARON: Yeah, exactly. SAM: You can sound confident talking about something and it can be the total wrong answer but if you're seen as someone superior or someone who knows what they're doing -- SARON: And you can sell it. SAM: Yeah. You can be the best snake oil salesman in the world. SARON: Absolutely. For the CodeNewbie podcast, we do short questions at the end of each episode and one of the questions -- my favorite question -- is what's the worst advice you've ever received. I love that question because I started by saying, I think that people love giving advice. I think people love asking for advice and the assumption again is if I give you advice, then I probably know more and you should probably listen to me but that's not always true. I want people to be comfortable making their own decisions and deciding for themselves. "This may sound like it could work and this may sound like a good idea, generally speaking, but for me, it's probably not a good fit. It's probably not what's best for me," and to be comfortable rejecting advice and that was kind of the reason why I started that question, it's my favorite question and it's so interesting how much advice is good. It's kind of generic but it's a good advice. It's an advice like, "Don't quit. Keep going," which maybe a good idea and maybe you do need to quit, so being open to rejecting advice, I think is really important and that one of my favorite questions. SAM: In your experience, what is the best way to reject advice? Because when you're a new developer, when you're new at anything and you're seeking advice from a community or from a person, you don't want to come off as rude or maybe you're feeling... I don't know, not very confident but you think the advice that you were given is just bad advice. What would your advice be? I guess, what would your advice be on this advice? For your perspective, what would be a good advice to reject advice that you think is just wrong? SARON: Number one is when I ask people for advice, I try to think about and try to know upfront, do they have the same values that I do? Do they have the same worldview? Do they have the same goals? Because that's the thing too. Oh, my God, I got so much unsolicited advice. It's amazing. I've actually stopped just saying to people my ideas or what's on my mind because I know as soon as I say, "I'm thinking about this," I'll get a whole slew of unsolicited advice and I'm like, "I didn't ask for that." What I've learned is first to kind of figure out are we even on the same page because if my goal is to be a developer, if your goal is to be -- the only thing I could think of is a juggler, I don't know why -- a juggler and I ask you for a career advice, I'm going to go ahead and safely assume that what you have to say is probably not as applicable to me and so, number one is kind of identifying that. But number two is if they say something that just I know is not going to work or I've already tried, I'll just nod and say, "Thank you very much," and kind of go about my day. I don't think you have to declare whether or not you going to take it. I think just acknowledging and I think the people that give advice, I think they're trying to be helpful, they have good intentions, usually. Usually it's, "I'm trying to save you from making mistakes that I made and I'm trying to help you get to learn a little faster." I always appreciate it but knowing that I can say, "Thank you. Thank you for your time. Thank you for your perspective," but know that I don't have to go off [inaudible]. SAM: That's actually very similar to my tactic. Just not like, "Thank you. Thank you so much. Don't talk to me ever again." No. SARON: And disappear, yeah. SAM: I'm like the wind. With this pressure that either new developers or seasoned veterans are feeling about the mentor relationship, because I feel like a lot of senior developers that I've spoken with or people who've been in the business for a long time, feel like they should be mentoring or they need to take on that responsibility but there's always that hint of dread in their voice when they say about like, "Oh, I should be doing this." I always feel like it's okay to not do that. I never really understood why it was so high value to have this one-on-one relationship with an individual when you're not in school because it just feels so like... Not childish but childish. SARON: Yeah, that's one of things, frankly that I love about the tech community and also do not understand about the tech community. It's such a giving knowledge sharing community, whether you do it in a tactful way or not in a tactful way but the idea of giving back and paying it forward is just so deep. It's so, so deep that even when I've been coding for only a couple of months, I still felt this, I don't want to call pressure because pressure kind of sounds a little negative but I definitely felt this expectation that I was supposed to be blogging, supposed to be sharing and shouting and helping and doing these pay it forward type things. I don't really know where that comes from. Maybe that comes from the culture of open source, maybe that's where it kind of penetrate. I'm not sure but there's this huge need, desire, idea that we're supposed to be giving back and for that, I am very, very, very grateful. But I think that acknowledging that if you're someone who wants to be a mentor that you can do it simply by being available, literally being available, the going to be hashtag is super, super active even when we're not doing our Twitter chats and people use it to ask for help, they used it to ask questions. If you're feeling particularly giving or extra helpful that day, go on Twitter and check the hashtag and see what questions people are asking. Things like that or just super helpful and don't require a huge amount of time and effort. There's a lot of small ways to help out. That may not seem like a big deal to you but for the person who's asking for help, who has been banging their head against the wall, it's hugely valuable. SAM: Yeah, absolutely. Up until I went to my first conference this year, I didn't realize how supportive and important Twitter is. You know I always kind of considered it to be like another social media platform that I don't understand because I'm 84 years old and I just don't get it. It's been so uniquely helpful and in ways like Stack Overflow or even issues in GitHub, it just aren't. You can get so many more perspectives, so many different perspectives from people. SARON: Yeah, absolutely. Twitter has been amazing exactly for that. It's just an efficient way to crowdsource opinions and crowdsource perspectives and when you get your question answered and someone else answers it, it doesn't only benefit you the way it would if you email someone but it benefits anyone else who comes across that page, so yeah, it's hugely valuable. CHARLES: I remember the first moment I had kind of like that, a light bulb went off in my head where I was working on some really weird project that was using some strange wiki for its content storage and I was getting frustrated and I just tweeted about it and then the CTO of that company just immediately answered my question and I was like, "What?" You know, it was years ago and definitely, I was like, sound of explosion, that is where my mind exploded. I was not seeking help. I was just literally being kind of a jerk and venting frustration and lo and behold, the answer for my problem descended from the Twitter clouds. It was incredible. SARON: The Twitter clouds are the best clouds, usually CHARLES: Twitter is very... What's the word? It's very split down in the middle. SARON: Noodie? Yeah, there you go. SAM: There's this live feedback, so there's no buffer of emotion there, you know? SARON: Yeah. SAM: It's like, "Oh, this thing that you said, it made me mad. I'm going to tell you about it right now." Charles, I know that you had mentioned before that you think mentoring would be a good idea for Frontside and then, after all this discussion, have your views stayed the same? What are you feeling about that? CHARLES: As kind of the person who's like the grizzled veteran in the software world, it's definitely something that I've kind of whipped myself over the back. It's like feeling like it's something that we should do but I think it comes from the idea that people come here and we want to make sure that they're getting access to the learning that they need and the ways, in which they can level themselves up that they need, that's the kind of the prime motivator there. I always perceived mentorship as some vehicle through which to achieve that. It's something that I've heard. Obviously, we don't have a mentorship program at our company. It's something I felt that we should always be investigating. I've always felt maybe a little bit bad that we didn't have it but it's also something that I really struggled with in my career because I can't really say that I've ever had a mentor, so I don't really know what that relationship would look like but I do have a lot of people that I learned a lot of critical things from. I can look at it as kind of these seminal moments in my career, where like light bulbs went off and a lot of the time, they're associated with an individual and that individual and the thing that they taught me or multiple things that they taught me, are still with me. I have those experiences, which have been phenomenal and critical to my development as a software developer, so I guess it's just part and parcel of that impulse that you're describing to pay it forward, to realize that when you walked into the building, the lights were on and the walls were standing and the air was at a comfortable climate temperature. As you live there, you realize that there are people involved in actually, doing that maintenance and providing the building for you and the space for you to become aware of your world and then, when new people walk into the building, you want to provide them the same experience that you had. I guess that's my take on. That's the kind of thing that I would want to provide, so the question is like what does mentoring or mentoring 3.0, as we're maybe talking about in this conversation, how does that fit into that? How would you implement something like this, some sort of distributed learning in a company? I don't know. Maybe, it's not worthwhile. Maybe it is. SAM: I think it focuses more on that pair programming because when you're thinking back and you have all these people, like you have names of people that taught you something, it's multiple names. It's not just this one guy taught me all of these things. Actually, within a company, that mentoring just comes from pairing with your coworkers, seeing what different hats everybody wears and then, trying them on every now and again but not necessarily taking that individual's word as gospel, you know? CHARLES: Right and hopefully, that's not something that we've advocated for. Maybe, it's how do you introduce structure around that, to make sure that the proper ferment is happening, so that you have novel pairings and make sure the ideas that are flowing are flowing around the entire company and not just through certain set channels. SARON: Yeah. The other part of that is if you create structure around what it looks like to share outside. You know, pair programming is interesting because it's kind of one-on-one and it's hopefully, I have something important or bright to say in our pairing session. Maybe, I don't. Maybe I'm having a dull day. Maybe, I'm having a bad day but this really give you the same opportunity to take a moment and say, "What do I know? What do I want to share? What do I want to put together?" It does really give you a chance to prepare and gather yourself. It's kind of in the moment. I think having another opportunity where you can gather yourself is important and so, that might look like brown bag lunches, where everyone takes a turn and has to do a little lightning talk. That's usually the opportunity to say, "I have five minutes. I'm going to share something." Everyone has a turn, which means that the company's literally saying everyone has something to say. It's only five minutes, only a few minutes, so hopefully it won't be too terrifying if you're not big on public speaking and it's your co-worker so hopefully, it won't be terrifying because it's people you know and not total strangers. You know, a format like that, where there's structure but the company is saying, "We're going to give you time to think about what you're good at and what you know and to share that is good." I think another way to do that is by setting time aside for blogging. If your company can say, "Thirty minutes out of the week, we're going to take some time to write down five things I learned, to write down one cool thing I learned, post it publicly, post it internally about this expectation that everyone should be writing, everyone should be sharing, which also says everyone has something to share." I think those are two ideas and two ways that we can create a culture of sharing and a culture of distributed mentorship, where everyone has an opportunity to find the thing that they're excited about and specific ways to share it. SAM: Yeah, that's excellent. CHARLES: I hope you're grinning as much as I am, Sam because at least in the first half, you basically described our Lunch and Learn process. It's a little bit more than five minutes but I think another thing that clicked for me there is making sure that having a variation of expectations of quality or something like that because I feel like where we do really well is in the Lunch and Learn thing. We have a process very similar to what you describe but where we're not so good is maybe with blogging. I wonder if part of that is we just hold ourselves to such a high standard of what it is. The idea that we could throw together a blog post in 30 minutes, I love that idea but it means you really have to be willing to just say, "You know what? We're going to get it out there and we're going to make it bite-sized and the expectation is that we're not going to be writing some gigantic essay that's going to shake the industry to its core every Friday at three o'clock." There are things and if we can, I shouldn't say a reduction in quality but maybe a reduction in scope so that you can say like, "We're going to carve out 30 minutes or an hour and we're going to pick a topic that scope-appropriately for that." SARON: Absolutely and I think that knowing that you only have 30 minutes or maybe it's an hour -- an hour is probably a little bit more realistic -- but knowing that you only have an hour also forces scope. You can't write a book about JavaScript in an hour. You just can't, so the fact that by the end of that hour, you have to have something to turn in is a great way to force people to focus and do something really small and really bite-sized. The other thing is I don't think that after the hour, you need to publish it publicly. It could be, you need to turn it into someone else, to edit and look over for you and give you feedback. It's not quite ready yet but it's a solid first draft and the ideas that after that first person edits it, then it's on its way to being published. I think there's different ways to manage a scope without also making this scary thing where I have to say something for the Earth to shake. There's different things that we can do around that. CHARLES: I'm wondering what other forms of sharing that we can fit into our workday. I guess, the other baseline is just making sure that you're always... What is it? ABT -- always be tweeting. It's so easy to be write-only, not even engaging conversations but just throwing ideas out into the void. SAM: I think holding a discussion with your coworkers like if you're in an environment where you can work face to face or are constantly online, if you're more of a remote worker, I think just having a conversation with anybody, rather than just putting your idea out there, putting it out there with someone who can actually provide real time feedback in a more friendly way, then I think some people on Twitter could be. Because they're your coworkers and they're not going to call you rude names, you know? CHARLES: Right and you're also going to know, hopefully the whole trust and intent and 'are we on the same page?' that question is answered even before the text is written. SAM: Right. SARON: Yeah, absolutely and with those conversations, this actually mean [inaudible] that we do. We do like a show and tell every week and the idea is that we're both always learning random things, usually related things but sometimes, totally random but still very interesting and it will take 30 minutes to just share what we've learned. Sometimes, they'll also turn it into a blog post. Sometimes, it's just a knowledge sharing opportunity. I'm not really sure but it's a good window of opportunity to say, "We are learning and we're sharing and we have something of value to bring." The great thing about something like a show and tell is that it doesn't necessarily have to come from my brain. It doesn't have to be like, "I have a great idea that I'm going to share." It could be, "I read about this cool idea." It can be, "I heard about this cool thing that we can try and we can apply," but I still kind of credit, you know? Like I get credit for being the value bringer but the burden isn't on me every week to come up with the idea. That's a nice balance, to kind of create space to share and to promote this knowledge share and if it comes from you, it's great but if not, you're still helping other people. CHARLES: I have a question that may or may not be related in here. This has just kind of occurred to me because this is definitely something that I experienced, where I get into a mode where I become overwhelmed by the ideas that people are sharing and so, what's the balance? Because usually, we're out there searching for ideas and we're searching for novel things so that we can include them in our work, in the things that we want to do and accomplish, whether be that in tech or elsewhere. What's the balance of being heads down and being like, "You know what? I'm going to be closed to new ideas right now." Because they can be distracting, right? The [inaudible], that's actually a phenomenon and so, how do you protect yourself from sharing? What's the balance? SARON: My solution was to move to San Diego. That was my solution to that. I actually moved from New Jersey and I worked in New York City... How long has it been? Was it only been a year? Oh, my goodness, and now, I'm in San Diego and it was so interesting because that ended up being a really nice side effect. I didn't move specifically for that reason but when you are commuting in New York City every single day, there's so much going on all the time. There's just so many ideas and events and meet ups and companies and people. It's just so much. I think that it was a great place to be in my early 20s when I really just wanted to soak up everyone else's ideas and I didn't really have opinions of my own at that point and it's a great way to just kind of absorb and be this awesome sponge in the big city but after a while, I kind of realized, maybe I have my own ideas and my own thoughts, so moving to San Diego, which is a much, much, much quieter place, has been a really great way to reflect and sit with my own thoughts and feelings and opinions and just kind of focus on that. I understand that everyone can move to San Diego, although I highly recommend it but I think in that way of carving out like... What do they call it? Do they call it a tech sabbath? A digital sabbath? Am I saying that right? CHARLES: Yeah. Maybe. It sounds about right. SARON: Yeah. I came across that term recently but this idea of one day out of the week, I'm not going to be on the interweb. I'll just not going to do it. Maybe, even the whole weekend, oh, my goodness and saying, "I'm just going to stay away from things. I'm just going to create a little space for me to think and reflect." I think when I don't have the whole day and what I need is just like a moment, I find that writing things down is a great way -- a really, really good way of doing it -- even if I'm taking notes or from doing a strategy session or if I'm trying to make a decision. Usually, I'll start typing and what I've started to do recently is to say, "I'm not going to type. I'm going to plot in a notebook and I'm just going to write things down," and because writing is slower than typing, it forces you to just think. It forces you to be alone with your thoughts, for better or worse and it forces you to really just to think about what you're doing or what you're saying and reflect. It's a really, really great meditative exercise that I found. You know, finding little ways to build in an escape from the noise, ideally on a regular basis, I think is a really healthy thing to do. SAM: Yeah, I definitely agree with that. My normal method of sort of closing everybody off is I just sketch out ideas because I'm an artist. I come from that sort of perspective as I can make a drawing out of feelings more so than I can write them out. If I'm feeling really overwhelmed or if I'm trying to make sense of some information that people have given me, I just sketch it out and I think that's something that doesn't really get talked about a lot in the whole community because sometimes it's always about eat, breathe, live, code, you know? We have different skills. You have other things that you're good at that's not just code. When I was at React Rally, a lot of people were in the music and then finding a way to separate yourself from the entirety of it is definitely one of the better ways to make sense of your situation. SARON: Yup, absolutely. CHARLES: Yeah. Sleep? It's a great way to take a break. SARON: Sleep is so good. SAM: On my top three things: sleep. CHARLES: Yeah. SARON: Yeah. As a kid, I never ever thought I would look forward to my bedtime ever. You know, it's my favorite part of the day. CHARLES: Yeah but like sleep, writing, drawing, I always forget. Like when I'm caught up in a problem, I always forget that engaging in some other activity -- I like to walk in the place next to my house. I like to play my ukulele. Engaging in those activities is almost on the critical path to solving the problem and I always forget it. I think we always forget it but sometimes, you can be so frustrated and you can just shut it off, be completely alone and there is some magical process that's probably going on in your brain. I don't know exactly what it is but you come back and the answer is just sitting there, waiting practically on your desk. SARON: Absolutely. One thing, we recently moved a couple of weeks ago to a new place and it's a little bit bigger and so, I had the opportunity to unpack boxes and buy furniture that we didn't really need before or just trying to make it more of a home. I've been using it as a really great opportunity to be productive and to feel productive but not be in front of a screen. Sometimes, I even like save tasks for myself like, "I'm going to wait till the evening to put together this shelf because I'm going to need a moment to just be away from my computer." I have a plan around it so it ended up being such that, I think about every day, there's one little home activity thing that I can do, whether it's cleaning or cooking or assembly or movie or something with the home, that allows me to, because I'm not really a hobby person. I don't really do hobbies because it just feels, like no judgment on people who do. I know people get really into their hobbies but it just feels like, "Why?" You know, like, "Why?" like, "For what?" But when I put a shelf together, it's like, "I'm going to use this for books." You know what I mean? Like you're very purposeful, so home activities has been my way of carving out that space away from the screen but also feeling like I'm doing something productive, I'm getting things done. SAM: Something that I would recommend to anybody who doesn't really have that, I'm going to step away from the computer and do this thing. Something that's kind of helping me was the Pomodoro Technique, which if you're not familiar with that, it's basically a time management thing where you set your timer for work like for 25 minutes, 30 minutes or whatever and then, when the timer goes off, you take an allotted break for five minutes, 10 minutes, just so you're not doing the thing that you've been doing for the last 30 minutes. SARON: Yes, absolutely. That's a great one. SAM: My advice is to implement that if you don't have a thing, that you use for your cleaner, I guess. SARON: Oh, you want to hear some really terrible but effective advice? SAM: Yes. SARON: And this is what I found out very accidentally is if you have a really, really crappy office chair that hurts -- CHARLES: Oh, man. I'm sitting in one right now. It's literally a rocking chair from the 1800s. SARON: That sounds awesome. CHARLES: Yeah, it does sounds awesome. SARON: But if you have a crappy office chair, that can be a really great way to get away from your screen because after about an hour, your thighs will hurt and your back will hurt and you will be forced to get up and walk around. It's so funny because I have a pretty crappy office chair and my back has been hurting for so long and I just thought, "That's life." That's like my [inaudible] for myself. I'm like, "That's just how life is, my backs hurt," and then it got to a point where I was like, "I need to go and talk to someone," and as soon after that, I spoke to a conference and I was basically up and down away from any type of chair for like four or five days straight and magically, my back pain went away and I was, "Oh, my God. It's that freaking chair," and ever since I realized it, I started noticing it. I would sit down and I would go, "I'm nearing the one- Oh, there are my thighs. There they go. They're in pain." There's another great cheap life hack: get a crappy chair, after about an hour, everything will hurt. You will be forced to go do some jumping jacks for about five, 10 minutes and there's your additional sabbath. There you go. SAM: In Charles' case, probably a haunted office chair. Yeah, that's an excellent advice. I never really noticed that. Now, I'm going to. CHARLES: You know what funny is, I actually didn't even notice it but I do. I never used to get up and go on walks before or spend as much of the day standing as I do and I'm actually completely and totally oblivious to it but I think, I realize like I can attribute a lot of that to the terribly, uncomfortable chair, in which I sit on every day. SARON: I have this awesome habit of sitting cross-legged, which apparently is a very, very bad idea, my physical therapist told me, so I make it worse for myself. If you don't feel like you have enough screen time, just sit cross-legged and that will accelerate the pain process. SAM: As you said that, I am currently sitting cross-legged in my desk chair. SARON: Yeah! SAM: That's just how I sit in chairs. My legs are too short to reach the floor. SARON: Me too. I just find it so comfortable. I don't know and I'm so happy to hear that you also do this because I'm like, "Am I just weird?" because I love sitting cross-legged. It's so comfortable. It makes me really happy. SAM: No, I verified 100%, that's how I sit in all chairs. SARON: Yeah, the same. CHARLES: I can do one leg. SARON: Only one? Man, you need to work on that. SAM: -- [inaudible]. That's going to be the end of our podcast. Again, thank you Saron for coming on and having this awesome conversation about mentoring. Definitely check out the website CodeNewbie.org. We are the Frontside. We build software that you can stick a future on. Hit us up if you're looking for help building your next big thing and also, hit us up on Twitter. Hit Charles, myself, Frontside and Saron on Twitter. SARON: Thank you so much for having me. This is awesome. This is fun. SAM: Also, I want to give another thanks to Mandy, our producer for producing this lovely episode and all of our episodes. If you have any questions for us, hit us up on Twitter. Any ideas for future topics, any thoughts you have on this great conversation, let us know and we'll talk to you all later.

In this episode David talks about his Florida vacation, the recent Laravel Nova launch and controversy, and Andrew's wild time at React Rally.

In this episode of Second Career Devs, I chat with Michael Chan, a well known conference speaker and web developer in the React community. He shares his story of growing up working in the family business and how that took him from accounting, to music, to web development. He shares some nuggets of wisdom and a great new conference talk idea along the way. Links: Michael's talk at React Rally 2017 - https://www.youtube.com/watch?v=T9-Mb_axNgA War of Art by Steven Pressfield - https://www.amazon.com/War-Art-Through-Creative-Battles/dp/1936891026/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1530546676&sr=8-2 Michael's Talk on React Component Patterns - https://www.youtube.com/watch?v=YaZg8wg39QQ

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

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

1:00 Intro to guests Brian Douglas and Matt Christensen 2:20 Definition of JAMStack 8:12 JAMStack and confusion over nomenclature 12:56 JAMStack and security, reliability and performance 17:05 Example of traffic spike for company Sphero 18:26 Meaning of hyperdynamic 20:35 Future and limits of JAMStack technology 26:01 Controlling data and APIs versus using third parties 28:10 Netlify.com and JAMStack 31:16 APIs, JavaScript framework and libraries recommended to start building on JAMStack 35:13 Resources and examples of JAMStack: netlify.com, Netlify blog, JAMStack radio, JAMStack SF Meetup QUOTES: “I think in the next couple of years we’re going to see the limits being pushed a lot for what you can do with this.” - Matt “Today we’re starting to see really interesting, really large projects getting built with this approach.” - Matt “If you can farm 100% of your backend off to third parties, I feel like that really limits a lot of the interesting things you can do as a developer.” - Brian PICKS: Early History of Smalltalk (Jamison) React Rally 2016 videos (Jamison) FiveStack.computer (Jamison) Falsehoods programmers believe about time (Aimee) Nodevember conference (Aimee) 48 Days Podcast (Charles) Fall of Hades by Richard Paul Evans (Charles) Jon Benjamin Jazz (Brian) RailsConf 2016 (Brian) React Native (Brian) Book of Ye Podcast (Brian) Aurora by Kim Stanley Robinson (Matt) Sequoia Capital website Sphero website Isomorphic rendering on the Jam Stack by Phil Hawksworth SPONSORS: Front End Masters Hired.com

1:00 Intro to guests Brian Douglas and Matt Christensen 2:20 Definition of JAMStack 8:12 JAMStack and confusion over nomenclature 12:56 JAMStack and security, reliability and performance 17:05 Example of traffic spike for company Sphero 18:26 Meaning of hyperdynamic 20:35 Future and limits of JAMStack technology 26:01 Controlling data and APIs versus using third parties 28:10 Netlify.com and JAMStack 31:16 APIs, JavaScript framework and libraries recommended to start building on JAMStack 35:13 Resources and examples of JAMStack: netlify.com, Netlify blog, JAMStack radio, JAMStack SF Meetup QUOTES: “I think in the next couple of years we’re going to see the limits being pushed a lot for what you can do with this.” - Matt “Today we’re starting to see really interesting, really large projects getting built with this approach.” - Matt “If you can farm 100% of your backend off to third parties, I feel like that really limits a lot of the interesting things you can do as a developer.” - Brian PICKS: Early History of Smalltalk (Jamison) React Rally 2016 videos (Jamison) FiveStack.computer (Jamison) Falsehoods programmers believe about time (Aimee) Nodevember conference (Aimee) 48 Days Podcast (Charles) Fall of Hades by Richard Paul Evans (Charles) Jon Benjamin Jazz (Brian) RailsConf 2016 (Brian) React Native (Brian) Book of Ye Podcast (Brian) Aurora by Kim Stanley Robinson (Matt) Sequoia Capital website Sphero website Isomorphic rendering on the Jam Stack by Phil Hawksworth SPONSORS: Front End Masters Hired.com

1:00 Intro to guests Brian Douglas and Matt Christensen 2:20 Definition of JAMStack 8:12 JAMStack and confusion over nomenclature 12:56 JAMStack and security, reliability and performance 17:05 Example of traffic spike for company Sphero 18:26 Meaning of hyperdynamic 20:35 Future and limits of JAMStack technology 26:01 Controlling data and APIs versus using third parties 28:10 Netlify.com and JAMStack 31:16 APIs, JavaScript framework and libraries recommended to start building on JAMStack 35:13 Resources and examples of JAMStack: netlify.com, Netlify blog, JAMStack radio, JAMStack SF Meetup QUOTES: “I think in the next couple of years we’re going to see the limits being pushed a lot for what you can do with this.” - Matt “Today we’re starting to see really interesting, really large projects getting built with this approach.” - Matt “If you can farm 100% of your backend off to third parties, I feel like that really limits a lot of the interesting things you can do as a developer.” - Brian PICKS: Early History of Smalltalk (Jamison) React Rally 2016 videos (Jamison) FiveStack.computer (Jamison) Falsehoods programmers believe about time (Aimee) Nodevember conference (Aimee) 48 Days Podcast (Charles) Fall of Hades by Richard Paul Evans (Charles) Jon Benjamin Jazz (Brian) RailsConf 2016 (Brian) React Native (Brian) Book of Ye Podcast (Brian) Aurora by Kim Stanley Robinson (Matt) Sequoia Capital website Sphero website Isomorphic rendering on the Jam Stack by Phil Hawksworth SPONSORS: Front End Masters Hired.com

Michael Jackson, Stephen Rivas Jr, and Jay Phelps discuss React and other front end frameworks at React Rally.  Topics covered:  - Create-react-app - How using ember prior to react has affected the thinking behind working on react - React trainings - Building complex react apps - Webpack vs Rollup  - HistoryJS (react history) - How you should approach open source projects - React Router v4 - Early mistakes in the early router - Previews some of the changes happening with react router and react history.  -Integration of redux with react router and react history - React Router 4 - Sate management in react Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.

Tracy Lee interviews Ben Lesh at React Rally. They discuss the React community compared to other JavaScript communities, which they boil down to being very similar to a “choose-your-own-adventure”. Important things to note in this podcast: The benefits and costs of new ES2015 features, Node’s position in the JavaScript ecosystem and how TC39 standards are affecting the node ecosystem, senior developers mentoring and making junior developers feel comfortable, the promises spec and cancellation tokens with observables. Other topics: how React trainings differ from Angular or Ember trainings, the new create-react-app and why it’s so amazing, the new screencast site Yolobrolo, and why @godtributes is the most amazing twitter bot ever. Ben also might have said that Dan Abramov is a React superstar, but you’ll have to listen to be sure. Tracy called out Ben on not wearing the hat that Sam Saccone’s mother purchased him. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.

Modern Web sits down with Devon Lindsey (@devonbl), Sarah Drasner (@sarah_edo), James Kyle (@thejameskyle), and Katherine Poulter (@katpoulter) at React Rally (@reactrally).  Our main goal was to put them in power ranger outfits, but you’ll have to watch that on Youtube. Listen as they discuss the benefits of being an individual technical contributor versus taking the management route. The four share their views on the excitement of being a JavaScript developer, learning new technologies and how the trend of openly sharing code has helped speed up the evolution of OSS and technology. Other topics discussed are companies giving engineers time for open source projects, how awesome the React community is at being nice to each other, and how conferences help you get to know community leaders better. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.

03:08 - Benjamin Dunphy Introduction Twitter GitHub 04:07 - Berkeley Martinez Introduction Twitter GitHub Free Code Camp 04:19 - Ian Sinnott Introduction Twitter GitHub Blog TruSTAR Technology 05:19 - The React Codebase 12:38 - Other Important Parts of the React Ecosystem 14:22 - The Angular vs the React Ecosystem and Community The Learning Curve create-react-app 22:07 - Community Developer Experience Functional Programming 26:56 - Getting Connected to the React Community Meetup: Real World React @rwreact ReactJS San Francisco Bay Area Meetup Meetup Eventbrite Calagator Twitter Dan Abramov: My React List 29:34 - Conferences React.js Conf React Rally ReactNext ReactiveConf ReactEurope 33:28 - Technology From the Community redux ThunderCats.js 38:23 - Choices Are Expanding; Not Shrinking Linting 40:19 - The Future of React 42:39 - Starting More Communities   Picks This Developing Story (Aimee) Nashville (Aimee) Nodevember (Aimee) egghead.io: React in 7 Minutes (Ben) Lee Byron: Immutable User Interfaces @ Render 2016 (Ben) Nick Schrock: React.js Conf 2016 Keynote (Ben) create-react-app (Ian) Functional Programming Jargon (Ian) The Serverless Framework (Ian) Ben's Blog (Berkeley) Isaac Asimov’s Robot Series (Berkeley) Vsauce: The Zipf Mystery (Berkeley) Kinesis Advantage for PC & Mac (Dave)

03:08 - Benjamin Dunphy Introduction Twitter GitHub 04:07 - Berkeley Martinez Introduction Twitter GitHub Free Code Camp 04:19 - Ian Sinnott Introduction Twitter GitHub Blog TruSTAR Technology 05:19 - The React Codebase 12:38 - Other Important Parts of the React Ecosystem 14:22 - The Angular vs the React Ecosystem and Community The Learning Curve create-react-app 22:07 - Community Developer Experience Functional Programming 26:56 - Getting Connected to the React Community Meetup: Real World React @rwreact ReactJS San Francisco Bay Area Meetup Meetup Eventbrite Calagator Twitter Dan Abramov: My React List 29:34 - Conferences React.js Conf React Rally ReactNext ReactiveConf ReactEurope 33:28 - Technology From the Community redux ThunderCats.js 38:23 - Choices Are Expanding; Not Shrinking Linting 40:19 - The Future of React 42:39 - Starting More Communities   Picks This Developing Story (Aimee) Nashville (Aimee) Nodevember (Aimee) egghead.io: React in 7 Minutes (Ben) Lee Byron: Immutable User Interfaces @ Render 2016 (Ben) Nick Schrock: React.js Conf 2016 Keynote (Ben) create-react-app (Ian) Functional Programming Jargon (Ian) The Serverless Framework (Ian) Ben's Blog (Berkeley) Isaac Asimov’s Robot Series (Berkeley) Vsauce: The Zipf Mystery (Berkeley) Kinesis Advantage for PC & Mac (Dave)

03:08 - Benjamin Dunphy Introduction Twitter GitHub 04:07 - Berkeley Martinez Introduction Twitter GitHub Free Code Camp 04:19 - Ian Sinnott Introduction Twitter GitHub Blog TruSTAR Technology 05:19 - The React Codebase 12:38 - Other Important Parts of the React Ecosystem 14:22 - The Angular vs the React Ecosystem and Community The Learning Curve create-react-app 22:07 - Community Developer Experience Functional Programming 26:56 - Getting Connected to the React Community Meetup: Real World React @rwreact ReactJS San Francisco Bay Area Meetup Meetup Eventbrite Calagator Twitter Dan Abramov: My React List 29:34 - Conferences React.js Conf React Rally ReactNext ReactiveConf ReactEurope 33:28 - Technology From the Community redux ThunderCats.js 38:23 - Choices Are Expanding; Not Shrinking Linting 40:19 - The Future of React 42:39 - Starting More Communities   Picks This Developing Story (Aimee) Nashville (Aimee) Nodevember (Aimee) egghead.io: React in 7 Minutes (Ben) Lee Byron: Immutable User Interfaces @ Render 2016 (Ben) Nick Schrock: React.js Conf 2016 Keynote (Ben) create-react-app (Ian) Functional Programming Jargon (Ian) The Serverless Framework (Ian) Ben's Blog (Berkeley) Isaac Asimov’s Robot Series (Berkeley) Vsauce: The Zipf Mystery (Berkeley) Kinesis Advantage for PC & Mac (Dave)

Conferences continue to be a great way to learn and grow as an engineer. In the 14th episode of the Front End Happy Hour podcast we discuss the value of conferences and why you might want to attend. It’s a special episode because we recorded at React Rally in Salt Lake City. At the conference we caught up with a lot of great attendees and speakers to hear about their experiences at conferences and the benefits for attending. Items mentioned in the episode: React Rally, Fluent Conference, Scotland JS, FITC, Adobe Max, Jamison Dance, Matt Zabriskie, React JS, Pete Hunt, Stranger Things, Xoxo, Recruiter episode Guests: Tasha Alfano - @TashAlfano Sumana Mohan - @sumana_mohan Henry Zhu - @left_pad Ryan Wachholz - @https://github.com/wachie Quinn Daniels - @https://github.com/aqdaniels Hani Ahir - @HaniAhir Albert Toledo - @toledoalbert Brian Tice - @BrianTice99 Panelists: Ryan Burgess - @burgessdryan Jem Young - @JemYoung Ryan Anklam - @bittersweetryan Picks: Ryan Burgess - V-moda m-100 headphones Ryan Burgess - Deadmau5 Stranger Things Cover Jem Young - Emojipedia Jem Young - Tron Legacy Reconfigured Ryan Anklam - Disclosure - You & Me - Flume remix Ryan Anklam - Zamst Knee Brace

React Remote Conf and Angular Remote Conf   03:15 - Justin Searls Introduction Twitter GitHub Blog Test Double JavaScript Jabber Episode #038: Jasmine with Justin Searls 04:13 - Testing testdouble.js teenytest Sinon.JS 08:44 - Mocking Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Jim Weirich 14:45 - Starting These Concepts as a Junior Developer Test-driven Development 17:55 - testdouble.js vs. sinon.js NIH = Not Invented Here 26:39 - Duck Typing, Monkey Patching, Duck Punching 32:22 - Node.js Negativity Design, Resources Martin Fowler’s Refactoring and Patterns Books Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans 42:52 - Community 45:08 - The AAA Rule: Arrange, Act, Assert 51:19 - Error Messages   Picks Unemployment (Jamison) React Rally (Jamison) Julia Evans' Tweet: how to be a wizard programmer  (Jamison) See the good in people (Aimee) Sinon.JS (Joe) How to Stay Motivated: Developing the Qualities of Success by Zig Ziglar (Chuck) The Harry Potter Series (Chuck) RetroPie (Justin) How Elm can Make you a Better JavaScript Programer (Justin) NEJS Conf (Justin)

React Remote Conf and Angular Remote Conf   03:15 - Justin Searls Introduction Twitter GitHub Blog Test Double JavaScript Jabber Episode #038: Jasmine with Justin Searls 04:13 - Testing testdouble.js teenytest Sinon.JS 08:44 - Mocking Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Jim Weirich 14:45 - Starting These Concepts as a Junior Developer Test-driven Development 17:55 - testdouble.js vs. sinon.js NIH = Not Invented Here 26:39 - Duck Typing, Monkey Patching, Duck Punching 32:22 - Node.js Negativity Design, Resources Martin Fowler’s Refactoring and Patterns Books Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans 42:52 - Community 45:08 - The AAA Rule: Arrange, Act, Assert 51:19 - Error Messages   Picks Unemployment (Jamison) React Rally (Jamison) Julia Evans' Tweet: how to be a wizard programmer  (Jamison) See the good in people (Aimee) Sinon.JS (Joe) How to Stay Motivated: Developing the Qualities of Success by Zig Ziglar (Chuck) The Harry Potter Series (Chuck) RetroPie (Justin) How Elm can Make you a Better JavaScript Programer (Justin) NEJS Conf (Justin)

React Remote Conf and Angular Remote Conf   03:15 - Justin Searls Introduction Twitter GitHub Blog Test Double JavaScript Jabber Episode #038: Jasmine with Justin Searls 04:13 - Testing testdouble.js teenytest Sinon.JS 08:44 - Mocking Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Jim Weirich 14:45 - Starting These Concepts as a Junior Developer Test-driven Development 17:55 - testdouble.js vs. sinon.js NIH = Not Invented Here 26:39 - Duck Typing, Monkey Patching, Duck Punching 32:22 - Node.js Negativity Design, Resources Martin Fowler’s Refactoring and Patterns Books Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans 42:52 - Community 45:08 - The AAA Rule: Arrange, Act, Assert 51:19 - Error Messages   Picks Unemployment (Jamison) React Rally (Jamison) Julia Evans' Tweet: how to be a wizard programmer  (Jamison) See the good in people (Aimee) Sinon.JS (Joe) How to Stay Motivated: Developing the Qualities of Success by Zig Ziglar (Chuck) The Harry Potter Series (Chuck) RetroPie (Justin) How Elm can Make you a Better JavaScript Programer (Justin) NEJS Conf (Justin)

03:08 - John A. De Goes Introduction Twitter GitHub Blog SlamData 04:07 - PureScript JavaScript Jabber Episode #189: PureScript with John A. De Goes and Phil Freeman 04:58 - “Purely Functional” 09:18 - Weaknesses With Functional Programming Object-oriented Programming Procedural Programming 14:36 - Organizing a FP Codebase John A. De Goes: A Modern Architecture for FP 17:54 - Beginners and Functional Programming; Getting Started Learning About the History of Functional Programming Hiring Junior Devs to do FP 28:20 - The Rise of Functional Programming in JavaScript-land 32:08 - Handling Existing Applications 36:03 - Complexity Argument 41:53 - Weighing Language Tradeoffs; Alt.js Picks Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 (Aimee) React Rally (Jamison) Cleanup Algorithm (Jamison) PostgreSQL Exercises (Jamison) iPad Pro (Chuck) Smart Keyboard for iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) John A. De Goes: Halogen: Past, Present, and Future (John) slamdata (John)

03:08 - John A. De Goes Introduction Twitter GitHub Blog SlamData 04:07 - PureScript JavaScript Jabber Episode #189: PureScript with John A. De Goes and Phil Freeman 04:58 - “Purely Functional” 09:18 - Weaknesses With Functional Programming Object-oriented Programming Procedural Programming 14:36 - Organizing a FP Codebase John A. De Goes: A Modern Architecture for FP 17:54 - Beginners and Functional Programming; Getting Started Learning About the History of Functional Programming Hiring Junior Devs to do FP 28:20 - The Rise of Functional Programming in JavaScript-land 32:08 - Handling Existing Applications 36:03 - Complexity Argument 41:53 - Weighing Language Tradeoffs; Alt.js Picks Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 (Aimee) React Rally (Jamison) Cleanup Algorithm (Jamison) PostgreSQL Exercises (Jamison) iPad Pro (Chuck) Smart Keyboard for iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) John A. De Goes: Halogen: Past, Present, and Future (John) slamdata (John)

03:08 - John A. De Goes Introduction Twitter GitHub Blog SlamData 04:07 - PureScript JavaScript Jabber Episode #189: PureScript with John A. De Goes and Phil Freeman 04:58 - “Purely Functional” 09:18 - Weaknesses With Functional Programming Object-oriented Programming Procedural Programming 14:36 - Organizing a FP Codebase John A. De Goes: A Modern Architecture for FP 17:54 - Beginners and Functional Programming; Getting Started Learning About the History of Functional Programming Hiring Junior Devs to do FP 28:20 - The Rise of Functional Programming in JavaScript-land 32:08 - Handling Existing Applications 36:03 - Complexity Argument 41:53 - Weighing Language Tradeoffs; Alt.js Picks Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 (Aimee) React Rally (Jamison) Cleanup Algorithm (Jamison) PostgreSQL Exercises (Jamison) iPad Pro (Chuck) Smart Keyboard for iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) John A. De Goes: Halogen: Past, Present, and Future (John) slamdata (John)

React Remote Conf and Angular Remote Conf   03:18 - Dennis Ushakov Introduction Twitter GitHub JetBrains JetBrains Issue Tracker WebStorm @WebStormIDE   03:54 - Writing an IDE in Java YouTrack TeamCity   04:50 - Specs 05:43 - WebStorm Defined Integrated Development Environment (IDE) 06:19 - IDEs vs Text Editors 08:31 - Building an IDE Language Support External Tool Support Abstract Syntax Tree (AST) 13:00 - Code Reuse 15:07 - Prioritizing Features 17:11 - Why is IDE tooling important? “Code is read a lot more than it’s written.” 19:57 - Refactorings The Dynamic Nature of JavaScript TypeScript-specific Refactorings 23:35 - Next Versions of Webstorm Early Access Program 25:07 - Framework Support; Usage Data 28:12 - Other Technology and Framework Support 31:12 - Working for JetBrains 32:17 - Release Cycles and Procedures Early Access Program 34:39 - Java Source Code Contribution Kotlin   Picks Jesse Kriss: Human scale technology (Jamison) React Rally (Jamison) Vote (Chuck) Transmit (Chuck) Steam Squad (Dennis) Ergobaby Four Position 360 Baby Carrier (Dennis)

React Remote Conf and Angular Remote Conf   03:18 - Dennis Ushakov Introduction Twitter GitHub JetBrains JetBrains Issue Tracker WebStorm @WebStormIDE   03:54 - Writing an IDE in Java YouTrack TeamCity   04:50 - Specs 05:43 - WebStorm Defined Integrated Development Environment (IDE) 06:19 - IDEs vs Text Editors 08:31 - Building an IDE Language Support External Tool Support Abstract Syntax Tree (AST) 13:00 - Code Reuse 15:07 - Prioritizing Features 17:11 - Why is IDE tooling important? “Code is read a lot more than it’s written.” 19:57 - Refactorings The Dynamic Nature of JavaScript TypeScript-specific Refactorings 23:35 - Next Versions of Webstorm Early Access Program 25:07 - Framework Support; Usage Data 28:12 - Other Technology and Framework Support 31:12 - Working for JetBrains 32:17 - Release Cycles and Procedures Early Access Program 34:39 - Java Source Code Contribution Kotlin   Picks Jesse Kriss: Human scale technology (Jamison) React Rally (Jamison) Vote (Chuck) Transmit (Chuck) Steam Squad (Dennis) Ergobaby Four Position 360 Baby Carrier (Dennis)

React Remote Conf and Angular Remote Conf   03:18 - Dennis Ushakov Introduction Twitter GitHub JetBrains JetBrains Issue Tracker WebStorm @WebStormIDE   03:54 - Writing an IDE in Java YouTrack TeamCity   04:50 - Specs 05:43 - WebStorm Defined Integrated Development Environment (IDE) 06:19 - IDEs vs Text Editors 08:31 - Building an IDE Language Support External Tool Support Abstract Syntax Tree (AST) 13:00 - Code Reuse 15:07 - Prioritizing Features 17:11 - Why is IDE tooling important? “Code is read a lot more than it’s written.” 19:57 - Refactorings The Dynamic Nature of JavaScript TypeScript-specific Refactorings 23:35 - Next Versions of Webstorm Early Access Program 25:07 - Framework Support; Usage Data 28:12 - Other Technology and Framework Support 31:12 - Working for JetBrains 32:17 - Release Cycles and Procedures Early Access Program 34:39 - Java Source Code Contribution Kotlin   Picks Jesse Kriss: Human scale technology (Jamison) React Rally (Jamison) Vote (Chuck) Transmit (Chuck) Steam Squad (Dennis) Ergobaby Four Position 360 Baby Carrier (Dennis)

Ben Lesh and Tracy Lee interview Zabriskie’s Beard and Jamison Dance on the accidental creation of React Rally, how the JavaScript framework communities are organically formed based on the strength of the framework's opinions and exploration into why the react community exists in the form that it does. Also discussed are Power Rangers fighting bananas at React Rally, how redux is pushing the envelope for react developers to solve harder problems, and discussing the possibilities of a future react cli. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.

02:25 - Kyle Simpson Introduction Twitter GitHub Blog “Getify” You-Dont-Know-JS [Pluralsight] Advanced JavaScript by Kyle Simpson 04:43 - Development => Teaching Front End Masters 16:20 - Inheritance and Delegation 29:40 - Evolving a Language 36:23 - Cohersion Weak Typing, Dynamic Typing The Politics of JavaScript by Angus Croll 50:37 - Performance The Width Keyword 54:33 - Developer Education Programs and The Skill of Teaching   Picks Adam Tornhill: Code, Crime, Complexity: Analyzing software with forensic psychology @ TEDxTrondheim (Aimee) Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill (Aimee) Planet Money Episode 704: Open Office (Jamison) Zooko's Triangle (Jamison) The Barkley Marathons (Jamison) React Rally (Jamison) X-Men: Apocalypse (Joe) America's Got Talent (Joe) Overwatch (Joe) Stack (Kyle) Jeremy Keith: A web for everyone (Kyle) Jeremy Keith: Regressive Web Apps (Kyle)

02:25 - Kyle Simpson Introduction Twitter GitHub Blog “Getify” You-Dont-Know-JS [Pluralsight] Advanced JavaScript by Kyle Simpson 04:43 - Development => Teaching Front End Masters 16:20 - Inheritance and Delegation 29:40 - Evolving a Language 36:23 - Cohersion Weak Typing, Dynamic Typing The Politics of JavaScript by Angus Croll 50:37 - Performance The Width Keyword 54:33 - Developer Education Programs and The Skill of Teaching   Picks Adam Tornhill: Code, Crime, Complexity: Analyzing software with forensic psychology @ TEDxTrondheim (Aimee) Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill (Aimee) Planet Money Episode 704: Open Office (Jamison) Zooko's Triangle (Jamison) The Barkley Marathons (Jamison) React Rally (Jamison) X-Men: Apocalypse (Joe) America's Got Talent (Joe) Overwatch (Joe) Stack (Kyle) Jeremy Keith: A web for everyone (Kyle) Jeremy Keith: Regressive Web Apps (Kyle)

02:25 - Kyle Simpson Introduction Twitter GitHub Blog “Getify” You-Dont-Know-JS [Pluralsight] Advanced JavaScript by Kyle Simpson 04:43 - Development => Teaching Front End Masters 16:20 - Inheritance and Delegation 29:40 - Evolving a Language 36:23 - Cohersion Weak Typing, Dynamic Typing The Politics of JavaScript by Angus Croll 50:37 - Performance The Width Keyword 54:33 - Developer Education Programs and The Skill of Teaching   Picks Adam Tornhill: Code, Crime, Complexity: Analyzing software with forensic psychology @ TEDxTrondheim (Aimee) Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill (Aimee) Planet Money Episode 704: Open Office (Jamison) Zooko's Triangle (Jamison) The Barkley Marathons (Jamison) React Rally (Jamison) X-Men: Apocalypse (Joe) America's Got Talent (Joe) Overwatch (Joe) Stack (Kyle) Jeremy Keith: A web for everyone (Kyle) Jeremy Keith: Regressive Web Apps (Kyle)

Check out Newbie Remote Conf!   02:44 - What it Takes to Learn JavaScript in 2016 04:03 - Resources: Then vs Now 09:42 - Are there prerequisites? Should you have experience? 20:34 - Choosing What to Learn The iPhreaks Show Episode #153: Using Mobile Devices to Manage Diabetes with Scott Hanselman 28:19 - Deciding What to Learn Next 31:19 - Keeping Up: Obligations As a Developer 34:22 - Deciding What to Learn Next (Cont’d) 42:01 - Recommendations You-Dont-Know-JS gulp.js webpack The Little Schemer Designing Data-Intensive Applications by Martin Kleppmann   Picks accidentally nonblocking (Jamison) choo (Jamison) Web Rebels (Jamison) React Rally (Jamison) Grab The Gold (Aimee) node-for-beginners (Aimee) Procrastinate On Purpose by Rory Vaden (Chuck) Newbie Remote Conf (Chuck) Get A Coder Job (Chuck)

Check out Newbie Remote Conf!   02:44 - What it Takes to Learn JavaScript in 2016 04:03 - Resources: Then vs Now 09:42 - Are there prerequisites? Should you have experience? 20:34 - Choosing What to Learn The iPhreaks Show Episode #153: Using Mobile Devices to Manage Diabetes with Scott Hanselman 28:19 - Deciding What to Learn Next 31:19 - Keeping Up: Obligations As a Developer 34:22 - Deciding What to Learn Next (Cont’d) 42:01 - Recommendations You-Dont-Know-JS gulp.js webpack The Little Schemer Designing Data-Intensive Applications by Martin Kleppmann   Picks accidentally nonblocking (Jamison) choo (Jamison) Web Rebels (Jamison) React Rally (Jamison) Grab The Gold (Aimee) node-for-beginners (Aimee) Procrastinate On Purpose by Rory Vaden (Chuck) Newbie Remote Conf (Chuck) Get A Coder Job (Chuck)

Check out Newbie Remote Conf!   02:44 - What it Takes to Learn JavaScript in 2016 04:03 - Resources: Then vs Now 09:42 - Are there prerequisites? Should you have experience? 20:34 - Choosing What to Learn The iPhreaks Show Episode #153: Using Mobile Devices to Manage Diabetes with Scott Hanselman 28:19 - Deciding What to Learn Next 31:19 - Keeping Up: Obligations As a Developer 34:22 - Deciding What to Learn Next (Cont’d) 42:01 - Recommendations You-Dont-Know-JS gulp.js webpack The Little Schemer Designing Data-Intensive Applications by Martin Kleppmann   Picks accidentally nonblocking (Jamison) choo (Jamison) Web Rebels (Jamison) React Rally (Jamison) Grab The Gold (Aimee) node-for-beginners (Aimee) Procrastinate On Purpose by Rory Vaden (Chuck) Newbie Remote Conf (Chuck) Get A Coder Job (Chuck)

Our guests in this episode are Jamison Dance and Matt Zabriskie, OSS contributors and organizers of React RallyFollow us on Twitter

Check out Newbie Remote Conf and get your tickets!   02:24 - Guillermo Rauch Introduction Twitter GitHub Blog ZEIT @zeithq   Cloudup Mongoose.js Socket.IO 03:07 - Now: Realtime Node.js Deployments 04:28 - Key Concepts now-serve Heroku 10:22 - Deployment Process 14:55 - Getting Started Experience About 17:22 - Technology vs Design 20:36 - Running Now vs npm-install 27:17 - Simplicity; SSH and Metrics 35:33 - Debugging and Performance 37:34 - Security 41:44 - What’s Next?   Picks Overwatch (Joe) To Kill A Mockingbird by Harper Lee (Jamison) React Rally (Jamison) Grokking Algorithms: An illustrated guide for programmers and other curious people by Aditya Y. Bhargava (Aimee) Birgitta Böckeler: Born for it (Aimee) TSA Pre✓ (Chuck) RIF6 Cube 2-inch Mobile Projector (Chuck) Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracy (Guillermo)

Check out Newbie Remote Conf and get your tickets!   02:24 - Guillermo Rauch Introduction Twitter GitHub Blog ZEIT @zeithq   Cloudup Mongoose.js Socket.IO 03:07 - Now: Realtime Node.js Deployments 04:28 - Key Concepts now-serve Heroku 10:22 - Deployment Process 14:55 - Getting Started Experience About 17:22 - Technology vs Design 20:36 - Running Now vs npm-install 27:17 - Simplicity; SSH and Metrics 35:33 - Debugging and Performance 37:34 - Security 41:44 - What’s Next?   Picks Overwatch (Joe) To Kill A Mockingbird by Harper Lee (Jamison) React Rally (Jamison) Grokking Algorithms: An illustrated guide for programmers and other curious people by Aditya Y. Bhargava (Aimee) Birgitta Böckeler: Born for it (Aimee) TSA Pre✓ (Chuck) RIF6 Cube 2-inch Mobile Projector (Chuck) Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracy (Guillermo)

Check out Newbie Remote Conf and get your tickets!   02:24 - Guillermo Rauch Introduction Twitter GitHub Blog ZEIT @zeithq   Cloudup Mongoose.js Socket.IO 03:07 - Now: Realtime Node.js Deployments 04:28 - Key Concepts now-serve Heroku 10:22 - Deployment Process 14:55 - Getting Started Experience About 17:22 - Technology vs Design 20:36 - Running Now vs npm-install 27:17 - Simplicity; SSH and Metrics 35:33 - Debugging and Performance 37:34 - Security 41:44 - What’s Next?   Picks Overwatch (Joe) To Kill A Mockingbird by Harper Lee (Jamison) React Rally (Jamison) Grokking Algorithms: An illustrated guide for programmers and other curious people by Aditya Y. Bhargava (Aimee) Birgitta Böckeler: Born for it (Aimee) TSA Pre✓ (Chuck) RIF6 Cube 2-inch Mobile Projector (Chuck) Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracy (Guillermo)

02:34 - Michael Glukhovsky Introduction Twitter RethinkDB @rethinkdb 02:35 - horizon-js 04:52 - Versus Open Source Firebase 06:15 - The Security Model Horizon.io 07:56 - The Admin Interface 09:16 - RethinkDB + Horizon 10:56 - Versus Meteor 13:35 - Message Format 14:26 - Getting Started 19:01 - Real-time 21:24 - Security 26:56 - The Grand Vision; Use Cases 32:17 - Managing Deployment with Redundancy   Picks That Conference (Joe) AngularConnect (Joe) React Rally (Joe) Soft Skills Engineering Podcast (Dave) May the 4th (Chuck) The Developer Preview (Mike) The Art Spirit Paperback by Robert Henri (Mike) React Rally (Jamison) Uncanny Valley Podcast  (Jamison) Kishi Boshi (Jamison) David R. MacIver: On criticizing programming languages (without criticizing their users) (Aimee)

02:34 - Michael Glukhovsky Introduction Twitter RethinkDB @rethinkdb 02:35 - horizon-js 04:52 - Versus Open Source Firebase 06:15 - The Security Model Horizon.io 07:56 - The Admin Interface 09:16 - RethinkDB + Horizon 10:56 - Versus Meteor 13:35 - Message Format 14:26 - Getting Started 19:01 - Real-time 21:24 - Security 26:56 - The Grand Vision; Use Cases 32:17 - Managing Deployment with Redundancy   Picks That Conference (Joe) AngularConnect (Joe) React Rally (Joe) Soft Skills Engineering Podcast (Dave) May the 4th (Chuck) The Developer Preview (Mike) The Art Spirit Paperback by Robert Henri (Mike) React Rally (Jamison) Uncanny Valley Podcast  (Jamison) Kishi Boshi (Jamison) David R. MacIver: On criticizing programming languages (without criticizing their users) (Aimee)

02:34 - Michael Glukhovsky Introduction Twitter RethinkDB @rethinkdb 02:35 - horizon-js 04:52 - Versus Open Source Firebase 06:15 - The Security Model Horizon.io 07:56 - The Admin Interface 09:16 - RethinkDB + Horizon 10:56 - Versus Meteor 13:35 - Message Format 14:26 - Getting Started 19:01 - Real-time 21:24 - Security 26:56 - The Grand Vision; Use Cases 32:17 - Managing Deployment with Redundancy   Picks That Conference (Joe) AngularConnect (Joe) React Rally (Joe) Soft Skills Engineering Podcast (Dave) May the 4th (Chuck) The Developer Preview (Mike) The Art Spirit Paperback by Robert Henri (Mike) React Rally (Jamison) Uncanny Valley Podcast  (Jamison) Kishi Boshi (Jamison) David R. MacIver: On criticizing programming languages (without criticizing their users) (Aimee)

02:22 - Michael North Introduction Twitter GitHub Levanto Financial 04:10 - Ember vs React or Angular JavaScript Jabber Episode #203: Aurelia with Rob Eisenberg 07:13 - Convention Over Configuration 09:39 - Changes in Ember SproutCore   iCloud Ember CLI Performance glimmer 16:04 - Ember FastBoot Building a performant real-time web app with Ember Fastboot and Phoenix 18:53 - EmberConf Opening Keynote by Yehuda Katz & Tom Dale 22:47 - Mobile/Native Experience & Optimization Service Worker Hybrid Apps 29:52 - Electron 30:46 - Open Source Empowerment; The Ember Learning Team 33:54 - Michael North's Frontend Masters Ember 2 Series 37:11 - The Ember Community Picks React Rally (Jamison) Embedded (Jamison) Remy Sharp: A debugging thought process (Jamison) NashDev Podcast (Aimee) JS developers who don’t know what closure is are fine. (Aimee) Sublime Text (Chuck) DesktopServer (Chuck) MemberPress (Chuck) Frontend Masters (Mike) Wicked Good Ember Conf (Mike) Debugging Node.js with Visual Studio Code (Mike)

02:22 - Michael North Introduction Twitter GitHub Levanto Financial 04:10 - Ember vs React or Angular JavaScript Jabber Episode #203: Aurelia with Rob Eisenberg 07:13 - Convention Over Configuration 09:39 - Changes in Ember SproutCore   iCloud Ember CLI Performance glimmer 16:04 - Ember FastBoot Building a performant real-time web app with Ember Fastboot and Phoenix 18:53 - EmberConf Opening Keynote by Yehuda Katz & Tom Dale 22:47 - Mobile/Native Experience & Optimization Service Worker Hybrid Apps 29:52 - Electron 30:46 - Open Source Empowerment; The Ember Learning Team 33:54 - Michael North's Frontend Masters Ember 2 Series 37:11 - The Ember Community Picks React Rally (Jamison) Embedded (Jamison) Remy Sharp: A debugging thought process (Jamison) NashDev Podcast (Aimee) JS developers who don’t know what closure is are fine. (Aimee) Sublime Text (Chuck) DesktopServer (Chuck) MemberPress (Chuck) Frontend Masters (Mike) Wicked Good Ember Conf (Mike) Debugging Node.js with Visual Studio Code (Mike)

02:22 - Michael North Introduction Twitter GitHub Levanto Financial 04:10 - Ember vs React or Angular JavaScript Jabber Episode #203: Aurelia with Rob Eisenberg 07:13 - Convention Over Configuration 09:39 - Changes in Ember SproutCore   iCloud Ember CLI Performance glimmer 16:04 - Ember FastBoot Building a performant real-time web app with Ember Fastboot and Phoenix 18:53 - EmberConf Opening Keynote by Yehuda Katz & Tom Dale 22:47 - Mobile/Native Experience & Optimization Service Worker Hybrid Apps 29:52 - Electron 30:46 - Open Source Empowerment; The Ember Learning Team 33:54 - Michael North's Frontend Masters Ember 2 Series 37:11 - The Ember Community Picks React Rally (Jamison) Embedded (Jamison) Remy Sharp: A debugging thought process (Jamison) NashDev Podcast (Aimee) JS developers who don’t know what closure is are fine. (Aimee) Sublime Text (Chuck) DesktopServer (Chuck) MemberPress (Chuck) Frontend Masters (Mike) Wicked Good Ember Conf (Mike) Debugging Node.js with Visual Studio Code (Mike)

02:51 - Marcus Blankenship Introduction Twitter Blog 03:09 - Panelist Worst Boss Experiences 13:06 - Developer Anarchy vs Having a Hierarchy SE-Radio Episode 253: Fred George on Developer Anarchy The Valve Playbook 20:57 - Transitioning Managers Impostor Syndrome 26:05 - Manager Influence 28:33 - Management vs Leadership Leader-Member Exchange Theory 34:37 - Interpersonal Relationships and Happiness 38:24 - What kind of feedback do managers want from their employees? Timesheets 46:17 - Am I manager material? Am I ready to go into management? 48:06 - Following a Technical Track 51:55 - Why would anyone ever want to be a department manager? Picks A Plain English Guide to JavaScript Prototypes (Aimee) Oatmega (Aimee) Luck by Tom Vek (Jamison) The 27 Challenges Managers Face: Step-by-Step Solutions to (Nearly) All of Your Management Problems by Bruce Tulgan (Marcus) React Rally Call for Proposals (Jamison) React Rally (Jamison) Multipliers: How the Best Leaders Make Everyone Smarter by Liz Wiseman (Dave) Soft Skills Engineering Podcast (Dave)

02:51 - Marcus Blankenship Introduction Twitter Blog 03:09 - Panelist Worst Boss Experiences 13:06 - Developer Anarchy vs Having a Hierarchy SE-Radio Episode 253: Fred George on Developer Anarchy The Valve Playbook 20:57 - Transitioning Managers Impostor Syndrome 26:05 - Manager Influence 28:33 - Management vs Leadership Leader-Member Exchange Theory 34:37 - Interpersonal Relationships and Happiness 38:24 - What kind of feedback do managers want from their employees? Timesheets 46:17 - Am I manager material? Am I ready to go into management? 48:06 - Following a Technical Track 51:55 - Why would anyone ever want to be a department manager? Picks A Plain English Guide to JavaScript Prototypes (Aimee) Oatmega (Aimee) Luck by Tom Vek (Jamison) The 27 Challenges Managers Face: Step-by-Step Solutions to (Nearly) All of Your Management Problems by Bruce Tulgan (Marcus) React Rally Call for Proposals (Jamison) React Rally (Jamison) Multipliers: How the Best Leaders Make Everyone Smarter by Liz Wiseman (Dave) Soft Skills Engineering Podcast (Dave)

02:51 - Marcus Blankenship Introduction Twitter Blog 03:09 - Panelist Worst Boss Experiences 13:06 - Developer Anarchy vs Having a Hierarchy SE-Radio Episode 253: Fred George on Developer Anarchy The Valve Playbook 20:57 - Transitioning Managers Impostor Syndrome 26:05 - Manager Influence 28:33 - Management vs Leadership Leader-Member Exchange Theory 34:37 - Interpersonal Relationships and Happiness 38:24 - What kind of feedback do managers want from their employees? Timesheets 46:17 - Am I manager material? Am I ready to go into management? 48:06 - Following a Technical Track 51:55 - Why would anyone ever want to be a department manager? Picks A Plain English Guide to JavaScript Prototypes (Aimee) Oatmega (Aimee) Luck by Tom Vek (Jamison) The 27 Challenges Managers Face: Step-by-Step Solutions to (Nearly) All of Your Management Problems by Bruce Tulgan (Marcus) React Rally Call for Proposals (Jamison) React Rally (Jamison) Multipliers: How the Best Leaders Make Everyone Smarter by Liz Wiseman (Dave) Soft Skills Engineering Podcast (Dave)

02:30 - Ben Briggs Twitter GitHub Blog cssnano 03:03 - PostCSS cssnext Postcss.parts 07:16 - What problems was PostCSS designed to solve for developers? rework autoprefixer 09:46 - Using PostCSS vs Sass lost 14:02 - Using Future Features 16:28 - Tool Fatigue postcss.org 23:39 - When should people start thinking about using PostCSS? stylelint rtlcss postcss-colorblind 31:24 - Postprocessing midas 33:43 - Shipping Apps with Emojis? 36:21 - Where does PostCSS end and where does css-modules begin? Picks Chet Corcos: Functional Programming for JavaScript People (Aimee) Operation Code Scholarship (Aimee) Web Platform Daily Digest (Ben) Cadbury Caramel Eggs (Joe) Hello World Podcast (Joe) React Rally (Dave)

02:30 - Ben Briggs Twitter GitHub Blog cssnano 03:03 - PostCSS cssnext Postcss.parts 07:16 - What problems was PostCSS designed to solve for developers? rework autoprefixer 09:46 - Using PostCSS vs Sass lost 14:02 - Using Future Features 16:28 - Tool Fatigue postcss.org 23:39 - When should people start thinking about using PostCSS? stylelint rtlcss postcss-colorblind 31:24 - Postprocessing midas 33:43 - Shipping Apps with Emojis? 36:21 - Where does PostCSS end and where does css-modules begin? Picks Chet Corcos: Functional Programming for JavaScript People (Aimee) Operation Code Scholarship (Aimee) Web Platform Daily Digest (Ben) Cadbury Caramel Eggs (Joe) Hello World Podcast (Joe) React Rally (Dave)

02:30 - Ben Briggs Twitter GitHub Blog cssnano 03:03 - PostCSS cssnext Postcss.parts 07:16 - What problems was PostCSS designed to solve for developers? rework autoprefixer 09:46 - Using PostCSS vs Sass lost 14:02 - Using Future Features 16:28 - Tool Fatigue postcss.org 23:39 - When should people start thinking about using PostCSS? stylelint rtlcss postcss-colorblind 31:24 - Postprocessing midas 33:43 - Shipping Apps with Emojis? 36:21 - Where does PostCSS end and where does css-modules begin? Picks Chet Corcos: Functional Programming for JavaScript People (Aimee) Operation Code Scholarship (Aimee) Web Platform Daily Digest (Ben) Cadbury Caramel Eggs (Joe) Hello World Podcast (Joe) React Rally (Dave)

02:52 - What’s up Merrick Christensen? Twitter GitHub Blog 03:43 - Favorite Episodes Episode #124: The Origin of Javascript with Brendan Eich Episode #037: Specialized vs Monolithic with James Halliday and Tom Dale   Episode #071: JavaScript Strategies at Microsoft with Scott Hanselman Episode #044: Book Club: Effective JavaScript with David Herman Episode #161: Rust with David Herman Episode #008: V8 and Dart with Lars Bak and Kasper Lund Episode #175: Elm with Evan Czaplicki and Richard Feldman Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki Adventures in Angular Episode #80: Aurelia with Rob Eisenberg 08:58 - How have ideas about JavaScript changed since being a panelist on the show? jQuery adding 2 numbers from input fields 15:01 - Off the Air Experiences         20:23 - Work/Job Changes Kuali 23:54 - JS Jabber = Newbie-Friendly 24:58 - Work/Job Changes (Cont’d) Daplie All Remote Conferences 35:25 - Organizing Conferences and Name Recognition Dave Smith: How React literally waters my lawn from React Rally 40:55 - Spinoff Shows Adventures in Angular Web Security Warriors React Native Radio JavaScript Air Angular Air 45:08 - Podcast Administration and Organization; Episode Release Timeline Mandy Upwork Picks JavaScript Jabber (Joe) The Harry Potter Audiobooks (Joe) Calamity by Brandon Sanderson (Joe) AngularConnect (Joe) Dennis Overbye: Gravitational Waves Detected, Confirming Einstein’s Theory (AJ) The God Who Weeps: How Mormonism Makes Sense of Life by Terryl Givens (AJ) Julia Evans: Have high expectations for your computers (Jamison) January 28th GitHub Incident Report (Aimee) Denzel Brade: Front End Dev — Running before you can walk (Aimee) Captivating Revised and Updated: Unveiling the Mystery of a Woman's Soul by John Eldredge and Stasi Eldredge (Aimee) drone (Merrick) Haskell Book (Merrick) Amazon Prime (Chuck) nexxt Maine Wall Shelf/Floating Ledge (Chuck) Read the presidential candidate’s books (Chuck)

02:52 - What’s up Merrick Christensen? Twitter GitHub Blog 03:43 - Favorite Episodes Episode #124: The Origin of Javascript with Brendan Eich Episode #037: Specialized vs Monolithic with James Halliday and Tom Dale   Episode #071: JavaScript Strategies at Microsoft with Scott Hanselman Episode #044: Book Club: Effective JavaScript with David Herman Episode #161: Rust with David Herman Episode #008: V8 and Dart with Lars Bak and Kasper Lund Episode #175: Elm with Evan Czaplicki and Richard Feldman Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki Adventures in Angular Episode #80: Aurelia with Rob Eisenberg 08:58 - How have ideas about JavaScript changed since being a panelist on the show? jQuery adding 2 numbers from input fields 15:01 - Off the Air Experiences         20:23 - Work/Job Changes Kuali 23:54 - JS Jabber = Newbie-Friendly 24:58 - Work/Job Changes (Cont’d) Daplie All Remote Conferences 35:25 - Organizing Conferences and Name Recognition Dave Smith: How React literally waters my lawn from React Rally 40:55 - Spinoff Shows Adventures in Angular Web Security Warriors React Native Radio JavaScript Air Angular Air 45:08 - Podcast Administration and Organization; Episode Release Timeline Mandy Upwork Picks JavaScript Jabber (Joe) The Harry Potter Audiobooks (Joe) Calamity by Brandon Sanderson (Joe) AngularConnect (Joe) Dennis Overbye: Gravitational Waves Detected, Confirming Einstein’s Theory (AJ) The God Who Weeps: How Mormonism Makes Sense of Life by Terryl Givens (AJ) Julia Evans: Have high expectations for your computers (Jamison) January 28th GitHub Incident Report (Aimee) Denzel Brade: Front End Dev — Running before you can walk (Aimee) Captivating Revised and Updated: Unveiling the Mystery of a Woman's Soul by John Eldredge and Stasi Eldredge (Aimee) drone (Merrick) Haskell Book (Merrick) Amazon Prime (Chuck) nexxt Maine Wall Shelf/Floating Ledge (Chuck) Read the presidential candidate’s books (Chuck)

02:52 - What’s up Merrick Christensen? Twitter GitHub Blog 03:43 - Favorite Episodes Episode #124: The Origin of Javascript with Brendan Eich Episode #037: Specialized vs Monolithic with James Halliday and Tom Dale   Episode #071: JavaScript Strategies at Microsoft with Scott Hanselman Episode #044: Book Club: Effective JavaScript with David Herman Episode #161: Rust with David Herman Episode #008: V8 and Dart with Lars Bak and Kasper Lund Episode #175: Elm with Evan Czaplicki and Richard Feldman Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki Adventures in Angular Episode #80: Aurelia with Rob Eisenberg 08:58 - How have ideas about JavaScript changed since being a panelist on the show? jQuery adding 2 numbers from input fields 15:01 - Off the Air Experiences         20:23 - Work/Job Changes Kuali 23:54 - JS Jabber = Newbie-Friendly 24:58 - Work/Job Changes (Cont’d) Daplie All Remote Conferences 35:25 - Organizing Conferences and Name Recognition Dave Smith: How React literally waters my lawn from React Rally 40:55 - Spinoff Shows Adventures in Angular Web Security Warriors React Native Radio JavaScript Air Angular Air 45:08 - Podcast Administration and Organization; Episode Release Timeline Mandy Upwork Picks JavaScript Jabber (Joe) The Harry Potter Audiobooks (Joe) Calamity by Brandon Sanderson (Joe) AngularConnect (Joe) Dennis Overbye: Gravitational Waves Detected, Confirming Einstein’s Theory (AJ) The God Who Weeps: How Mormonism Makes Sense of Life by Terryl Givens (AJ) Julia Evans: Have high expectations for your computers (Jamison) January 28th GitHub Incident Report (Aimee) Denzel Brade: Front End Dev — Running before you can walk (Aimee) Captivating Revised and Updated: Unveiling the Mystery of a Woman's Soul by John Eldredge and Stasi Eldredge (Aimee) drone (Merrick) Haskell Book (Merrick) Amazon Prime (Chuck) nexxt Maine Wall Shelf/Floating Ledge (Chuck) Read the presidential candidate’s books (Chuck)

02:43 - Oren Rubin Introduction Twitter GitHub LinkedIn TESTIM.IO 05:43 - Testing Unit Testing End-to-end Testing Acceptance Testing Functional Testing Performance Testing 18:18 - Page Object(s) Locators 27:10 - Protractor & Selenium Zombie 32:06 - Checking UI (Screenshots) 37:04 - End-to-end > Full Coverage? 40:03 - When should you start testing? 42:21 - Cucumber 45:39 - Debugging Picks Paul Ford: 10 Timeframes (Jamison) Kishi Bashi - “In Fantasia” (Jamison) Matt Zabriskie (Jamison) http-backend-proxy (Aimee) repl.it (Aimee) React.js Training with Michael Jackson and Ryan Florence (Joe) React Rally (Joe) AngularConnect (Joe) ng-conf (Joe) Ruby Remote Conf Videos (Chuck) Angular Remote Conf (Chuck) 15 Minute Podcast Listener chat with Charles Wood (Chuck) Dave Haeffner: Elemental Selenium (Oren) CSS Secrets by Lea Verou (Oren) Cloudinary (Oren)

02:43 - Oren Rubin Introduction Twitter GitHub LinkedIn TESTIM.IO 05:43 - Testing Unit Testing End-to-end Testing Acceptance Testing Functional Testing Performance Testing 18:18 - Page Object(s) Locators 27:10 - Protractor & Selenium Zombie 32:06 - Checking UI (Screenshots) 37:04 - End-to-end > Full Coverage? 40:03 - When should you start testing? 42:21 - Cucumber 45:39 - Debugging Picks Paul Ford: 10 Timeframes (Jamison) Kishi Bashi - “In Fantasia” (Jamison) Matt Zabriskie (Jamison) http-backend-proxy (Aimee) repl.it (Aimee) React.js Training with Michael Jackson and Ryan Florence (Joe) React Rally (Joe) AngularConnect (Joe) ng-conf (Joe) Ruby Remote Conf Videos (Chuck) Angular Remote Conf (Chuck) 15 Minute Podcast Listener chat with Charles Wood (Chuck) Dave Haeffner: Elemental Selenium (Oren) CSS Secrets by Lea Verou (Oren) Cloudinary (Oren)

02:43 - Oren Rubin Introduction Twitter GitHub LinkedIn TESTIM.IO 05:43 - Testing Unit Testing End-to-end Testing Acceptance Testing Functional Testing Performance Testing 18:18 - Page Object(s) Locators 27:10 - Protractor & Selenium Zombie 32:06 - Checking UI (Screenshots) 37:04 - End-to-end > Full Coverage? 40:03 - When should you start testing? 42:21 - Cucumber 45:39 - Debugging Picks Paul Ford: 10 Timeframes (Jamison) Kishi Bashi - “In Fantasia” (Jamison) Matt Zabriskie (Jamison) http-backend-proxy (Aimee) repl.it (Aimee) React.js Training with Michael Jackson and Ryan Florence (Joe) React Rally (Joe) AngularConnect (Joe) ng-conf (Joe) Ruby Remote Conf Videos (Chuck) Angular Remote Conf (Chuck) 15 Minute Podcast Listener chat with Charles Wood (Chuck) Dave Haeffner: Elemental Selenium (Oren) CSS Secrets by Lea Verou (Oren) Cloudinary (Oren)

02:05 - André Arko Introduction + Bundler Twitter GitHub Blog 04:28 - Ruby Together Trade Association ​Brian Mikulencak 10:52 - Ruby Central 501(c) Organization 14:23 - Ruby Together Timeline 16:01 - Open Source People Depend on vs Open Source as a Hobby 17:03 - Corporate Member Rights / The Structure of Ruby Together Monthly Contributions 20:19 - How the Board Makes Decisions Slack 23:00 - Membership Numbers 24:03 - How Voting Works 26:58 - How much work is involved in maintaining these projects? 30:08 - How is work doled out? Eric Hodel (@drbrain) Aaron Patterson (@tenderlove) 33:41 - Future Plans and Community Impact Fastly 40:28 - Getting People Involved 43:34 - Lessons Learned 45:23 - Code of Conducts / Community Values Picks Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André) The Protomen (André) Bubblesort Zines (André) Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron) F.lux (Saron) Hue (Saron) Madison Ruby Day 1 (Coraline) Madison Ruby Day 2 (Coraline) Survive Escape From Atlantis 30th Anniversary Edition (Coraline) Angular Remote Conf (Chuck) React Rally (Chuck) Alcatraz Books by Brandon Sanderson (Chuck)

02:05 - André Arko Introduction + Bundler Twitter GitHub Blog 04:28 - Ruby Together Trade Association ​Brian Mikulencak 10:52 - Ruby Central 501(c) Organization 14:23 - Ruby Together Timeline 16:01 - Open Source People Depend on vs Open Source as a Hobby 17:03 - Corporate Member Rights / The Structure of Ruby Together Monthly Contributions 20:19 - How the Board Makes Decisions Slack 23:00 - Membership Numbers 24:03 - How Voting Works 26:58 - How much work is involved in maintaining these projects? 30:08 - How is work doled out? Eric Hodel (@drbrain) Aaron Patterson (@tenderlove) 33:41 - Future Plans and Community Impact Fastly 40:28 - Getting People Involved 43:34 - Lessons Learned 45:23 - Code of Conducts / Community Values Picks Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André) The Protomen (André) Bubblesort Zines (André) Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron) F.lux (Saron) Hue (Saron) Madison Ruby Day 1 (Coraline) Madison Ruby Day 2 (Coraline) Survive Escape From Atlantis 30th Anniversary Edition (Coraline) Angular Remote Conf (Chuck) React Rally (Chuck) Alcatraz Books by Brandon Sanderson (Chuck)

02:05 - André Arko Introduction + Bundler Twitter GitHub Blog 04:28 - Ruby Together Trade Association ​Brian Mikulencak 10:52 - Ruby Central 501(c) Organization 14:23 - Ruby Together Timeline 16:01 - Open Source People Depend on vs Open Source as a Hobby 17:03 - Corporate Member Rights / The Structure of Ruby Together Monthly Contributions 20:19 - How the Board Makes Decisions Slack 23:00 - Membership Numbers 24:03 - How Voting Works 26:58 - How much work is involved in maintaining these projects? 30:08 - How is work doled out? Eric Hodel (@drbrain) Aaron Patterson (@tenderlove) 33:41 - Future Plans and Community Impact Fastly 40:28 - Getting People Involved 43:34 - Lessons Learned 45:23 - Code of Conducts / Community Values Picks Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André) The Protomen (André) Bubblesort Zines (André) Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron) F.lux (Saron) Hue (Saron) Madison Ruby Day 1 (Coraline) Madison Ruby Day 2 (Coraline) Survive Escape From Atlantis 30th Anniversary Edition (Coraline) Angular Remote Conf (Chuck) React Rally (Chuck) Alcatraz Books by Brandon Sanderson (Chuck)

Check out Angular Remote Conf!   02:22 - Jason Rhodes Introduction Twitter GitHub Blog SparkPost NodeSchool @nodeschool GitHub: NodeSchool charmCityJS @charmcityjs 03:46 - NodeSchool Jason Rhodes: A Story About NodeSchool and Community Building at CascadiaJS 2014 Jason Rhodes: NodeSchool Trying Node AND Contributing @ Empire Node 2014 06:05 - “Workshopper(s)” 07:13 - How Meetups Run (Format), Target Audience 11:09 - Pair Programming and Peer Learning 14:34 - Starting a NodeSchool Chapter 15:53 - Implementing Diversity 18:07 - Mentoring and Mentorship 20:49 - Time Commitment and Effort 24:02 - Appealing to All Experience Levels of Attendees 26:48 - The NodeSchool Community 30:45 - Being a Member of an Open Source Community Picks Better Off Ted (Joe) Cat Exercise Wheel (Aimee) That Conference (Joe) primitive.io (Joe) React Rally (Aimee) Falcor YouTube Playlist (Aimee) javascriptjabber.com/15minutes (Chuck) Entreprogrammers Retreat 2015  (Chuck) Love Letter (Jason) charmCityJS (Jason) Mad Max: Fury Road (Jason)

Check out Angular Remote Conf!   02:22 - Jason Rhodes Introduction Twitter GitHub Blog SparkPost NodeSchool @nodeschool GitHub: NodeSchool charmCityJS @charmcityjs 03:46 - NodeSchool Jason Rhodes: A Story About NodeSchool and Community Building at CascadiaJS 2014 Jason Rhodes: NodeSchool Trying Node AND Contributing @ Empire Node 2014 06:05 - “Workshopper(s)” 07:13 - How Meetups Run (Format), Target Audience 11:09 - Pair Programming and Peer Learning 14:34 - Starting a NodeSchool Chapter 15:53 - Implementing Diversity 18:07 - Mentoring and Mentorship 20:49 - Time Commitment and Effort 24:02 - Appealing to All Experience Levels of Attendees 26:48 - The NodeSchool Community 30:45 - Being a Member of an Open Source Community Picks Better Off Ted (Joe) Cat Exercise Wheel (Aimee) That Conference (Joe) primitive.io (Joe) React Rally (Aimee) Falcor YouTube Playlist (Aimee) javascriptjabber.com/15minutes (Chuck) Entreprogrammers Retreat 2015  (Chuck) Love Letter (Jason) charmCityJS (Jason) Mad Max: Fury Road (Jason)

Check out Angular Remote Conf!   02:22 - Jason Rhodes Introduction Twitter GitHub Blog SparkPost NodeSchool @nodeschool GitHub: NodeSchool charmCityJS @charmcityjs 03:46 - NodeSchool Jason Rhodes: A Story About NodeSchool and Community Building at CascadiaJS 2014 Jason Rhodes: NodeSchool Trying Node AND Contributing @ Empire Node 2014 06:05 - “Workshopper(s)” 07:13 - How Meetups Run (Format), Target Audience 11:09 - Pair Programming and Peer Learning 14:34 - Starting a NodeSchool Chapter 15:53 - Implementing Diversity 18:07 - Mentoring and Mentorship 20:49 - Time Commitment and Effort 24:02 - Appealing to All Experience Levels of Attendees 26:48 - The NodeSchool Community 30:45 - Being a Member of an Open Source Community Picks Better Off Ted (Joe) Cat Exercise Wheel (Aimee) That Conference (Joe) primitive.io (Joe) React Rally (Aimee) Falcor YouTube Playlist (Aimee) javascriptjabber.com/15minutes (Chuck) Entreprogrammers Retreat 2015  (Chuck) Love Letter (Jason) charmCityJS (Jason) Mad Max: Fury Road (Jason)

02:40 - Justin Collins Introduction Twitter GitHub Blog Brakeman @brakeman SurveyMonkey Brakeman Pro @brakemanpro 03:40 - Brakeman & Static Analysis 04:02 - Common Security Vulnerabilities (and Definitions) Cross-site Scripting SQL Injection     rails-sqli.org Mass Assignment Open Redirects 08:57 - The Inspiration for Brakeman 09:47 - Getting Brakeman Working (Process) 10:41 - Learning About Security The Rails Cheat Sheets The Open Web Application Security Project (OWASP) The OWASP Top Ten     13:01 - Security and The Rails Core Team Justin Collins: The World of Ruby on Rails Security @ RailsConf 2015 15:19 - Should Brakeman be integrated into Rails? 16:29 - Running Brakeman On Your CI Machine guard-brakeman 17:43 - Are there specific types of vulnerabilities that are hard to find with static analysis? 19:18 - Rails Engines 20:56 - When building an app, is security something you should focus on from the get-go? Where should you get started? The OWASP Top Ten 25:32 - Code Schools Teaching Security 26:17 - Translating Lessons Learned Into Brakeman 27:24 - Handling Security and Data Breaches Charlie Miller 32:28 - Crowdsourcing Security (Security in Open Source) Terri Oda: Bringing Security to Your Open Source Project 34:54 - The Technical Side of Brakeman and Static Analysis Tools Identifying a Dangerous Value 37:34 - Data Tracing, Limited Data Flow Analysis 40:52 - Future Brakeman Features 43:29 - Supporting and Contributing to Brakeman 48:23 - PhDs Picks "Why didn't you [just]..." and "Did you consider..." Parley Thread (Avdi) Object Thinking (Developer Reference) by David West (Avdi) Web Design - The First 100 Years (Avdi) Brighton Ruby Conference (Avdi) Email (Avdi) The Twitter Mute Button (Avdi) git - the simple guide (Saron) I Love My Campus (Saron) LoneStarRuby (Saron) React Rally (Jessica) Livecoding.tv (Jessica) Remembering the Apollo 11 Moon Landing With the Woman Who Made It Happen (Coraline) Showgoers (Coraline) AngularJS Kurs (Chuck) Hire Thom Parkin! (Chuck) RethinkDB (Justin) 
Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age by Michael A. Hiltzik (Justin) The Search for General Tso (Justin)

02:40 - Justin Collins Introduction Twitter GitHub Blog Brakeman @brakeman SurveyMonkey Brakeman Pro @brakemanpro 03:40 - Brakeman & Static Analysis 04:02 - Common Security Vulnerabilities (and Definitions) Cross-site Scripting SQL Injection     rails-sqli.org Mass Assignment Open Redirects 08:57 - The Inspiration for Brakeman 09:47 - Getting Brakeman Working (Process) 10:41 - Learning About Security The Rails Cheat Sheets The Open Web Application Security Project (OWASP) The OWASP Top Ten     13:01 - Security and The Rails Core Team Justin Collins: The World of Ruby on Rails Security @ RailsConf 2015 15:19 - Should Brakeman be integrated into Rails? 16:29 - Running Brakeman On Your CI Machine guard-brakeman 17:43 - Are there specific types of vulnerabilities that are hard to find with static analysis? 19:18 - Rails Engines 20:56 - When building an app, is security something you should focus on from the get-go? Where should you get started? The OWASP Top Ten 25:32 - Code Schools Teaching Security 26:17 - Translating Lessons Learned Into Brakeman 27:24 - Handling Security and Data Breaches Charlie Miller 32:28 - Crowdsourcing Security (Security in Open Source) Terri Oda: Bringing Security to Your Open Source Project 34:54 - The Technical Side of Brakeman and Static Analysis Tools Identifying a Dangerous Value 37:34 - Data Tracing, Limited Data Flow Analysis 40:52 - Future Brakeman Features 43:29 - Supporting and Contributing to Brakeman 48:23 - PhDs Picks "Why didn't you [just]..." and "Did you consider..." Parley Thread (Avdi) Object Thinking (Developer Reference) by David West (Avdi) Web Design - The First 100 Years (Avdi) Brighton Ruby Conference (Avdi) Email (Avdi) The Twitter Mute Button (Avdi) git - the simple guide (Saron) I Love My Campus (Saron) LoneStarRuby (Saron) React Rally (Jessica) Livecoding.tv (Jessica) Remembering the Apollo 11 Moon Landing With the Woman Who Made It Happen (Coraline) Showgoers (Coraline) AngularJS Kurs (Chuck) Hire Thom Parkin! (Chuck) RethinkDB (Justin) 
Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age by Michael A. Hiltzik (Justin) The Search for General Tso (Justin)

02:28 - Sebastian McKenzie Introduction Twitter GitHub Blog 02:53 - Babel (Pronunciation Clarification) 05:56 - History Learn ES2015 - Babel 09:14 - The State of Babel 09:59 - Babel and the TC39 Process 11:54 - Features That Can’t Be Transpiled Weak Maps and Proxies     13:45 - Readability and Performance Output Traceur 18:12 - Plugin Architecture 19:58 - ES6/2015 Feature Implementation Blockscoping Labels Exceptions Destructuring 25:49 - The Birth of Babel 26:45 - Babel vs Traceur 28:08 - Future Babel Features Code Optimization Minification Linting 30:15 - The Status of ES2015 and ES2016 31:01 - Browser Support 35:03 - Marketing 35:59 - TypeScript 37:24 - Babel Development and Labor Picks Primitive.io (Joe) Armada: The Novel by Ernest Cline (Joe) How to Win Friends & Influence People by Dale Carnegie (AJ) Web Security Warriors Podcast (AJ) Nodevember (Aimee) The Hitchhiker's Guide to the Galaxy by Douglas Adams (Dave) Yellowstone National Park (Dave) React Rally (Dave) Iterativ: AngularJS Kurs (Chuck) Hire Thom Parkin! (Chuck) The Martian by Andy Weir (Sebastian) Five Guys Burgers and Fries (Sebastian)

02:28 - Sebastian McKenzie Introduction Twitter GitHub Blog 02:53 - Babel (Pronunciation Clarification) 05:56 - History Learn ES2015 - Babel 09:14 - The State of Babel 09:59 - Babel and the TC39 Process 11:54 - Features That Can’t Be Transpiled Weak Maps and Proxies     13:45 - Readability and Performance Output Traceur 18:12 - Plugin Architecture 19:58 - ES6/2015 Feature Implementation Blockscoping Labels Exceptions Destructuring 25:49 - The Birth of Babel 26:45 - Babel vs Traceur 28:08 - Future Babel Features Code Optimization Minification Linting 30:15 - The Status of ES2015 and ES2016 31:01 - Browser Support 35:03 - Marketing 35:59 - TypeScript 37:24 - Babel Development and Labor Picks Primitive.io (Joe) Armada: The Novel by Ernest Cline (Joe) How to Win Friends & Influence People by Dale Carnegie (AJ) Web Security Warriors Podcast (AJ) Nodevember (Aimee) The Hitchhiker's Guide to the Galaxy by Douglas Adams (Dave) Yellowstone National Park (Dave) React Rally (Dave) Iterativ: AngularJS Kurs (Chuck) Hire Thom Parkin! (Chuck) The Martian by Andy Weir (Sebastian) Five Guys Burgers and Fries (Sebastian)