Podcasts about nodevember

We're talking [Nodevember](https://nodevember.io) in this episode! Jonas and Luca explain what Nodevember is, how it started, and how you can be a part of it yourself. These two are great fun to listen to... and while you listen, you can make your own burst of node-y goodness.

Podcast Description Kim is taking some much needed time off, so enjoy this keynote presentation from the 2017 Nodevember conference. Since technology now literately touches almost everyone and it is no longer the playground of just a few, it isn’t economically prudent to build products and services that don’t reflect the needs and desires of large portions of the population. So it makes sense that technology communities are now focused on attracting a more inclusive and diverse membership. But how do you turn the focus into a successful plan of action? Community Engineering, which is an approach that can be used once the decision has been made pursue these kinds of community growth initiatives. Community Engineering - Is the intentional and skillful effort of creating environments which support the sharing of common attitudes, interests, and goals in order to grow a more diverse and inclusive technology community. Community -  a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals. Engineering - to arrange, manage, or carry through by skillful or artful execution Additional Resources ​Presentation Slides Presentation Video Transcription Coming Soon! Twitter What is Community Engineering? Become a #causeascene Podcast sponsor because disruption and innovation are products of individuals who take bold steps in order to shift the collective and challenge the status quo. Learn more > All music for the #causeascene podcast is composed and produced by Chaos, Chao Pack, and Listen on SoundCloud. Listen to more great #causeascene podcasts full podcast list >

We are at the half century mark, episode 50 is with an artist I am a big admirer of and the coalition Nodevember winner Doru Bogdan. We got into how he fell in love with Substance Designer, the struggles job rejections and how he found parallels between Zbrush and Designer! . Doru’s ArtStation ⯈ https://www.artstation.com/sublime . Listen on Spotify ⯈ https://open.spotify.com/show/7spDMpMZJ9dr3Ziu8bRwCA Listen on SoundCloud ⯈ https://soundcloud.com/gamedevdiscussion Listen on iTunes ⯈ https://podcasts.apple.com/gb/podcast/game-dev-discussion/id1459400002 Listen on YouTube ⯈ https://www.youtube.com/channel/UCKfTBvcsO9Kw0b5EVuf4CJQ . Support the podcast on Patreon ⯈ https://www.patreon.com/GDD_Podcast

In this episode, Robert, Charles, and Wil talk about the whys and hows of accessibility, as well as what makes single page applications special, why they are they harder for accessibility, and frameworks that can do this for you. Resources: #SkyQ app on #iOS from a #VoiceOver user's Perspective Rob's Routing Doc Wil's PR Single Page Apps routers are broken Greater Than Code Episode #92: A11y Ally with Rob DeLuca This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: ROBERT: Hello everyone. Welcome to The Frontside Podcast. This is Episode 111. I'm Robert DeLuca, a software developer here at the Frontside and I'll be your episode host. Today, we're going to be discussing accessibility in single page apps. With me as co-hosts are Charles Lowell. Hey, Charles. CHARLES: What is up Robert? ROBERT: And Wil Wilsman. Hey, Wil. WIL: Yo, yo, yo, yo. ROBERT: Sounds like we're ready to drop a disc track. We're not going to be dissing anybody here. We're going to be talking about helpful things with accessibility in single page apps. Before we get into the nitty-gritty of accessibility in single page apps because we're getting into some deep stuff, I think I want to cover a lot of 'how' because I know accessibility things are usually about why you should be doing it and then they touch on things like, "You should be using alt attributes for your images," but for single page apps, I think we need to go further. CHARLES: It always ends up like, "Then draw the rest of the accessibility owl." ROBERT: Yeah, here's your two circles and the alt-tags are your circles and then the rest of the freaking owl is focus management and everything else that comes with it. Before we get there, what is accessibility? I guess, if we trim the giant umbrella down a little bit from everything that is accessibility that can be physical space things, like wheelchair accessible ramps or things like that, what about just technology? WIL: People need assistive tech to interact with technology such as switches or keyboards and obviously screen reader is a big one but when it comes to the software itself, you could even talk about colors and people who are color blind, so red might not be red to everybody. ROBERT: Speaking from experience there? WIL: Yeah. I'm colorblind. Red is brown to me. CHARLES: Things like hearing and all of it, right? It really is like just designing it in such a way that it can be used by as many people as possible. ROBERT: Right. WIL: And that includes your mom who may not be the best with technology but she still needs to pay your bills online or something. ROBERT: Exactly, yeah and in for context to listeners that might not know, my mom is 100% blind, so it's kind of where it comes from. CHARLES: But my mom is not but she has all kinds of problems. WIL: Yeah, same with my mom. CHARLES: That also falls under the category of accessibility, right? ROBERT: Absolutely. CHARLES: Right, accounting for age and culture. ROBERT: We're blending into the why of accessibility, which is perfect. One of the things that it's such a good segue because what people are starting to realize and I think why accessibility is really starting to catch wind and get some traction is because a lot of people that grew up in the technology age were open in using technology a lot. Our parents probably did not use technology heavily. That's definitely the case for my dad. He still has a flip phone and he says, he's a low tech man living in a high tech world and just refuses to pick up technology but those are the people that just didn't use technology. But now we have a lot of people that grew up with technology and use a lot and they're aging into more disabilities and they're going to need that accessibility, which I think is really interesting to think about because that's a lot of buying power if you're just going to start moving in that needs in accessibility, right? CHARLES: That's true. I know I may need glasses pretty soon, so colors and fonts were going to be heck a lot more to me in the next five years than they have over the last 20. ROBERT: Yup, exactly and that's going to be huge for that and that's one piece of the why, so what are the other reasons that you'd pick up accessibility other than people saying that it's morally correct. I don't like starting off conversations for accessibility because it's the thing that you should be doing. WIL: I think it goes even to my user experience like power users that don't like using the mice or mouse. That's me. I really prefer to just use my keyboard for everything. When the new Firefox browser came out and I couldn't navigate through the menus the way I was used to, I went back to Chrome. ROBERT: That's interesting. CHARLES: I still have not found a good workflow for navigating tabs with the keyboard without just kind of twisting my wrist all out of shape. You have to share that with me but again, that's another thing. That's an impediment that sits between me and the application, that actually -- ROBERT: Which is really interesting, you're getting into a keyboard navigation and focus management, which is really the crux of accessibility for screen reader users and switch users. CHARLES: What I'm hearing is that in this case, including good keyboard and focus management in your application, e.g. making it accessible to screen readers, you at the same time, enabling your power users. I think a great point is that by introducing these very low friction workflows, you're actually going to be enabling other parts of your customer base and not just catering to one, that there are ripple effects throughout your system. ROBERT: It may set it for everyone. WIL: Yeah, not only people who need it but people who don't know they need it. ROBERT: Yes, exactly. Think about the WCAG spec as user experience guidelines. They're not telling you how to implement a thing specifically for a screen reader. They're telling you how to implement it in a way that works for everyone, regardless of what ailment they have. It could be a temporary ailment. It could be a permanent ailment, where they have to use a screen reader or any kind of ailment that you can think of. They're not considering just one use case. It's a broad thing that shows how you can make your application better for everyone. I think that's a better way to look at the WCAG spec than I need to read through this and make sure that this auto complete works for a screen reader. If you look at the guidelines, they're not telling you just first screen reader. They're telling you how to make it work for a switch, someone who is colorblind or who is using a dictation software. I kind of tend to look at that as UX guideline, which really helps me build a better app overall because when you nail down that user flow, everyone benefits from it because it's pretty well thought out at that point. CHARLES: I like that too and I think that thinking of it as user experience and making sure that you have a complete user experience is a good way to think about it because it kind of separates the concerns of, "I've got HTML but is my application really HTML or is it a set of workflows and the data over which those workflows operate?" It really forces you to think my application is not a set of React opponents or web components or Ember components or what have you but really, there's a deep structure to it and it makes you kind of shine a light on that deep structure and try to map its surface. Then, if you really, really know it and you capture it, then you can represent it in any medium. I think it's just a win not just for one niche group of users but also for all of our users and then also for your future users that you don't have because your application is designed better and is going to work. Who knows? Maybe there's some new interface or some new medium, some new device that comes out that hasn't even been invented yet. But if you really have a strong internal representation of what your application is, you're going to be able to be the first to move to that market. ROBERT: Right and like I said earlier, people are starting to aid in the needing accessibility thing. If you need a dollar to justify it, that's going to be a big reason coming up. As a part of the new WCAG 2.1 spec, there is a zoom. I forget what this access criteria number is but the new criteria says your app basically needs to be responsive. That kind of maps directly to what you said earlier, Charles which is like you're going to need glasses soon and fonts and being able to zoom. It's going to be really important. We see that just pop up everywhere. To give a counter example of not just for accessibility like you need it for glasses but the other side of that could be like when we give demos on low resolution projectors or screencast or anything, when we zoom the screen, the apps just still be usable and you should still be able to demo it and that's just something that you have both sides to that, where accessibility kind of works out for everybody. People on the call probably don't need glasses but to see that tiny screen that's being shared, you should be able to assume that. CHARLES: Right. I'm just kind of restating what you said but I want to make sure to call it out explicitly because it was a definitely an aha moment for me, that you basically if you build yourself an accessible website, you build it so that it works on projectors and mobile devices too, so you kind of killed two birds with one stone and you don't have to make a special effort because zooming in the screen is tantamount to viewing it on a phone or viewing it on a tablet. WIL: Yeah, we mentioned it earlier about accessibility and physical space and one of those things is being able to access something from anywhere no matter the device that person is using. ROBERT: Yes. That's a lot of the 'why' of accessibility and I think we did a pretty good job of staying away from the more argument because morally we don't know if it's the right thing to do but a lot of the times it's not in front of you, it's hard to do and I want to make sure that you don't feel bad if you're not building accessibility in your apps. It's not easy. I don't sort of like people get up and say that, "Accessibility is easy. Just do this," because it's not -- WIL: If it was easy, everybody would do it. ROBERT: Exactly. I always come back to accessibility being just like UX -- user experience -- because if it were easy, everybody would have a really great user experience too. It's a hard thing to boil down and to simplify it, right? CHARLES: Right and like every other aspect, the kind of nonfunctional requirement, I say nonfunctional requirement that's a little bit of a contradiction terms but it becomes very hard if you haven't done it from the beginning. But if you didn't start with an accessible app, you weren't thinking about that or you inherited the app or it just wasn't on your radar for whatever reason. If you got a codebase that's two years old, going back and trying to make it accessible, it was extremely hard. It's expensive, expensive, expense. WIL: Yeah, it's going to cost more in terms of money and time to added it after the fact. ROBERT: Exactly. I spent a year on helping on Visa Checkout and there were some accessibility considered in the designs but a lot of the time my feedback wasn't just like, "Yeah, sprinkle some ARIA attributes on there and you're good." It was like, "Do we really need a carousel here to represent your list of carts because it's really hard to navigate around that?" A lot of the times, it ends up boiling up to is this the best way we can represent this data? Is this the best way we can navigate and build this user flow? A lot of times -- CHARLES: And if the answer is no, it's so painful, right? ROBERT: Yeah, exactly, so all that work that was put into building that carousel and all the components that built that carousel together is thrown out because it's just not a pattern that should be used there. Doing after the fact is really hard and really expensive and usually ends up in refactoring anyways. CHARLES: I just want to point that out because a lot of people find themselves in that situation, where they're staring down at a pretty big cost. Now, the reasons why your app may not be accessible or many and good and you shouldn't feel bad, if you're finally in that situation. ROBERT: I gave a talk at Nodevember a couple of years ago called Accessibility Debt and it's just like any technical debt. Your apps going to have it. It's okay. Don't get beat up about it, especially if anybody is trying to beat you up over it, don't listen to them. It really is just like any other kind of technical form of technical debt. It's something that you'll have to deal with and it is just something you have to work through. It's not world ending. It's just another problem to work through. What are some things like everybody usually talks about like the things you can do, the basics for making your app more accessible like using all its attributes and instead of doing a div with an on-click handler, just use a button or don't overuse ARIA attributes. Are there any other things that I missed there like the basics of accessibility? WIL: The biggest is the HTML structure. Screen readers and other assistive tech were built with the standards in mind, so if you're doing nonstandard things like putting divs in H1 and adding ARIA attributes within there, you're not going to have a great time. ROBERT: Right or splattering ARIA roles all over the place, probably not a good idea. That will be harder to debug. Also fun fact, ARIA roles, while you can implement directly to the spec, you may still have bugs across the different screen reader combinations or assistive tech combinations, so that's fine. CHARLES: Keep it super simple is what I'm hearing, like use semantic markup. If you're going to introduce a custom button, still make sure that it's a button. ROBERT: Use the platform. CHARLES: Yeah, use the platform. Don't fight the platform. Probably the best example of that is people implementing their own select boxes. That's the classic example. ROBERT: Wil and I, our lives has centered around that for a little while. It's so true. Usually, it's the first thing people go to grab to reimplement because selects are just ugly. I think Firefox has the ability for you to style select options now like you can change the color and the font but you can't style that. The pop up that comes, usually that's the system dialogue, which a lot of designers don't really like. That's usually the first thing that people go to implement and that's usually actually the first thing that stop somebody from signing up. A lot of sign up forms that I see, if your date of birth is in a select format, that probably will hinder somebody that uses assistive tech from signing up. CHARLES: Yeah. You just basically bounced that entire person. The thing is people don't appreciate the cost. This gets into the whole concept of accessibility that is how much money would that person or those group of people have actually brought into your site versus the cost that you spent redoing that select box. You might be thinking, "It only took this developer actually two weeks," but when you actually look at the actual cost over the course of your application, you're not factoring that into the decision to go with custom select box. Just in our experience, it's just the truly low cost option per quality of experience, that tradeoff there is almost invariably going with platforms select, right? ROBERT: Yeah. Your secret sauce and the best UX that you're going to provide is not going to be nicely styled select box and seriously, a battle that I had to fight a lot was if you really want to implement a custom widget, decide if this is what you want to spend your time on because custom widgets aren't just quick and easy things you implement. You're not going to implement the select that's fully accessible across all the AT combos in a couple of days. CHARLES: It's a lot of work. ROBERT: Yeah. You're going to fall down on a huge rabbit hole. CHARLES: Yeah. It is just you're committing to that work over the lifetime of your application. ROBERT: Exactly, if you can maintain that now. If you implement custom check boxes and custom radios and custom input that of content edible for some reason, I think -- WIL: I think what I see is like custom date pickers -- ROBERT: Oh, I just had a rant about that. CHARLES: Date pickers are hard and there's not really a good option. You just have to open your eyes to the true cost. ROBERT: Right, exactly. That's what I always try to explain, just like you have ownership over this now and you now have to maintain this and you can't regress. CHARLES: Right and if you do regress, it's your neck that gets choked. ROBERT: Yes. A good way to put it. We've talked a lot about things that are just general accessibility but nothing specific to single page apps. I do want to say like a lot of other things that people recommend is like if you're using React, use like the JSX ES1 plugin to help you analyze if you're writing any JSX that might not be accessible or use like HTML_CodeSniffer or aXe to statically analyze the DOM that you have. Those tools are great. I'd see a lot of people [inaudible] those things as like, "Look, this automated checkers says I'm inaccessible so I'm inaccessible," and that's not the case, especially in a single page apps. You can have 100% passing automated checkers but your app also could be 100% broken and why is that? WIL: I don't know. ROBERT: I'm wobbling the router question here. WIL: Yes. I guess that would just be due to routing. In single page applications, they handle their own routing, whereas static web sites and whatnot, the routing is handled despite URLs and the browser and reloading pages. ROBERT: Right. There are probably other major differences between single page apps but the biggest thing is the routing is managed by the client, the JavaScript and on a server-rendered page, you click a link, it's going to rerender the entire page for that next page and the screen reader and the browser know exactly what to do with that, to put the focus back to the top of the page and start working through the page for you. But with single page apps, you're just replacing a piece of the DOM and the screen reader has no idea of what's going on. An automated checker cannot check for this. They cannot tell you if your routes are accessible. The reason I'm bringing this up is because this has never talked about. I don't see in accessibility talks and this is the thing that actually is most broken and makes your app pretty much unusable to anybody that's using assistive tech. There's ways that people if they're savvy can navigate around it but if they don't know what's going on, they're going to think, "All right, I pressed this button and nothing happened, so I'm just going to leave now because it's not working." CHARLES: There's a great video that you point to me, I believe a guy from the UK who has recorded a bunch of his experiences using websites and apps -- ROBERT: Yes, I want to dig it up and put it in the show notes. CHARLES: Yeah. Those are great to watch because you'll really get it. ROBERT: Yeah and that's a really unique case because he's really savvy. I believe, I could be wrong but I think he might have said that he definitely work in tech somehow -- CHARLES: Right. He knows the workarounds and he knows these things but in some of the cases it's like, "If I didn't work in tech, there's no way that I would be able to use this website." ROBERT: Yeah. This is kind of the crux of like if you ever listen to anybody that is an accessibility consultant, they'll say, "You will never ever be able to automate accessibility," and this why I tie accessibility so much to user experience, would you ever have a user experience test that can tell you in a binary fashion? Yes or no, that your app has a great user experience? No, because it's pretty subjective. CHARLES: Of how does your users feel? right? ROBERT: Yeah. CHARLES: You can rate, "My users feel great." ROBERT: Accessibility is like that because there's a lot of context that you have to carry around. It's all about context. When I transition from this page, the next thing does the user have enough context of where they're coming from to where they're going to be able to operate on that page. Is there enough information to achieve the task they want? That is pretty much the crux of why there is no binary yes or no for that because it's contextual. It varies from person to person but you do your best to make sure that that works and that you provide enough information to do something. That's kind of a single page app as a crux. This is why we have a philosophy of testing as a whole. We don't test components individually because again, you can make all of your components individually accessible there but as a whole, they might not work together because you're not providing enough context on an entire page. We did this in one of the apps that we work on, which is open source, so we can link to the PR that Wil wrote for this and I wrote an entire routing documentation around our philosophy and the different things that we tried. How did we manage the focus in that application? I'm kind of just going to lob it over to you Wil since you did the work. Do you want to give context of the holdings and how that all kind of came together? WIL: Yes. One of the features of the app is these panels. It's like this three panel system. When you click an item in a list, a third panel pops up and this goes back to the context thing where if you're using a keyboard, you can't see the screen. You click an item in a list, how do you know that third panel popped up? The solution isn't for a component. The component can't be responsible for this. The list can't focus the item. It opens or vice versa, so this is definitely an application concern, where we needed to check against the route and see whether or not, the pane is opening or was already open or wasn't open before and when this pane opens for the first time, it will just focus it and that gives a lot of the context that the user needs when they click it, like they click an item in the list, it focuses this third pane and they're on a third pane. ROBERT: Right. We didn't even just focus on the entire div. We focused on the heading of the thing that you selected. WIL: Yeah because focusing the div, it might read something off but not all the time. The main thing we're focusing on that third pane opens is the heading to let them know that the item you click, you are now on that page and reading that heading. This is the same thing that would happen if you loaded up that page statically and the screen readers would usually just focus on that first heading. ROBERT: Right. That helped a lot. For a little bit more context, the middle pane is like kind of a master detail thing going on here and in the middle pane there that we have, it's an infinite scrolling list. You have different things there and one of them is like a package. If you select the package and without the focus management and focusing on that heading, you would have to go through every single package that's in that list which could be a thousand of them before you actually get over to the pane that you just opened because source order. You have to go through each one of those. WIL: And it's the same thing is true for power users, not just screen readers. It's like if they want to use tab once that pane open, they have to tab through the entire list. ROBERT: Exactly. It wasn't keyboard accessible and it made it really hard to navigate around with a keyboard because the focus just wasn't being managed. There was a lot of work that we did there. I want to focus on the routing situation there because if you can't navigate around with a keyboard in your single page app, like you click a link and it's not selecting the next thing that should be focused and you provide the right amount of context, your app probably won't be usable without a lot of trial and error to a user, which depending on what your product is, they may not have a lot of patience for trial and error, right? WIL: Yeah. ROBERT: It's really important to try and nail down the routing situation and there are some frameworks and things out there that can do it. In the app that we're talking about, it's React app and we use React router but we don't actually really hook into the router to handle that and that's because React router doesn't provide very much information. WIL: Yeah. You can think of React router as more of an outlet system, where your routes can render anything, anywhere on the page. That's kind of dangers of accessibility and that's kind of the reason that React router can't handle accessible things very well because at any point, the route can just change the button on the page to look like something else. CHARLES: Yeah. It just pop in and pop out. There's no deeper model, right? There's not -- WIL: Yeah, there's no tree. CHARLES: Right, there's the internal state -- WIL: Like a component tree, yeah. CHARLES: The internal state of what is happening is completely opaque. You can only analyze the second and third order effects of the React tree. ROBERT: Right and especially if you have nested route components, it's really hard to determine. One of the things that I've seen people do is focus on mount, which is a very naive approach because what if you have three nested routes, they're all going to focus on mount and the last one that mounts wins and that's a focus for which nobody wins. CHARLES: You all tried that, right? ROBERT: Yes. That's part of the document that I wrote up. We tried three different approaches and we ended up landing on something because we were using React router that was more of like an application state thing, so we were checking props because we knew what the user flow was. We knew what the user, when they come to this page is trying to accomplish, so we're able to kind of figure out from where they came from or where they're going through props and focus the right things for them. WIL: One of the examples, like we talked about the third pane opening and focusing the heading inside but what you know what happens when you close that third pane, you kind of lose contexts again, so we have to focus the previous list item that was active because if you focus back at the top of the list, they've essentially lost their place and the list of results. In that case, we couldn't use on mount. That list item is already mounted. We have to listen to props and we have to look at the route through these props to determine if that third pane was open. If it just closed and if an item in the list is active, it should have focus. It's a lot of logic going on. You have to really understand your app in order to make it a very good accessible app. You can't just sprinkle in ARIA attributes and focus on mount everywhere and think it'll work fine because you're accessible. You have to really know the flow. CHARLES: Right. All those signposts point towards having a deeper application state, a deeper understanding of your application than just the render tree. At that point, it's too late and so by that, I'm definitely lobbying a Reach/Ember router. WIL: Yes. We talked a lot about the React router and we can't really be too accessible with it but to create a React router to go out and there is now Reach router. Robert, have you heard any good things about that? You're the accessibility expert here. ROBERT: I haven't played with it myself, so [audio glitch] things that were lost from the React router three to four transition, I think and also, it's actually accessible routing which is nice because it comes out of the box and you know how to implement it. I haven't played with it. I know Gatsby has implemented that for their V2, that's their default router now, which makes me really happy because a lot of static sites that were being built with Gatsby were very inaccessible and broken which made me sad but now, they're not with V2. I haven't played with Reach router but one of the things that I think it provides which was missing from React router was transition hooks. It has a concept of like where you're going from and to for your routes, which really helps figure out what you need to focus. The one thing I will say about Reach router and I'm sure it's got to be configurable somewhere but I haven't really looked and the demos that I saw, they were just focusing the div of the content that's being rendered, like it kind of just wraps with a generic div or the tabindex="-1" and then focuses it. If you have a lot of content that's inside of that div, it probably will be confusing but at least, it manages the focus somewhere. If you're now off in a no man's land, you have no idea what's going on, at least it focuses that. But if you want to really nail the experience to be better, I would recommend trying to figure out what you should focus inside of that route that you just transition to, what is the best thing. That's for React. There are other things out there for other frameworks, like I am on Ember accessibility team that's out there and we have Ember A11y, which just provide you a focusing outlet for you to be able to just drop in your app and then when the route changes, it does the same thing. It focuses the wrapping div of that outlet that was just rendered. I want to emphasize more in talking about e-holdings work that we did that we were focusing the heading because that told you exactly where you're at and what package you're on or what thing you're on. You know the name of it and now you know how you can go and navigate through that. CHARLES: But it's conceivable, so how would you do that with the Ember router? Would you just introduce some way to delegate down to a particular component? Like when I'm rendered into an outlet, it focus on this component? ROBERT: That would be interesting. I actually don't know. It's been a long time since I've messed around with the Ember router and Ember accessibility. It's definitely a great first step and that's where it kind of came from. I think there needs probably some work done to help implement on what you want to focus. That's kind of where I was going with when we were first exploring the React router stuff and e-holdings was I wanted to have this like high order component that knew of your routing tree and it knew where you're coming from or where you're going. Then from there, it would just tell you, this is the route that we're going to and there's need to be focus management done, like if this prop exists, then you can pick inside of that component that what you want to focus. It leaves it up to the implementor of what they need to focus but it could be probably just like a fallback to the general div because that's not bad. It's a good first step. There needs to be a little bit of work there to get that done probably. CHARLES: Yeah. But it is worth pointing out that by starting from a position of having an externalized application state via the route structure, in an Ember application, you're starting 95% of the way there. An Ember application, at any point, you know where you are and during your transition, you know where you're starting and where you're going to end up and you know when you leave and you know when you got there. ROBERT: Yeah. Having an Ember route pivot handler there, like where you're pivoting from and to is just so nice and it kind of made it click together a lot easier. CHARLES: Right. Reach router looks interesting but as I understand, it's still couched in React components and it feels to me like this is a problem that ought to be solved, that ought to be framework agnostic. Because if I use something like Reach or I use some other routing library for another framework, some other tool might come out that I want to use and I shouldn't be locked in -- ROBERT: Right like what if I really like Redux little router, then I have to make a choice between Redux state that I like or accessibility. CHARLES: Exactly and that feels like a false dichotomy to me. What I would want to be looking for is a platform independent or a framework independent routing library that really just helps you represent your application state and the concrete state in which your application is in at any moment and then, also be able to represent the transitions between those states fully and completely. Then if you have that, you could embed that into any framework. ROBERT: Right. That would be really nice to have. Just like pull it off the shelf and help you out there. CHARLES: If anybody is listening who wants something to do for the next 18 months, no one will thank you for 18 months but you had to get on that. We'll give you lots of thanks then. ROBERT: [inaudible] compare with you. That would be awesome. CHARLES: I would love to be part of that. ROBERT: Yeah, that would be awesome. To kind of tie back to other things, I don't know too much about Angular but I'm sure there are solutions out there to help with Angular. I know Marcy Sutton used to do a lot of work in the Angular world, so I'm sure there's something out there that helps with that. I just don't know off the top of my head right now. I wrote a Medium 'think piece'... No, I wrote a little medium blog post about how all of single page out for routers are broken. I was pleasantly surprised by Vue. Vue brings its own router and their router has a concept of before each, so before each route transition you can run some code and that really helped with implementing the live, the announcer pattern where you use ARIA live to announce something but even beyond there, if you wanted to dig in there, you could probably figure out where you're transitioning from and to and give that next route some kind of attribute that says, "This needs to be focused. Figure out what you need to focus there and inside that route, you can focus wherever you want." I thought that was a really awesome. That's kind of the crux of what I was missing from React router. I wanted the concept of knowing where I'm coming from or where I'm going and I would help with everything but unfortunately, that kind of doesn't exists because they're just components. For better or for worse, they're just components. CHARLES: The world is so much more than just components. ROBERT: Yeah, a little bit off topic, I think it's kind of funny how React kind of just shoved everything into the Vue layer, just to make it all a component. CHARLES: Yeah, it's very easy. ROBERT: Yeah, until it's not. CHARLES: Yeah, exactly. It's easy but it's not simple. ROBERT: That's a lot of talking about how routes need to be done and what you can kind of do to manage focus. It's really about managing the context and how you can provide the most contexts. For somebody to operate on that information, can they complete this thing? What can you do to make sure that you've done this properly? What steps can you take to make sure that you actually are accessible and that your routes work? WIL: Manually testing those screen reader is probably the biggest thing, you know? CHARLES: Yeah. I think the biggest thing is really watching someone who uses assistive tech on a regular basis use your application and then trying to use it yourself. WIL: Yeah. ROBERT: Right. Yeah, I'll definitely -- CHARLES: If you can get a little bit of this yourself but then it's kind of like someone who is never used a mouse before and trying to learn something new. What really helps is seeing someone who's good at it and see how their expectations are either being met or not being met. ROBERT: Yeah, it's definitely the best way. If you can find somebody that actually relies on assistive tech, there's nothing that beats that kind of feedback. If they get to your app and they're really confused, I see some people that just dismiss it because they just don't understand. That is the best feedback you can actually get. If they don't understand what's going on, you have -- CHARLES: That's on you. ROBERT: Yeah, that is going to be what happens for everybody that uses that. Well, maybe not everybody because everybody has different experiences but it's probably going to be a thing that pops up everywhere. But if you don't have access to people that are actually using assistive tech regularly and are pros at it, WebAIM provides really great tutorials for how to use a screen reader. If you're using a Mac, you have a screen reader built in and you can use that called VoiceOver. If you ever want to turn it on or turn it off, its command F5. WIL: You might have to have that shortcut enabled, though. ROBERT: Really? I'm pretty sure it's quite default. WIL: I thought I had to enable mine but I could be wrong. ROBERT: It's interesting. CHARLES: Yeah. They got great tutorial too. It's like it notices the first time you turn it on, so it tries to help you navigate bullet lists and select boxes and input fields and check boxes and all kinds of good stuff. ROBERT: Yeah. It gives you a little bit of a boot camp but WebAIM also helps with specific to website and stuff because one of the things that we ran into while working on the e-holdings project is they're transitioning from a native app to a web app and there were just things that you can do on a native app that you cannot do on a web app. Just keep that in mind also when you're testing, there's just things that will behave differently. Like you're not going to have a lot of crazy key shortcut commands like you're not going to press command F to get to the search box if your app has a prominent search box because that is going to clobber a bunch of other assistive tech key commands. WebAIM is really a good help with giving you the tutorial of how to test a web app and many different screen readers, so they have it for JAWS, they have it for NVDA, they have it for VoiceOver iOS, they have it for TalkBack, which is the Android screen reader. There's a lot of really good resources there for you to start using as screen reader and test with your app. I highly recommend using it with a screen off. You gain a lot of context by looking ahead of your cursor and -- CHARLES: Yeah. It's true. ROBERT: -- The example that I usually give to people is like, "I worked on Visa Checkout. I went through that checkout flow pretty much every day for a year and eight months in, even then turning off the screen, I was still lost." Even though I knew what each screen was and what each component was there, I would find myself confused of like, what just happened and it's because sometimes, you'll get into something like you have a dropdown that sets the focus inside the dropdown and then the dropdown disappears from the DOM and your focuses in nowhere. You're like, "What is going? what am I doing. I don't even know where I'm at," and I turn the screen back on and I'm like, "Oh, now, I know what's going on." CHARLES: Right. It really is a lot like interacting with your application as though you were interacting with Siri or Alexa but with a keyboard instead, instead of voice commands. That's an excellent point. We would understand if where would Amazon be if Alexa couldn't successfully navigate those situations. The counterpoint or even the flip side of that is if you model your web application in such a way that it can handle that type of serial interaction, instead of the highly parallel environment to being able to perceive huge amounts of information concurrently, like you can on a screen, if that were effectively serialized, that means you could represent your application through nothing but voice commands. ROBERT: Yeah. Did you provide enough context for me to build this mental map is really what I'm going on to? CHARLES: Yup. ROBERT: Which I always thought was really interesting because I always wanted to know how my mom visualizes what a website looks like because it's wildly different than any of us. She's never been able to see what a website looks like. Does it look like a bunch of nodes and graphs and webs connecting to each other and how things pieced together? It's just a different way. But it's not only about screen readers, right? You can use a keyboard to navigate and that's definitely what we did with e-holdings is like can we tab through this [audio glitch] list, hit enter and go into the detail record, edit it, close it and go back and edit another one. Is that something that we can do with just a keyboard, not even a screen reader? WIL: And with the keyboard, we're not talking about shortcuts to hit edit. We're talking about like tabbing over and hitting enter like people with accessibility issues would have to do. ROBERT: Right and that's kind of a good segue into creating use cases. If you want to know if your app actually works, if your screen reader users or if your keyword users or if your dictation users are going to be able to navigate this app, create use cases. Things like actual user flows like how would somebody actually going to use this app? What task are they going want to complete? In that case, e-holding was like an electronic holdings management system for libraries. They probably want to get in there, add a couple of books or whatever you might have to their library and get out. A use case could be like, "Can I search for this thing? I'm going to search for something specific. I'm going to go through the list, find the thing that I want. I'm going to add it, close the pane, go back and then remove one thing and can they complete that flow successfully without running into any issues or any blockers or any showstoppers." I can tell you before we did the routing management stuff, you would hit search and that was it. There was nothing else that you could do. CHARLES: Yeah. They wouldn't even announce that anything can happen. ROBERT: Exactly. WIL: Yeah, and with these librarians, it's not necessarily a matter of they can't see the screen. It's just that they don't use the mouse because they're power users. ROBERT: Right. They don't have any disabilities but that was essential to the workflow. CHARLES: Yeah, exactly. Do that change. You just lowered the activation energy of that workflow by... What? three orders of magnitude? WIL: Yeah, at least. ROBERT: Let me click here right now. I can tab, now I can tab. Right now, let me click here and now I can tab, I can tab, I can tab. It's not as nice as just being able to completely do it through a keyboard. Through us making it super keyboard accessible, that also became super screen reader accessible and the people who use dictation were able to work through and get through the app and use it now, which was really cool. It really helps when you go for those things and create use cases to really figure out how a user is actually going to work through this app. That's the best way. Just get right through it. With Visa Checkout, we're like, "Can somebody buy something?" or if they don't have an account, can they sign up and buy? those were some of the use cases that we had because it turns out, those are actually pretty important to the business. That all have been said, you also can test your components for accessibility individually because even at a smaller level, some of your components might have to manage focus. The best one I can think of is models. When you open a model, you should trap the focus inside of that model and you should be able to hit escape to close the model and when you close the model, it should go back to what triggered the model to be opened. These are all things that are individual that can be tested also. But just because your components are individually accessible, it does not mean your application as a whole was accessible either. I don't want to paint the picture like, you don't have to care about your components accessibility individually because you do. It really does help but I think a lot of people miss the whole of the application, rather than individual with components. CHARLES: Right. The components are the individual stitches but you have to follow the thread throughout the entire garment. ROBERT: Right, exactly. CHARLES: Man, what I really want to do is I want to find out how your mom visualizes website navigation and use that as a visualization technique. ROBERT: That might be a fun webcast or something. CHARLES: Yeah and then see like could we actually use it as a tool because I have to imagine, it's probably pretty simple. It's much simpler than what we think of when we think of a website because it has to be really condensed down to its essence. ROBERT: Right. Yeah and [inaudible] users, they're not dumb. They have different ways. They know the gotchas. They know things that happen. They know there are different ways of getting trolled like my mom knows about focus jumping and she gets irritated what happens but she knows generally of what to do and it depends on her patience level. Like if it's focused jumping, she's like, "I don't need to use this thing. See you," and it's just not worth the frustration but there's different ways to navigate around like if you're a real power user, you might be able to recognize like the routing is inaccessible and you can navigate by headings or by regions or different landmarks. There's many different ways for users to navigate but to use those different navigation methods, you need to have a real strong coherent document structure. Your H1s have to actually be H1s and you have to have some things that they can navigate around to kind of work around those things. It's interesting and basically, do everything you can to help those situations. If you can provide semantic markup and give it a proper structure. If you can do the focus management, it's going to help everybody. It really will. I did see when we went through the use cases and defining those things, we actually learned a little bit more about our product because we had to put ourselves in a different seat and think about it because you get real close to it. You go through that same flow nine million times and you pick up real power user things that you can do like, "I'll work on that. I got this. I'll click this button. All right, we're good." Somebody that's going through it for the first time and you put yourself in that seat, it kind of opens your eyes a little bit and makes the experience better for everyone. I think that's kind of the underlying tone there. That's the message. WIL: Yeah, accessibility makes things better for everybody. ROBERT: That was a lot of content thrown at you there. We covered what is accessibility and why you'd want to do that and then kind of like more the basics things and how automated tools are really helpful and they can help you pick out things like using improper roles and nested things but they're not going to be able to tell you if your application is truly accessible or not and never will, unless we get something like a headless screen reader, where you can write automated tests for in that fashion but you're not to get something that will just run over you app and go, "Yup, you're good." CHARLES: Even so, it's a matter of user experience and that's not something you can get a thumbs up or a thumbs down to. When you as a user, it comes with application, you know when you see it but I would say until we have androids that accurately simulate human beings, I don't think we're going to actually have automated testing. ROBERT: Yeah. There's a joke for accessibility consultants. It's like if you put four accessibility consultants in a room and tell them to give you an alt attribute for an image, you'll get four different alts. We talked about the automated checkers, right? They'll not going to get everything for you and we talked about single page apps specifically in the routing and how we handled the routing in a React app and then how you can probably do it in an Angular app and how you can do it in an Ember app and Vue and different methods of how you can kind of attack that. We're definitely giving the link to the document that I wrote and the PR so you kind of see the real 'how' of how we did it because that would probably be helpful. I think there was a lot of good information there, so I would like to thank both Charles and Wil for being awesome co-host on this and -- WIL: Thanks for being an awesome host. CHARLES: Yeah, thanks for being an awesome host. I should say, you're welcome. ROBERT: I tried, I tried. We are The Frontside. We do accessibility consulting and training. If that's anything that your team needs help with, we're more than happy to jump on a call with you to kind of figure out what your needs are and what you need to do. If you need a WCAG support statement, if you need to audit, if you just need to figure out what's the next steps for you to even do, we're more than happy to help you sort through that. To reach out for that, you can contact us at Contact@Frontside.io or Sales@Frontside.io or Info@Frontside.io. You can contact us at any different ways and we'll be more than happy to help you. As always, thank you Mandy for producing the podcast. You're awesome and the next episode, what we're going to have is also still accessibility related and I'm really excited about this. It's about writing a proposal to the Unicode Committee and getting it accepted so basically, writing a proposal to get an emoji added and that's with Amberley and Amanda. They wrote three or four Unicode specs and actually got them accepted for, I believe it was sign language and deafness. That's really cool and I'm super excited for that because they'd be the first people that I've ever talked to that have actually created an emoji and gotten it accepted. WIL: Yeah, it's pretty cool. CHARLES: Yeah, that must feel great. ROBERT: Yeah, it's going to be awesome. That's our next episode. If you have any ideas or comments or anything, you can tweet us at @TheFrontside on Twitter or you can contact us through any of the emails that I talked about earlier. We're always open to hearing feedback. Thanks for listening. Take it easy, everyone.

How do we ensure a high level of quality and maximize the refactorability of our code? Frontsiders, Wil and Charles, talk about their battle tested techniques for testing web applications, not only in React JS, but in any JavaScript framework. Links Acceptance Testing Integration Testing jest Cypress.io Assertion Ember CLI Mirage mirage-server react-trigger-change Transcript CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 90. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. And with me today is Mr. Wil Wilsman. Wil, who just got back from Nodevember just walked straight into the office and is ready to podcast with us on a very, very, very interesting subject, I think, today. We're going to be talking about acceptance testing in JavaScript applications, especially some of the techniques that we've developed here around testing React applications based on the lessons that we learned from the Ember community. But really, more than just React applications. Really, testing any JavaScript application from the inside out, making acceptance tests for that. So, I think we're going to talk about some of the challenges that you encounter and some of the really novel solutions that are out there that we had nothing to do with. And I guess we really didn't have, just more of cobbling together of various techniques for a powerful witch's brew for acceptance testing. Anyway, so Wil, just to round out the problem space or explore the problem space, what are some of the challenges that you encounter with an acceptance test? Actually, let me back it up even further. What is an acceptance test in a JavaScript application compared to what people normally encounter? WIL: Acceptance testing or end-to-end testing is just a problem that every JavaScript app should face. Not everyone does, but they definitely should. And basically, it's how the user interacts with your app through the browser. And every part of that we want to test, from the browser triggering browser events, interacting with the app, not calling functions or clicking buttons, and we're pretending we're a user. CHARLES: Yeah. You know, I know that when we showed up in the React space, that was not really the way that most people tested their applications. WIL: No, not at all. they're all about unit testing. Make sure every small piece of your code works, and to some degree integration testing, making sure your components work with other components. But, nothing is out there really for those big acceptance tests that you want the user to click a button and expect them be brought to a page or these fields to be filled out, et cetera. CHARLES: Mmhmm. Yeah. And there certainly was a very high level of maturity around unit testing, like you said. There are tools like Enzyme and… WIL: Jest. CHARLES: Yeah, Jest. But I was actually shocked to find out that Jest didn't even run in the browser. WIL: Yeah, it's all virtual. CHARLES: It's all virtual. It's completely and totally simulated and stubbed. And that presents some problems. WIL: Yeah. The main problem is cross-browser testing. Some people might consider that to be separate from their acceptance testing but you should be able to just run your acceptance tests in multiple browsers and be able to also test cross-browser support. CHARLES: Mmhmm. Yeah. And so, if you're using something like Jest, you're never actually running the code inside Safari. You're never actually running it inside Internet Explorer. You're actually running it in NodeJS. WIL: And you know, your user is not going to run it in Node. [Laughter] WIL: They're going to use a browser. CHARLES: I don't know about your users. WIL: [Chuckles] CHARLES: [Laughs] You know, we like to stick to the pretty advanced. It's like, go to getNodeJSBrowser.com. WIL: [Laughs] CHARLES: Enough of this Firefox BS. But not seriously, it was certainly a problem. We were looking around, because we never like to build anything ourselves if we can avoid it. But it really just seemed like there was not an off-the-shelf solution for writing these big style acceptance tests in JavaScript. There are some services out there. There's a couple now. What was the… WIL: I think the main one here is Cypress. CHARLES: Cypress, yeah. So, there's Cypress now. I've watched the instructional videos but never actually tried to integrate it into my application. WIL: Yeah. I think at its core it takes the same approach that we've been doing with how we're interacting with our tests. CHARLES: Mmhmm. Okay. The main difference is, is it that it's a service? Like you have to edit your tests through… WIL: Yeah. CHARLES: Their web browser, their web interface, and use their assertion library? WIL: Yeah. I'm not sure about the editing part. But yeah, it's their assertion library. I'm pretty sure it's their test runner and it's their testing environment. Really, the only control through that is through their UI, or through settings, basically. And you're stuck with those. You can't use other… I don't think you can use Mocha with Cypress. CHARLES: Right. WIL: Although it's very much like Mocha… CHARLES: Right. WIL: It's not. CHARLES: Right, right. And I also noticed, we'll touch on this later, the assertions, most of the side effects that were happening were happening right there inline inside your assertions. And that might be an opaque statement, but we will actually get into that later. WIL: Yeah. And I think one of the things about their side effects so to speak is everything leading up to a side effect is a promise with Cypress. CHARLES: Mmhmm. WIL: So, when you select a button and click it, Cypress is going to wait for that button to actually exist before it clicks it. CHARLES: Right, right, which is actually pretty cool. So, that's actually a perfect into into one of the primary challenges with doing acceptance testing in general in a JavaScript application. This is a problem when you're doing it in Ember. It's a problem in React. It's really a problem anywhere. And that is, how do you know when the effects of a user's interaction have been realized? Right? WIL: Yeah. And in Ember you take advantage of the run loop. Once that action happens, you wait for the run loop to complete and then your tests run. CHARLES: Right. So, the idea is that I've clicked some button or I've typed some key or I've moved the mouse. And then I listen for the run loop and when it's “settled” then I can now run my assertions because I know that the side effects that I was looking for have now been realized. WIL: Yeah, hopefully, if you're... CHARLES: Hopefully. WIL: Writing your app right. [Chuckles] CHARLES: Right, right. But that actually presents some problems in itself because it requires visibility into the internals of the framework. WIL: Yeah, so Ember is built with testing in mind. CHARLES: Mmhmm. WIL: And other libraries like React just being a view library might not be built with testing in mind. So, we don't have those hooks to wait for this loop to complete, wait for all of these things to be rendered before you continue. CHARLES: Exactly. And so, this is, I think it's actually kind of both a blessing and a curse. Because there are such strong conventions in Ember, they were able to build this wonderful acceptance testing regimen from the get go. WIL: Yeah. CHARLES: But like you said, that doesn't exist at all in the React ecosystem. And so, what do you do? There's no run loop. You're cobbling together a bunch of different components. And maybe you're using Redux, maybe you're using MobX, maybe you're using… you're certainly using React. And all of these things have their own asynchronies built-in. And there's not one unifying abstraction that's keeping track of all the asynchrony in the system. And so that presents a challenge. So, the question is then, if you're trying to not actually check and observe the state of a system until the right moment, how do you know when that right moment is? WIL: Yeah. And in early testing of a side React project I had, I would basically wait for a state to be complete before I continued my ‘before each'. And in the testing we're doing now, it's essentially what we're doing except the state is what the browser sees, or what the user would see in the browser. CHARLES: So you were actually querying the... WIL: Yeah. So, I was using Redux. So, in my app I was saying, when the Redux app is done loading... CHARLES: Mmhmm. WIL: The instance is set to true or false, then continue the test. CHARLES: Mmhmm. And so, what that means, what we're doing, is doing the same thing except observing at the DOM... WIL: Yeah, exactly. CHARLES: Level. And what it means is we actually… I would love to set this up and have a big reveal but I guess we'll just have a big reveal, is that essentially what we do is polling. WIL: Yeah. CHARLES: Right? So, when we run an assertion, let's say you click a button and you want the button to become disabled, there's an inherent asynchrony there. But what we will do is we'll actually run the assertion to see if it's disabled not one time. We'll run it a thousand times. WIL: Yeah, as many times as needed until it passes. CHARLES: Right, exactly. As many times as needed until it passes. And I think that is, at least to most programmer instincts, an odious idea. WIL: Yeah. CHARLES: [Laughs] WIL: It's like, “Oh wait, you're just looping over every single assertion how many times?” CHARLES: Yeah, exactly. And it feels, yeah, it feels weird as an idea. But when you actually see the code that it produces, it just sweeps away so much complexity. WIL: Yeah. And… CHARLES: Because you don't worry about asynchrony at all. WIL: Yeah. And it's pretty genius. If I'm a user and I click a button, it's loading when I see that it's loading. So, our tests are going to wait until that button says it's loading. And then the test passes. CHARLES: Right. And so, what we do is we essentially, we use Mocha but you could do it with QUnit or anything else, is that when you run your assertion, you declare, you have an ‘it' block or I guess, what would it be in QUnit? WIL: A test? CHARLES: A test? WIL: I think it's just a test. CHARLES: You have your test block. And so that function that actually runs the assertion and checks the state will actually run, yeah it could run three times. It could run a thousand times. It's just sitting there waiting. And it will time out. And it will only fail if that assertion has failed a thousand times or it has failed through, I think two seconds is our default. WIL: Yeah, yeah. I think we default to the runner's default timeout. CHARLES: To the runner's default timeout, yeah. WIL: Yeah. Or you can set that yourself with how we have it set up. And the other thing that comes from that is if your tests are only failing when they time out, how do you know what's actually failing? And our solution to that was we catch the error every time it fails and right before the timeout actually happens we throw the real error. CHARLES: Yeah. Exactly. But the net effect is that you're able to write your assertions completely and totally oblivious of asynchrony. You don't, we don't have to worry about asynchrony pretty much at all. I mean, we do, and we'll get into that. So, I made a global statement and then immediately contradicted it. WIL: [Chuckles] CHARLES: But hey, you got to be controversial. But for the most part, asynchrony just disappears because asynchrony is baked into the fabric. So, rather than thinking about it as a one-off concern or a onesie-twosie, it's just every single assertion is just assumed to be asynchronous. And so, that actually means you don't have to deal with promises. You don't have to deal with run loops. You don't have to deal with anything. You just write your assertion and when it passes, it passes. And there are some really unique benefits for this. And there are some challenges. So, I think one of the first benefits is that it's actually way faster. WIL: Right. CHARLES: Which is counterintuitive. WIL: It's incredibly fast. CHARLES: It's very fast. WIL: Yeah, for all the loops that's happening you might think every loop is going to slow it down slightly. But it really doesn't. Our tests, each test, even though it asserts five or six times, it takes milliseconds. CHARLES: Mmhmm. WIL: The test itself might only loop twice. CHARLES: Right. Exactly. Whereas if you're waiting for a run loop to settle, you might have some… you click a button, it disables, it also fires off an Ajax request and does all this stuff. But if all my assertion wants to know is “Is this button disabled?” then I only need to assert until that has happened. I don't need to wait until all the side effects have settled... WIL: Mmhmm. CHARLES: And then do the assertion. I just know, “Hey, my assertion, the thing that I was waiting for - that happened. Let's move on.” Yeah. And so, it's so, so fast. And that was actually, I didn't predict that. But I was definitely pleasantly surprised. WIL: Yeah, that was a very nice surprise. And all of our tests ran so much quicker than they would have in a run loop environment with Ember or something. CHARLES: Right. Yeah, yeah. That was, we actually had just come off a project where we were having that thing, that exact problem, which was that yeah, our animations were slow. Or, the animations were fine. They were perfect. [Laughs] But there were slowing down the tests. WIL: Yes. I think in that project, it was like, 30-minute tests... CHARLES: Mmhmm WIL: For the whole suite to run. CHARLES: Yeah. To which I'll add a public service announcement. I think this is a conjecture but I do believe that animations are best applied not to individual components but by the thing that uses a component. So, I shouldn't have an animation that's like, implicit to a dialog. It should be the thing that's showing the dialog that gets to decide the animation to use. Anyway, just throwing that out there. WIL: [Laughs] CHARLES: Because animations are about context. And so, the context should provide the animation, not the individual atom. Anyway, moving on. WIL: Some other podcast. CHARLES: Yeah. [Laughter] CHARLES: That's another podcast right there. But there's also, this does present some challenges or requires code to be structured in a way that facilitates this. So, there are some challenges with this approach, some things you need to be aware of if you're using this kind of system. We've kind of settled on a name for what we call these types of assertions and these types of systems. WIL: Yeah. We call them convergent assertions, because you're converging on something to happen. It's going over and over until it happens. CHARLES: Right. WIL: And yeah, a lot of these challenges that we've come across are things that you might not think of, like there are a few instances of false positives... CHARLES: Mmhmm. WIL: That happen with these convergent assertions. CHARLES: Right. So, what would be an example there? WIL: So, the most common example that I'm seeing so far is when you're asserting that something didn't happen. CHARLES: Mm, right. WIL: That would immediately pass. But if it takes your app... CHARLES: [Laughs] WIL: A few seconds for it to actually happen, then you could still have an actual failure but your test passed immediately. CHARLES: Right, right. So, what's the countermeasure then? WIL: We invert our assertions. So, we make sure they fail for a certain amount of time. CHARLES: Right. So, the normal case where you just want to say, “I want to make sure that my state converges to this particular state.” WIL: Alright. I said fail at first. I meant, pass. We have to make sure it passes for a certain period of time. CHARLES: Right, exactly. WIL: So yeah, the normal way is it fails until it passes, and then it passes. When you invert one of these convergent assertions, you're just making sure it passes repeatedly and if it fails at any point, you throw a failure. CHARLES: Right, okay. And so, that's like, if I want to check that the button is not disabled, I need to check again and again and again and again. WIL: Until you're comfortable with saying, “Alright. It's probably not going to be disabled.” CHARLES: Yeah, exactly. And so there, it's kind of weird because it is dependent on a timeout. WIL: Mmhmm. CHARLES: You could go for two seconds and then at the very end it becomes disabled. So, you just kind of have to take that on faith. But... WIL: Yeah. CHARLES: In practice, I don't think that's been much of a problem. WIL: No. CHARLES: It's more indicative of, if your button disables after... WIL: A few seconds. CHARLES: A few seconds, what's up with your... WIL: Yeah, what's up with your app? CHARLES: Yeah, exactly. WIL: If you're waiting for an Ajax request or something, an example, then you should be using something like Mirage Server. CHARLES: Right. Which is, man, we got to get into that, too. There are a couple of other things that I wanted to talk about too, with these convergent assertions. And that is, typically when you look through the READMEs for most testing frameworks, you see the simple case of the entire test, the setup, the teardown, and the actual assertions, are in the actual test. WIL: Yeah. The ‘it' block in Mocha or the test block in QUnit. You click a button, and then make sure it's disabled, and it moves onto the next test. CHARLES: Mmhmm. WIL: Then you click a different button or the same button and you assert something else in the next test. CHARLES: Mmhmm. Right. WIL: And yeah, you can't do that with convergent assertions because they're looping. So, if you click a button in a loop it's going to keep clicking that button over and over and over again. CHARLES: Yeah. [Laughs] Right, right. So, it means that you need to be very conscientious about separating the parts of your tests that actually do the things that actually act the part of the user from the part of your test that's about observation. WIL: Yeah. So, our solution to that is we move out all of our things that have side effects like clicking a button or filling in a form, all that stuff happens in ‘before each's. And all of our actual assertions happen in these convergent ‘it' blocks that loop over and over again. So, our ‘before each' runs and clicks the button and then we have 10 or so tests that will loop and wait for various states to... CHARLES: Yeah. WIL: Be true. CHARLES: Right. That means that yeah, all these assertions do is they read state. And you just have to, you do have to be conscientious. You're not allowed to have any side effects inside your tests, your actual assertion blocks. WIL: Mmhmm. CHARLES: But that's actually, it's a good use case for the whole Act-Arrange-Assert, which has been around way, way, way before these techniques. But here, we're doing Act and Arrange in our ‘before each'... WIL: Mmhmm. CHARLES: And then we're doing Assert later. And I think it actually leads for more readable... WIL: Yeah, definitely. CHARLES: Things. WIL: And it also opens the door to something that we can't really take advantage of yet but if you have 10 assertions with one ‘before each' side effect, you could run all of those assertions in parallel. CHARLES: That's right. WIL: And your tests would be 10 times more faster. CHARLES: Mmhmm. Yeah, exactly. Or you could run them in parallel or you could just run them one after the other but you wouldn't have to run that ‘before each' 10 times. WIL: Yeah. But something with that, that I found, is if we move all of our side effects to ‘before' blocks instead of ‘before each' blocks, sometimes a test three tests down that's waiting for something to happen... CHARLES: Yeah. WIL: That thing might have already happened earlier... CHARLES: Yeah. WIL: And it already went away. A loading state is the best example of that. CHARLES: Mmhmm. WIL: You show the loading state, the loading state goes away. So, if you move that button click into a ‘before' and that loading state test is three tests in, that loading state is already going to be gone. CHARLES: Yeah, so I think the long story short is we've kind of come to the conclusion that we would have to write our own runner. WIL: Yeah. CHARLES: Essentially to take advantage of this. But that said, we've done some sketching about what we would gain by writing our own runner. And the speed, we're talking about exponential speedups. WIL: Yeah. CHARLES: Maybe taking an entire acceptance test suite and having it run in five or six seconds. WIL: Yeah. We're talking about these tests that are already extremely fast. CHARLES: Mmhmm. WIL: Each test takes a few milliseconds or tens of milliseconds to complete. But then if you can run all of those at the same time, all of your tests for that entire ‘describe' block just ran tens of milliseconds. CHARLES: Right. Yeah. So, it's really exciting and pretty tantalizing. And we would love to invest the time in that. I've always wanted to write our own test runner. But never had, [chuckles] never really had a reason. WIL: Yeah. CHARLES: Certainly not just for the sheer joy of it. Although I'm sure there is joy in writing it. But that, yeah, we'll have to wait on that. But I am actually really excited about the idea of being able to maybe bring this back to the Ember community. WIL: Yeah. CHARLES: Because acceptance tests getting out of control in terms of the speed is I think a problem with Ember applications. And I think this would do a lot to address that. WIL: Yeah. CHARLES: I think, how long, if we were just using a stock Ember acceptance testing setup for this, I think we have about 250 tests in this React app... WIL: Yeah. CHARLES: How long does it take to run? WIL: Right now I think our tests take something like 20 seconds. And that's also somewhat due to they have to print the tests on the screen on Travis so that takes a little time. In an Ember setup, that could maybe take a few minutes. I mean, that's not that big of a deal, a few minutes. CHARLES: Right. WIL: But compared to 20 seconds. CHARLES: Right. you're still talking about an order of magnitude... WIL: Yeah, exactly. CHARLES: Difference. And using this, I think you could get a 30-minute test suite... WIL: Yeah. CHARLES: Down to the order of 3 minutes. WIL: Now when we're talking about those times, we're talking about the tests themselves. Of course, the CI would have to download stuff and set up the [inaudible]. CHARLES: Mmhmm, right, right. WIL: And that of course all adds to the time. CHARLES: Yeah, mmhmm, yeah. Earlier you mentioned, we talked about Ember CLI Mirage. This is actually something that is having now been using it for what, 2 years or something like that, it's just… it's impossible... WIL: To go back, yeah. CHARLES: To go back. It is. It's like [chuckles] you come outside the Ember community and you're like, “How is anybody ever dealing without this?” WIL: Yeah. CHARLES: [Laughs] WIL: A lot of the mocks are usually mocking the function that makes the request and it returns it in that function. That's what's out there currently, minus the Mirage stuff. CHARLES: Mmhmm. WIL: But once you use Mirage, you're mocking the requests themselves. CHARLES: Yeah. And you've got such great support for the whole factories. I love factories. It's something that is very prevalent in the Ruby community, and maybe not so much elsewhere. But the ability to very, very quickly crank out high-fidelity production data... WIL: Yeah. And you don't have to have files upon files of fixtures. CHARLES: Yeah, exactly. And you can change, if something about your schema changes, you can change the factory and now your test data is up and running. So, Ember has this tool called Mirage which is just, like I said, it's so fantastic. Oh yeah, it's also go support for running your application. Not just in your tests, but you can actually run your application with Mirage on and... WIL: Oh right, yeah. CHARLES: And you've got now the most incredible rapid prototyping tool. WIL: Yeah. You don't need to connect to a server to see fake data. CHARLES: Right, right. And we were even talking about this yesterday to a potential client. they're trying to, they've got to present something to investors. And how wonderful is it to just be like, “You know what? We just don't want to invest in all, we don't want to move the inertia, invest the money to generate the force to move the inertia of a backend.” Especially in this particular use case, the backend was going to be really, really heavy. WIL: Yeah. And there were some questions about the backend that we couldn't address quite yet but we wanted to start working on something that we could show, something demo-able. CHARLES: Right, exactly. And so, Mirage is just so wonderful for that. But again, Mirage is, it's an Ember-specific project. WIL: Right. CHARLES: So, the question was, “How are we going to use that?” WIL: And you actually took this on yourself. CHARLES: Mmhmm. WIL: I just saw this pop-up one day and boom, you converted Ember Mirage to vanilla JavaScript. [Chuckles] CHARLES: So, I did extract it. But the lion's share of the credit goes to the developers of Mirage themselves. Sam Selikoff and the Mirage community, they built Mirage not using much of Ember. There were some utilities that they were using, but mainly things like string helpers to convert between camel-case and dash-case, and using a Broccoli build, or using an Ember CLI build. WIL: Yeah. That was one of the challenges that we came across using Mirage outside of Ember, was how do we autoload this Mirage folder with all this Mirage config and Mirage factories and models, et cetera. CHARLES: Right. The internals were all just straight up JavaScript classes, for the most part. And so, extracting it, it was a lot of work. But 90% of the work was already done. It only took three or four days to do it. WIL: Amazing. CHARLES: Yeah. So, it was actually a really pleasant experience. I was able to swap out all of the Ember string helpers for Lodash. So now, it's good to go. It shares a Git history with Ember CLI Mirage, so it's basically a fork. WIL: Mmhmm. CHARLES: Like, a very heavily patched Ember CLI Mirage. But I keep it up-to-date so that it doesn't... WIL: Good. [Inaudible] CHARLES: Yeah, so I think the last time I merged in from master was about a month ago, something like that. Because it's got all the features that we need but it's not a big deal to rebase or just to merge it on over in. Because yeah, it's a really straightforward set of patches. WIL: Was there any talk with the creators of Ember Mirage about getting this upstream? CHARLES: So, I've talked a little bit with Sam about it. And from what I can tell, his feeling on it is like, “Hey, my goal right now is to focus on this being the best testing and data stubbing platform for Ember. Anything that happens out there, outside of that scope, that's great. And I certainly won't get in the way of it. But I'm pretty maxed out in terms of the open source credits that I have to spend.” WIL: [Chuckles] CHARLES: And there hasn't been much motion there. I'm happy where it is right now. I would like to see it merged into upstream. I think it would be great to have basically this Mirage Server and then have Ember CLI bindings for it. WIL: Yeah, yeah. I was going to say, either another Ember CLI specific package for Mirage or maybe to make it a non-breaking change or something. CHARLES: Yeah. WIL: Just like an Ember-specific entry point. CHARLES: Right, exactly. And I think that's definitely doable, if someone wants to take it on. I will say, we have been using this extracted plain vanilla JavaScript Mirage Server now for what, almost six months? WIL: Yeah. CHARLES: And it really hasn't... WIL: Yeah, I don't think I ran into one issue with that. CHARLES: Yeah. It's solid. It's really, really good. So, kudos to the Mirage team for doing that. And if anybody is interested in using Mirage in their projects, it's definitely there and we'll put it in the show notes. WIL: Yeah. We call it Mirage Server. CHARLES: Mirage Server, yeah. So, I don't know. Maybe it's time to reopen that conversation. But it has become a very integral and critical piece of the way that we test our JavaScript applications now. So, what are the foundations of it? We've got, we're using Mirage. We're using these convergent assertions. We're using Mocha, although that's really... WIL: Yeah, we have jQuery and Chai jQuery just to help us out with interacting with the browser as a user would. And I think one of the big challenges with that actually, I just remembered, was triggering changes in React. CHARLES: Yeah. WIL: I think this is pretty specific to React. You might run into problems with the view. I don't know how to mess with view. But in React, at least I think 15 or React 16, one of them, they changed the descriptor of the value property on an element so that they can appropriately interact with it, make changes, watch for changes, et cetera. So, when you set this value property using jQuery or just straight up ‘.value()', that change event isn't triggered in React. Your on-change handlers are never called. CHARLES: Wait, they actually update the JavaScript property descriptor of the DOM element. WIL: Yes. CHARLES: Boo. WIL: Yeah. So, there's a nice little helper out there called React Trigger Change. I dug through it and I've stripped some of it down to just be for more modern browsers, more modern React. But there's a lot of good code in there. And basically, it just caches that descriptor, updates the value, triggers the change, and then adds the descriptor back. And that ends up triggering that React element. CHARLES: Okay. [Laughs] WIL: [Chuckles] Yeah, so that calls your handlers and that's how we get around that. CHARLES: Right. There's a few fun little hacks there. But I think it is good to tie that into a larger point, is that the amount of touch that you have with the framework is actually very low. WIL: Yeah. CHARLES: So, the amount of affordances that we've had to make just for React, there's that, that you just mentioned. And is there… there's not much else. We had to write a test harness to mount the app. But that's like... WIL: Yeah, yeah. Our describe application helper is pretty React-specific. CHARLES: Right. WIL: So, you'd have to render it and set up a Mirage server, et cetera. CHARLES: Right. But that's application-specific setup. WIL: Yeah, that's one file. CHARLES: Right. WIL: So, your goal for acceptance tests is you want to be able to have a refactor and your acceptance tests still pass. CHARLES: Right. WIL: So, what if that refactor involves switching libraries? CHARLES: Right. WIL: If you're writing Ember acceptance tests, you're going to have to rewrite all your acceptance tests. CHARLES: Right. WIL: That's a huge downside. CHARLES: Right. WIL: So, with this method of interacting with the actual library very little, we have that one file that sets up our app and then we have that one trigger change helper, we remove those, we can use whatever framework we want underneath this. And our tests would still work. CHARLES: Yeah, exactly. And I think that we actually could theoretically, and honestly I have enough confidence in this style that we're developing the tests now, we could refactor this application to Ember and not have to rewrite our tests. WIL: Yeah, exactly. CHARLES: In fact, the tests would be an aide to do that. WIL: Yeah, and the tests would be faster than Ember testing with that run loop problem. CHARLES: Yeah, exactly. that's really something to think about or to think on, is like, “Wow. You're really at this point completely, not completely, but very loosely coupled to the actual internal library code.” Which is one of the goals of a nice, big acceptance test, is to be able to make major changes, break big bones, and be able to set them and have your acceptance test suite be the bulwark that holds it all together. WIL: Yeah. CHARLES: So, I actually don't know what a bulwark is. WIL: [Laughs] CHARLES: I just know that it's a really strong thing. [Laughter] CHARLES: Maybe we could put that in the show notes. [Laughter] WIL: A link to what that is. CHARLES: [Laughs] So, alright. Well, I'm trying to think if there is anything else that we wanted to mention. Any challenges? Any next things? WIL: So, one of our next steps is something we mentioned that Cypress does, is they wait for elements to exist before they interact with them. And we're actually not doing that in our app currently. And we don't have helpers out there for it yet. CHARLES: Right. WIL: But that's very much the next step. When we go to click an element in our ‘before each', we have these describes that are nested. Say, you have nested describes and you get down three levels into a ‘before each' when you're clicking a button. That button might not exist yet. CHARLES: Right. WIL: And especially since we're using jQuery, if you trigger a change on an empty jQuery element, it's not going to throw an error. It's just not going to tell you that it triggered anything. CHARLES: Right. WIL: So, we get those skips where that button's not getting clicked and we should really be waiting for that button to exist. CHARLES: Right. So, what we've done right now is we're converging on our assertions at the backend of a test. But at the frontend of a test we need to also be converging at some state before we can actually interact with the application. WIL: Right, yeah. CHARLES: So yeah, so that part is missing. And that actually brings up, we are very slowly but nevertheless doing, we're collecting these convergent assertions and convergent helpers in a repository on our GitHub account. We're going to be adding these things so that you can either use them out of the box or use them to make your own testing library. WIL: Yeah. And one of the other next steps that goes along with waiting for the element to exist is when you need to chain convergences. Like, wait for this element to exist and then click it and then wait for this thing to happen before actually running a test. And that presents the problem of our convergences are waiting for that timeout and those timeouts will accumulate. So if you have three chained convergences, that's now a six thousand millisecond timeout as opposed to a two thousand millisecond timeout. CHARLES: Right. WIL: So, one of the next steps is getting that tracking under control so if you chain three convergences together, they're smart about it and they still fail under the two thousand millisecond timeout. CHARLES: Right, right. So yeah, so we're going to be collecting all this stuff that we're learning into some publicly available code. We have a repository set up. I don't know if I want to announce it just yet, because it's really early days. WIL: Yeah. CHARLES: But that definitely is the plan. And that way, whether you're using Mocha or whether you're using QUnit or whether you're using Chai or jQuery, you've got these underlying primitives that help you converge on a state, whether that state is to interact with some piece of the DOM or to just assert some observation is made about that state. We'll be continuing on that. But by all means, get in touch if this is something that is of interest to you. Let's make something happen, because it's something that we're pretty excited about. And honestly, it's pretty comfortable living inside the four walls of this test suite. WIL: Yeah. CHARLES: It feels pretty good. WIL: It does, yeah. They're very fast. And some places in the test might need a little reworking, but for the most part all of our tests are very well-written, very well-readable. And you can just open up a test and know exactly what's going on. CHARLES: Yeah. Alright. Well, I think that about does it for Episode 90. Wow, Episode 90. WIL: Man, coming up on that 100. CHARLES: Yeah. We're going to have to have a birthday cake or something. WIL: Do we celebrate Episode 100 or Episode 104? CHARLES: What's 104? WIL: 104 would be 2 years. CHARLES: Oh really? WIL: Well, I mean 2 years' worth of podcasts. CHARLES: Oh, right. 2 years' worth of podcasts. Yeah. WIL: Yeah, like if you go every week. CHARLES: Maybe we should celebrate a hundred hours or something like that. WIL: Oh yeah. CHARLES: We can add up the thing or celebrate… I don't know, be like, “You've literally wasted 2 years of your life.” WIL: [Laughs] CHARLES: “2 weeks of your life listening to the podcast.” Anyway, so that's it for Episode 90. and thank you so much, Wil. WIL: Thanks for having me. CHARLES: It's always a pleasure to talk about these topics with you. And as always, if you need to get in touch with us, please reach out to us on Twitter. We are @TheFrontside. Or you can send an email to contact@frontside.io.

Getting outside of the infosec echo chamber is something I've wanted to do for the past year. Spending time at infosec events is important for a career. It's great for networking and knowledge sharing. We need to do those same things at non-infosec events. For me that means getting out to developer events. I am speaking at Nodevember at the end of November 2017 and also at CodeMash in early January 2018. For better security I think it's a crucial activity.

Kaylie Kwon: kaylieEB | kayliekwon@gmail.com Show Notes: 02:14 - Kaylie's Journey Into Software Development 09:25 - Implementing a Design System and Attacking Higher-level Workflows 15:43 - EDS Collaboration and Public Availability 19:07 - Getting Involved with The Yarn Project 20:57 - Selective Resolution 23:37 - The Warmth of the Yarn Community 27:11 - Handling Issue Communication and Tracking Resources: Eventbrite britecharts Eventbrite Spectrum Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast. My name is Charles Lowell, I'm a software developer here at the Frontside and your podcast host-in-training. With me today is Elrick Ryan. Hello Elrick. ELRICK: Hey, what's up Charles? CHARLES: Not much. Are you enjoying your morning so far? ELRICK: Yeah, my morning is going well. Everything is good. CHARLES: Lots of cups of coffee? ELRICK: No cups of coffee yet. I've been drinking a lot of green tea. CHARLES: I've actually heard that's really good for you. ELRICK: That's what I heard too. That's why I started drinking it. CHARLES: Did you continue because it tastes good or do you just live on the idea of how good it is for you? ELRICK: A little bit of both. It doesn't taste that great but it's not horrible. It's almost like an acquired taste and then when you add in, "This is good for me," then it tastes great. CHARLES: Okay. We got a nice [inaudible] there. ELRICK: Yes. CHARLES: Anyway, I guess we should, at some point get on to the main content of our podcast. We have a very interesting guest with us today who has her fingers in all kinds of pies that we were talking about just at the pre-show, just before we were recording so we're really, really happy to have Kaylie Kwon. Thank you for coming on the show and welcome. KAYLIE: Hi. Thank you for having me. CHARLES: It's going to be great. Now, you are a software engineer at Eventbrite, that's correct? KAYLIE: Yep. CHARLES: What kind of things do you do over there? KAYLIE: I used to work on part of the feature team that worked on their reserved seating product but not too long ago, I moved to our frontend platform team, which is a team that helps other frontend engineers move faster through things like working on infrastructure or Eventbrite design system and dev tools. CHARLES: So like getting into the tools that unlock the exponential productivity of the developer team? KAYLIE: Uhm-mm. CHARLES: We're going to dig into all of that because you just listed a bunch of really interesting stuff. I'm really excited to talk about the design systems, in particular but lots of different stuff. But before we do, I understand that you have a fairly unique way of entering in to the position that you're in now. Your journey didn't follow the traditional arc. Would you be willing to elaborate on that or tell us that story? KAYLIE: Yeah, totally. I graduated with a degree in art history, not related to computer science at all. Then right after, I moved to New York and worked for a small startup. It was marketing/business development role and I wasn't really happy with it. I was working on some design-y stuff on the side with HTML and CSS but I just felt like my brain just needed to be stimulated a little more. I applied to this all women's bootcamp program called Hackbright in San Francisco. It was a three-month intensive program and luckily coming out of that, I had at least some initial knowledge to get my foot in the door and Eventbrite was one of the hiring partners. They brought me in for interview. I actually had no idea that it was going to be a frontend engineering role because my bootcamp was totally in Python and it just had more with a backend focus. Ben, who spoke at React Boston Conference with me, was actually one of the interviewers and he gave me this Clojure problem and I solved it but in Python just using recursion. He was like, "You got it. Just convert it to JavaScript," and I was like, "No, it just can't be done. No JavaScript." But there's the reason he would chose to hire me and they onboarded me as an internal bootcamp within Eventbrite. The first three months I was there, I learned about React, Redux, JavaScript, ES6, all of that good stuff. Then they moved me to a feature team, where I continued, I guess working on the product and then I became involved more with open source projects. I really expressed interest in when you're a new engineer and coming onboard, there's all these assumed knowledge that isn't documented anywhere or something will be really obscure and hard to use but people will just assume that that's the status quo. This idea around developer experience and helping other developers move faster, it just kind of become a natural interest of mine. I was talking to the platform team, Ben in particular, expressed my interest in working in these areas. Just about like a month ago, we did a big re-org and I landed on the platform team. Currently, we have a lot of projects in flight. One of them being moving our dependency system from our old codebase, which first was written in RequireJS to webpack. We're building out our Eventbrite design system, which is basically a shared UI component library that other teams could leverage. Our platform team will just come in and make sure that the API is usable across different teams and maintain a consistent brand in terms of look and feel. We're also working on other tooling stuff like making sure we use Docker for our dev environment and making sure that the frontend containers don't break, making sure that everyone is on the same version of ESLint, Node and things like that. CHARLES: How do you make sure that the frontend containers don't break? KAYLIE: It's actually hard. I think one thing that we're trying to test right now is using Yarn Offline Mirror and having better caching. When you build a container, it'll look into the cache directory, which is just bunch of committed tarballs. That way, they don't have to fetch to the network each time because once the lockfile or package.JSON changes at our current state, it'll rebuild the entire container and it could take a very long time. We just have a lot of packages that we've added over time. Other things, we're experimenting along with our platform team on the backend side about having remote images. Instead of devs building their containers locally on their computer, having them remotely built by a CI system and then just pulling the container and the images down. CHARLES: Really, really you're like all over the place. That sounds so much fun. KAYLIE: Yeah, it's a lot of context switching. Sorry, if I was jumping too many topics at once. CHARLES: No, absolutely not. I think it's actually fascinating and it's actually capture the kind of scope because when you are doing development, if you yourself are not running up and down the stack, the tools that you use are. The better the tools, the better you're able to focus on the one little sliver of the stack that you're working on. If I don't have to worry about where are my Docker images are coming from or if there's a temporary network flip that I can't install my dependencies, if I don't have to worry about those things, then that makes me more effective so it's important to just kind of lay out all of the stuff that goes into making a quality developer experience. KAYLIE: Yeah, the dream is like frontend people wouldn't have to worry about any of the backend stuff and they just have this isolated environment, where they could just work on what they do best, which is JavaScript and writing features in React. Everything else just works and they could see that replicated through their dev environment as well as QA and Prod and hopefully, make every tooling that they use, like testing and linting all easily, intuitive and accessible. CHARLES: How is it that you're working up and down the stack, making sure that your CI systems, your Docker images but then also at the same time, working on a design system, which you've got collaboration, I assume with some pretty hard core devops teams but also then you're interfacing with designers. You kind of flesh out your design system. Are those the same people on the platform team? Or there are different groups within it? KAYLIE: We have designers and researchers actually, as part of our engineering unit. We work pretty closely with them to define guidelines on what the design system should look like because coming into making this designs system, one thing we really wanted to make sure that is that both sides of engineering and design have input, rather than the previous old version called Style Guide, which was more engineering-driven that not. One team would need a model so they would build a model and a different team would build a slightly different model and we would end up with five different models. They want to be maintained over time and there wasn't really a focus on accessibility or consistency of brand so the design system project was to eliminate all of those pain points. CHARLES: For people who may not be familiar with design system but it's something that certainly is cramping up more and more, what's the general strategy you take? Clearly, you talked about the kind of the pains that it solves, like I'm experiencing this pain where I've got five dialogues, I've got three ways of laying out forms, I've got these problems. What's the strategy that I go about as my organization for trying to implement this? Like now, I want to do a design system, where do I start? KAYLIE: One big thing, I think that helped us was developing Eventbrite design system as just the standalone product. You could run Eventbrite design system as a standalone with all of the documentation and components with each of their different props that could be configured and it has its own set of tests. All of the components are API-driven so there's nothing specific about business logic that it assumes. For example, our button component just assumes that I'll be receiving a type of submission and some [inaudible] body. It doesn't make any assumptions that it's going to be anything Eventbrite specific. It's high-level configurable that the end user wants it to be. Another thing that helped is we have a planned approach session right before we start working on a new component. A developer who would be building the component would meet with one of the frontend platform members and will be discussing the API of the component, the CSS that would go in it and the designer would do the final QA. The development takes longer than if you were to write just a component for your app but we're trying to build it out for a long term use. We have versioning for Eventbrite design system as a library so whenever you make updates, we added to the changelog and then it gets released and we bumped in Core, which is where all of our apps live and people have to get the new version. Basically, it's an orchestrated effort and we have a process built around scheduled releases and bumping it in Core. CHARLES: I get the wanting to have a uniform buttons, uniform labels, dialogs and things like that. How do you attack the problem of higher-level workflows like a form submission and validation process that might have a lot of different pathways? How do you guide that using a design system? KAYLIE: Those are actually really good questions because we went through issues like that. Validation form field or components that have logic around more complex inputs and validation is really hard because different teams use it in a slightly different way so we ended up having two versions of complex inputs. Now, we're in the process of deprecating the V1 and then having people move over to V2. We also use the Atomic Design Principles for Eventbrite design system. It means, things like atoms would be composed of buttons and we have molecules, which are slightly more complex. Then one level above that would be organisms, which are things like forms. Obviously, as you move up to like the higher level, it becomes more difficult for us to decide does this belong in EDS or does it belong with the app. There's lots of refactoring that sometimes ends up happening as a result of something built one way and us realizing later down the road that it wasn't actually very extensible and we just built it for this particular use case. Sometimes, it's the opposite where this was too generic. We can make it a little bit more specific and add more logic to it. It really depends on the component but that's been our strategy, just taking the components as needed. We're still in the earlier stages. We've released EDS a year ago and now, we're almost close to finishing it. We're just missing a handful of components. They'll be more [inaudible] that's available as opposed to adding a brand new component. CHARLES: Did you find guidance in existing design systems? One thing is why not just use one of the existing ones that's out there. Is it a matter of branding? Is it a matter of, "There are certain interactions which are unique to our product that we need to design system to capture them?" I guess my question is, if this is something I want to take on myself, what tools would I be able to reach for and what other design systems would I be able to look to versus what I have to contribute myself? What am I going to be looking for to share with the community and what am I going to look for that's develop that's uniquely mine? KAYLIE: I think consistency was a big issue. Sort of the genesis of idea came actually even before I joined the company but I think what they were going for was that we already had an existing component library called Style Guide and it wasn't really working out for us. To build like a common UI library was a natural assumption but making it better, making it more reusable. We looked at companies like Airbnb and Microsoft and I learned a lot from what they were doing. You definitely wanted some components that are specific to Eventbrite such as a ticket card or a media card that we use for our browse pages which would be needed for Eventbrite specific pages. I think mostly, the designers wanted more control because relying on third library means we don't always get what we want. We're actually thinking about making EDS open source at some point in the future, where it could take themes so other companies or individuals can leverage it but use their own theming scheme. If Spotify came and wanted to use EDS but using their colors and brand logo, then they could do so, just by layering a different configuration style to it. CHARLES: That's such an interesting idea. Is this something that you all have explored, maybe collaborating with another company? I'm trying to think what would be the benefit of making it publicly available, unless you would be getting lots of contributions back to improve EDS itself. Is that the idea? KAYLIE: Yeah. We're definitely set on making it public at some point in the future but making it open source is a different conversation because like you said, there's pros and cons that comes with open sourcing a package. We recently open source britecharts, which is a D3 library. It's been getting a lot of contributions. It's a good recruiting tool but it's also a lot of maintenance work outside of developers normal work hours. Also, we have to start worrying about like when we make a breaking change to a component, we're not just breaking it for our own product but for other developers. We currently have external developers. We have Eventbrite plugin system called Spectrum so developers are already building on top of that and they've been asking for something like this, where they could leverage and match the look and feel with the rest of the product. The downside is lots of maintenance hours and worrying about all the people that would be breaking the component for by just solving your use case. I feel like I didn't fully answer one of your questions, which was you have a different dynamic of people working on both really backend ops things, as well as a really frontend design system work. We definitely got very smart people on the team. Some people definitely have expertise in one area versus on others. Currently, we have five developers and some of us lean more towards the backend of the frontend work and I am one of those people working on things like Yarn and Docker and build system work but it's funny because I was thinking if I had a portfolio then, there wouldn't be any visual components to it, even though I'm a frontend developer. It would just be like terminal screens. We try to divide the work but everyone tries to, I guess develop, at least some shared knowledge around why we make the decisions that we do. CHARLES: It's interesting how they all intersect. I feel like the trend of the last 10 years has been to dev of all the things. I think the first thing was this artificial divide between developers and testing and that came together with the test driven development and test obsessed. Then there was this divide between developer and an ops and that divide went away now with the advent of the devops movement. Now, there's this divide between developers and design and I feel like that kind of wall is collapsing right now. You have developers participating a lot more in design and designers spending a lot more in development. We're seeing that but it's just funny how the devs starts integrating with all the things. KAYLIE: Yeah, that's a really good insight. CHARLES: You said you kind of naturally gravitate towards more of the backend doing the working with Docker, working with Yarn. How did you get actually involved with the Yarn Project? KAYLIE: Eventbrite converted over from NPM to Yarn maybe a year ago and the benefits that we got from converting over was awesome because we were manually editing NPM shrinkwrap, which is a nightmare and the installation speed of the container was really slow just because we were on NPM and it didn't really have any advance caching mechanisms at that point. Yarn just sped up a lot of things for us. I really like the user interface outside of just installing. You actually get a lot of freebie commands like 'yarn why,' that tells you why you have a particular dependency or you could do 'yarn check.' It was just a lot more helpful. I've been wanting to contribute to open source for a while so I did a little bit of work before then but the community was really encouraging when I first try to solve and pick up some first contribution bugs off of their backlog. At the time, they were pushing for 1.0 release so there's a lot of excitement about what Yarn will be and all the new features will be adding. I kept trying to pick places where I felt like I could be of help and then, Christoph, the manager of the Yarn Team and I believe [inaudible] team as well, reached out and asked if I wanted to build the selective resolution feature for them. I was like, "Yeah. I'll give it a go." Then I did it. CHARLES: What is selective resolution? KAYLIE: Good question -- CHARLES: Because I use Yarn every day and I've never heard this term. KAYLIE: It's something that became available with 1.0 release, much like workspaces and most of the time, you're not going to need it but sometimes, you're using a library. That library will have a nested dependency that for some reason, has a bug or you can't work with that package or maybe you just want to dedupe the package so that all of your dependencies end up using one version of that particular nested package. Selective resolution is like a way for you to override other libraries dependencies -- CHARLES: Oh, that's really cool. I like that because I've had that happens to me where I want some version of a library that has got a bug fix and yet, some other library that's depending is requiring this library and they're getting the old version and I'm like, "Nah!" ELRICK: That was happening to me last night. I wish I knew about this. CHARLES: Yes, seriously. KAYLIE: Yeah. Before this -- CHARLES: I'm glad we had you on justifying about this. KAYLIE: Awesome. Before this, you would have to file an issue with the original maintainer and maybe, it'll get fix. Maybe it won't or maybe you're stuck on the old version and you can't do anything about it. We had a really similar issue with the PhantomJS package, where we wanted to use a next patch version with a bug fix but then, something that was requiring it wasn't letting us use it. It works. I verified it. It seems like Facebook started using it as well so it was a pretty rewarding to work on that. CHARLES: That's exciting. I also plan on using it the next time I encounter this. ELRICK: To get this feature, is this a flag that you have to pass? How does it do the selective resolution? KAYLIE: As long as you're using Yarn 1.0 or above, you define resolutions field inside of your package.json, like how you would define that dependencies, you also have extra [inaudible] resolutions. On the left hand side, you put in a glob pattern that you want to match and if you want to match all packages, you just enter the name of the package. Then on the right side, you enter whatever version or path that you wanted to match. It could be a file or a GitHub link or it could be a version or a range or whatever you want. ELRICK: Nice. CHARLES: That's fantastic. Now, you mentioned that as you were coming to work on this, you were looking for features to work on but the community actually did a very good job of drawing you in and getting that contribution from you, which is actually pretty amazing when you think about it. I think a lot of open source projects, either flourished or failed by their ability to attract contributors. What was it that was particularly inviting? KAYLIE: It was a combination of things. I think one thing is they tried to point you to the actual code like if you want to submit a PR, then this is where you would get started. I actually started doing that myself on some of the issues. Everyone loves PRs more than issues so I think giving people filing the issues, some, I guess empowerment to try to fix it on their own, I think is great. They also have a Discord Channel for devs to talk about any questions that they might have, how to set up their initial dev environment, to test things on Yarn. Also, they were really nice. They were really thankful when I posted a PR or commented on the fix. They also use a lot of emojis, which helps. I think I personally found it really rewarding because it made me a better developer. Before contributing to Yarn, I didn't know that much about Node. For me, it was just fun to learn more about like, "This is how something else works," and also, the codebase uses a lot of different linting configurations, which I hadn't really used before so that was a nice learning curve there as well. ELRICK: For your initial time going to Yarn when you didn't know much about it, was the champion from the project that worked with you to get you over the hump or places that you were stuck or did you just have to kind of figured it out on your own or did you ask questions on the Discord Channel or in Slack Channel or anything? How did that process go initially? KAYLIE: I definitely pace myself. I just picked up easier bugs on a repos if possible and BYK and Mel who maintain the project would give guidance, especially through PR comments and they also answer any questions on issues. If I ask questions like what's the right approach here, because sometimes you get a bug and it's not just a bug. It actually has to do with philosophy of like, what should Yarn do in this case. There be like really minor edge cases like maybe NPM does that in a particular way, should Yarn respect that or should it try to be better? Those discussions are, I think really helpful and interesting and understanding what's going on. CHARLES: It's fantastic when the conversation just builds and you're learning stuff and then you actually feel like you came out with the best solution that was available to you at the end of the process. ELRICK: You gain a lot of context about the project during those conversations. CHARLES: Right. KAYLIE: Yeah, what was good about those selective resolution feature was it was completely community-driven, even from the RFC standpoint which submitted by someone in the community and then it was implemented by me, who doesn't work in Facebook. I think that's awesome. CHARLES: There's been a lot of thought that was put into the feature even before the implementation. That's always so critical to getting people's and giving them some specifications, some blueprint of what they're actually going to build. One of the things also that I wanted to touch on too is you mentioned before the show that they have a very unique take on the way they handle communication with the community, not just in terms of pull request but also in terms of issues. KAYLIE: Yarn issue count is around 800 -- CHARLES: Boy, that's a lot. I can feel daunting when you look at that, right? KAYLIE: Yeah, but it's actively [inaudible] project, a lot of people are passionate about it and there are bots that other projects use to just automatically close issues when they're not active. But something that BYK told me was when issues are closed, people take it somewhat personally and we just want to make sure that there's like a human touch to it and we, at least get to the issues without just automatically closing them. I really respect that. I think even when people are really frustrated, the maintainers never really lose their shit. They're always very graceful and when someone is acting outside of the standards of Code of Conduct, there's a gentle reminder. So far, all of the interactions that I've seen to the issues have been really constructive, rather than being like, "Sorry, we're not going to work on this." It feels like it is a community project and people care about how it's being used. It's actually not easy given all the different operating systems that Yarn has to accommodate. It's like a pretty low level tool so I give the guys a lot of kudos for handling that. CHARLES: Eight hundred issues means that with a human touch, that means 800 people have to actually respond to those issues and usually those 800 people are not actually 800 people. They're like 10 people or some number significantly below 800. How do you attack them to try and make sure that they're responded to in a timely fashion? KAYLIE: I think issue tracking is the hardest part of open source. I think it's in the order of issue tracking and then reviewing PRs and then submitting PRs because writing code is writing code but understanding other people's code is more difficult and understanding other people's issues and what the bug is, actually is even more difficult. You don't, obviously have their exact dev environment so sometimes, it's hard to repro. I think we do a lot of things that a lot of other projects leverage, which is we label the issues, we define priority if it's actually impacting a lot of people or if it's a critical bug like you can install a package versus maybe a warning message that could be tweet. Then we kept a board, like a GitHub board to track issues when we were heading for the 1.0 release. I'm not sure if we're still doing that but that helped to a degree. Other people from the community, not just the maintainers, jump in to try and help out an issue, which is probably one of the best things. Then when we merge pull requests, we close the issues that have been referenced. CHARLES: Yeah, it's really wonderful when that thing happens. I'm so curious like how to [inaudible] because I know that it's so disheartening when you're working on a project and you file an issue and maybe, it doesn't even go answered for one day, two days or two weeks or you submit a pull request and no one's even commenting on it. It can be really disheartening and kind of make you question the viability of the product itself, especially if you see a lot of activity elsewhere. On the one hand, I also understand that the maintainers are human and they probably have a lot of obligations. I know that I've got a lot of projects where I let the issues languish and I even have one that I'm using where I can't get any response and it's just so frustrating. KAYLIE: Yeah, even Yarn is definitely not perfect. There are definitely issues that sort of go buried. You could add us at YarnPackage/Core. That pings all of us and the core team. You could call out specific people but that's a tough one. CHARLES: This isn't with Yarn, by the way. It's a totally separate project. It's fantastic when there's that basic acknowledgement. It makes such a difference in people's perception of the entire enterprise. Looks like we're actually approaching time. If we want to give a special shout out to any talks you're going to be giving, any events that you'll be at or -- KAYLIE: Actually, Ben on my frontend platform team is speaking at Nodevember about Next React. I think that's where the shout out. And then Christoph will be speaking at AgentConf in Austria, I think in January about the future of dev tools. I think both things are [inaudible]. CHARLES: All right. Fantastic. ELRICK: Any slick future features coming out in Yarn that we should know about? KAYLIE: I'll keep you updated. CHARLES: She's sworn to secrecy. KAYLIE: Yeah. I'm not sure what I'm supposed to [inaudible] yet. CHARLES: I could hear the pause of conspiracy in your voice. Thank you so much, Kaylie for coming on the show. This has been a really wonderful conversation that's just gone all over the map and those are my favorite kind. Thank you very much. KAYLIE: Thank you so much for having me. This has been a lot of fun, guys. CHARLES: Well, if people want to get in touch with you, how would they go about doing that? KAYLIE: I'm a rarity, where I don't have Twitter. You can email me, I guess. CHARLES: File an issue on Yarn. KAYLIE: Yeah. I'm KaylieEB on GitHub and KaylieKwon@Gmail. CHARLES: As always, you can get in touch with us. We're at @TheFrontside on Twitter or just drop us a line on the email. You use that on occasion too at Contact@Frontside.io. Thank you, Kaylie. Thank you, Elrick and thank you for listening.

Panel: Amy Knight Charles Max Wood Special Guests:  Nick Disabato In this episode, Java Script Jabbers talk with Nick Disabato. Nick is a newbie to JavaScript Jabber. Nick is the founder of Draft, an interaction design agency where he does research driven A/B testing of E-commerce business. This is a practical episode for those who are running a business and doing marketing for the products and services. Nick talks about A/B testing for a number scenarios within the company, such as for websites, funnels, and various marketing mechanisms. Nick further goes into how this helps companies strategically increase revenue by changing things such as websites design or building funnels. In particular, we dive pretty deep on: Testing of changes of Copy, Websites, etc. What does it mean of changes, Tools, Framework, Plugins, etc Does it matter what tools you use? Framework that works within your stack How do make we company money Researching for the next test Testing for conversion rate to decide which design to go implement - Variant Responsibility for the designs Feature and getting pay for the service Learn more about the resources and Copy Hackers Large organization or developers, or a QA department Optimization teams Usability tests and coming up with A/B tests Expertise Why should be care? And much more! Links: Draft Nick Disabato @nickd ConversionXL AB Testing Manual Wider Funnels  Copy Hackers Picks: Amiee Nodevember  Charles Mike Gehard  Admin LTE Nick HotJar.com

Panel: Amy Knight Charles Max Wood Special Guests:  Nick Disabato In this episode, Java Script Jabbers talk with Nick Disabato. Nick is a newbie to JavaScript Jabber. Nick is the founder of Draft, an interaction design agency where he does research driven A/B testing of E-commerce business. This is a practical episode for those who are running a business and doing marketing for the products and services. Nick talks about A/B testing for a number scenarios within the company, such as for websites, funnels, and various marketing mechanisms. Nick further goes into how this helps companies strategically increase revenue by changing things such as websites design or building funnels. In particular, we dive pretty deep on: Testing of changes of Copy, Websites, etc. What does it mean of changes, Tools, Framework, Plugins, etc Does it matter what tools you use? Framework that works within your stack How do make we company money Researching for the next test Testing for conversion rate to decide which design to go implement - Variant Responsibility for the designs Feature and getting pay for the service Learn more about the resources and Copy Hackers Large organization or developers, or a QA department Optimization teams Usability tests and coming up with A/B tests Expertise Why should be care? And much more! Links: Draft Nick Disabato @nickd ConversionXL AB Testing Manual Wider Funnels  Copy Hackers Picks: Amiee Nodevember  Charles Mike Gehard  Admin LTE Nick HotJar.com

Panel: Amy Knight Charles Max Wood Special Guests:  Nick Disabato In this episode, Java Script Jabbers talk with Nick Disabato. Nick is a newbie to JavaScript Jabber. Nick is the founder of Draft, an interaction design agency where he does research driven A/B testing of E-commerce business. This is a practical episode for those who are running a business and doing marketing for the products and services. Nick talks about A/B testing for a number scenarios within the company, such as for websites, funnels, and various marketing mechanisms. Nick further goes into how this helps companies strategically increase revenue by changing things such as websites design or building funnels. In particular, we dive pretty deep on: Testing of changes of Copy, Websites, etc. What does it mean of changes, Tools, Framework, Plugins, etc Does it matter what tools you use? Framework that works within your stack How do make we company money Researching for the next test Testing for conversion rate to decide which design to go implement - Variant Responsibility for the designs Feature and getting pay for the service Learn more about the resources and Copy Hackers Large organization or developers, or a QA department Optimization teams Usability tests and coming up with A/B tests Expertise Why should be care? And much more! Links: Draft Nick Disabato @nickd ConversionXL AB Testing Manual Wider Funnels  Copy Hackers Picks: Amiee Nodevember  Charles Mike Gehard  Admin LTE Nick HotJar.com

Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies  Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer

Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies  Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer

Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies  Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer

Tweet this Episode Tyler Renelle is a contractor and developer who has worked in various web technologies like Node, Angular, Rails, and much more. He's also build machine learning backends in Python (Flask), Tensorflow, and Neural Networks. The JavaScript Jabber panel dives into Machine Learning with Tyler Renelle. Specifically, they go into what is emerging in machine learning and artificial intelligence and what that means for programmers and programming jobs. This episode dives into: Whether machine learning will replace programming jobs Economic automation Which platforms and languages to use to get into machine learning and much, much more... Links: Raspberry Pi Arduino Hacker News Neural Networks (wikipedia) Deep Mind Shallow Algorithms Genetic Algorithms Crisper gene editing Wix thegrid.io Codeschool Codecademy Tensorflow Keras Machine Learning Guide Andrew Ng Coursera Course Python R Java Torch PyTorch Caffe Scikit learn Tensorfire DeepLearn.js The Singularity is Near by Ray Kurzweil Tensorforce Super Intelligence by Nick Bostrom Picks: Aimee Include media Nodevember Phone cases AJ Data Skeptic Ready Player One Joe Everybody Lies Tyler Ex Machina Philosophy of Mind: Brains, Consciousness, and Thinking Machines

Tweet this Episode Tyler Renelle is a contractor and developer who has worked in various web technologies like Node, Angular, Rails, and much more. He's also build machine learning backends in Python (Flask), Tensorflow, and Neural Networks. The JavaScript Jabber panel dives into Machine Learning with Tyler Renelle. Specifically, they go into what is emerging in machine learning and artificial intelligence and what that means for programmers and programming jobs. This episode dives into: Whether machine learning will replace programming jobs Economic automation Which platforms and languages to use to get into machine learning and much, much more... Links: Raspberry Pi Arduino Hacker News Neural Networks (wikipedia) Deep Mind Shallow Algorithms Genetic Algorithms Crisper gene editing Wix thegrid.io Codeschool Codecademy Tensorflow Keras Machine Learning Guide Andrew Ng Coursera Course Python R Java Torch PyTorch Caffe Scikit learn Tensorfire DeepLearn.js The Singularity is Near by Ray Kurzweil Tensorforce Super Intelligence by Nick Bostrom Picks: Aimee Include media Nodevember Phone cases AJ Data Skeptic Ready Player One Joe Everybody Lies Tyler Ex Machina Philosophy of Mind: Brains, Consciousness, and Thinking Machines

Tweet this Episode Tyler Renelle is a contractor and developer who has worked in various web technologies like Node, Angular, Rails, and much more. He's also build machine learning backends in Python (Flask), Tensorflow, and Neural Networks. The JavaScript Jabber panel dives into Machine Learning with Tyler Renelle. Specifically, they go into what is emerging in machine learning and artificial intelligence and what that means for programmers and programming jobs. This episode dives into: Whether machine learning will replace programming jobs Economic automation Which platforms and languages to use to get into machine learning and much, much more... Links: Raspberry Pi Arduino Hacker News Neural Networks (wikipedia) Deep Mind Shallow Algorithms Genetic Algorithms Crisper gene editing Wix thegrid.io Codeschool Codecademy Tensorflow Keras Machine Learning Guide Andrew Ng Coursera Course Python R Java Torch PyTorch Caffe Scikit learn Tensorfire DeepLearn.js The Singularity is Near by Ray Kurzweil Tensorforce Super Intelligence by Nick Bostrom Picks: Aimee Include media Nodevember Phone cases AJ Data Skeptic Ready Player One Joe Everybody Lies Tyler Ex Machina Philosophy of Mind: Brains, Consciousness, and Thinking Machines

JSJ 276: Vue.js with Maximilian Schwarzmüller          This episode of JavaScript Jabber features panelists AJ O’Neal, Aimee Knight, and Charles Max Wood. They talk with special guest Maximilian Schwarzmüller about Vue.js. Tune in to find out more! [00:02:21] Introduction to Maximilian Maximilian lives in Germany and is a self-taught web developer. He mostly teaches web development on Udemy and his YouTube channel. Vue.js is just one topic that he teaches. He enjoys teaching and passing on information to other web developers: he believes it is the best thing you can do. [00:03:10] What other courses do you teach? He tries to cover basic web development topics. On Udemy Maximilian teaches Angular and generic JavaScript courses. He also teaches courses on Angular and Node.js. On his YouTube channel he teaches more back-end development and Node.js courses. [00:04:00] Elevator Pitch for Vue.js Vue.js is a new framework that is popular because it is similar to React but also has Angular features. It is easier to learn than React: not everything is in JavaScript and JXS is not included. It is more also flexible and has better performance than Angular 1. Vue.js is easier than Angular 2 both to learn and master. It is still a JavaScript framework, where developers build single page applications or drop in existing applications to enhance views, control parts of a page with JavaScript, get rid of jQuery, and have an easier time creating applications. [00:05:10] What are some challenges people run into as they learn it? If developers are brand new to Vue.js, getting started is easy. It has one thing that a lot of frameworks lack which is awesome documentation. Vuejs.org has a comprehension guide that makes getting started simple. There is a general idea that developers still need to learn of how to structure the app, which is similar to React. Developers have to learn how to build components which is used to build the application. The build template is where everything is controlled with Vue.js. JavaScript code is used as well as template syntax. [00:06:27] So you build the template and then tell it how each part is supposed to behave with JavaScript? Yes. To get started use Vue instances, which are JavaScript objects, control parts of the page and it is marked by an id on an HTML element. Then, write a Vue template, which is basically HTML code where extra features can be used to easily output a variable. It makes it much easier to control via Vue instance. Then add a code, add a method which changes the property of Vue instance. It works together and is easy to build up templates and control your page with Vue.   [00:11:12] Vue’s Advantages That depends on the application. Vue.js is easier to learn, which is an advantage when trying to get new developers. The documentation on the website is excellent, which helps when learning the language. Vue also has it’s own single team that develops it’s products, such as the Vue Router and Vue X. It has better performance, but for extremely big projects Angular 4 may be better. [00:13:38] Does Vue have routing in it? Vue.js has its own router. The core Vue team develops it, which is a different package that is downloaded separately. The advantage to this is that if you don’t need the router, then you don’t have it in your bundle but can easily add it. Once it is added it integrates nicely. [00:14:16] How does the Vue router compare to the React router? The Vue router offers the same features as the React router: nested routes, passing parameters, route guards, etc. The Vue router integrates nicely into the Vue package. It also injects into every component you have and is very simple. All that has to be done is just to execute one line of code and then the router is in the project. [00:17:10] How often is Vue.js upgraded and how hard is it to keep up? Vue.js only has two versions. Upgrading from Vue 1 to Vue 2 is easy. The base syntax and framework is still the same, you just need to adjust and move on. Since Vue 2 they released bigger upgrades. There so far haven’t been any issues upgrading, they have added new features, and still use the old code. [00:19:09] What is the feature with Vue as far as adoption goes? It is hard to predict but there are indicators that Vue.js has a good future. Vue.js probably will not overtake Angular but it is becoming important for companies in Asia, which is an important market. They have developed an Ionic version of Vue.js. There has also been an ongoing trend on GitHub. [00:21:20] Why do we keep having new frameworks and versions? The language of JavaScript itself is seeing rapid development. New features have been added, new web technologies developed, etc. One reason is that developers do more on the web. They want easier ways of building applications. There is no perfect framework so there has to be tradeoffs between the frameworks. There is no perfect solution for every application so need a framework for every application. [00:23:16] What is left undone in Vue.js? It is complete as far as something can be complete. Developers are working on service rendering to improve search engine optimization and initial rendering performance. They are also working on progress web app support.   [00:28:02] What drives the way that Vue grows? There is simplicity in their documentation. While the documentation is simple, the framework is also easy to learn. Maximilian believes that the reason Vue.js took off is because the documentation and framework work together nicely. [00:31:19] What is going to keep Vue around? The support is not based on corporation, but there is an Asian company that is developing a framework that uses Vue to with their own product. Because of this, can draw an assumption that they will keep Vue.js around. Vue.js also has a strong community and core team, giving it a good support system. [00:34:15] What are people using if they want to use Native Apps but they want to use Vue? They are having a hard time right now. Frameworks for Quasar and Weex are in the early stages. A Vue.js app needs to be built but there are packages that are working in that direction. [00:37:25] How do you structure your Udemy courses and what do you think of that as a whole? Maximilian started teaching Udemy courses about one and a half years ago. He really enjoys teaching. Each course follows a similar pattern. He starts with a rough topic, researches the topic to see what is in demand, and builds a course around projects. He then fits all the things he wants to teach into the project, plans the course curriculum, records and edits the lecture videos, and then finally releases the course. [00:39:22] What do you get the most questions about with your Vue course? Questions are mixed. Students dive into the course quickly but then pause. Most questions are about the basics. They usually have something to do with the first few sections of the course or setup problems. Picks          AJ: Broke Eatery  Dream Dinners Aimee: Julie Evans blog  Nodevember Charles: The Ketogenic Diet 2 Keto Dudes Podcast  Max: Nuxt.js Framework  Slack “Chat with yourself” Channel Links Onsen UI for Vue Twitter Youtube https://academind.com/ Utemy Vue.js Course 

JSJ 276: Vue.js with Maximilian Schwarzmüller          This episode of JavaScript Jabber features panelists AJ O’Neal, Aimee Knight, and Charles Max Wood. They talk with special guest Maximilian Schwarzmüller about Vue.js. Tune in to find out more! [00:02:21] Introduction to Maximilian Maximilian lives in Germany and is a self-taught web developer. He mostly teaches web development on Udemy and his YouTube channel. Vue.js is just one topic that he teaches. He enjoys teaching and passing on information to other web developers: he believes it is the best thing you can do. [00:03:10] What other courses do you teach? He tries to cover basic web development topics. On Udemy Maximilian teaches Angular and generic JavaScript courses. He also teaches courses on Angular and Node.js. On his YouTube channel he teaches more back-end development and Node.js courses. [00:04:00] Elevator Pitch for Vue.js Vue.js is a new framework that is popular because it is similar to React but also has Angular features. It is easier to learn than React: not everything is in JavaScript and JXS is not included. It is more also flexible and has better performance than Angular 1. Vue.js is easier than Angular 2 both to learn and master. It is still a JavaScript framework, where developers build single page applications or drop in existing applications to enhance views, control parts of a page with JavaScript, get rid of jQuery, and have an easier time creating applications. [00:05:10] What are some challenges people run into as they learn it? If developers are brand new to Vue.js, getting started is easy. It has one thing that a lot of frameworks lack which is awesome documentation. Vuejs.org has a comprehension guide that makes getting started simple. There is a general idea that developers still need to learn of how to structure the app, which is similar to React. Developers have to learn how to build components which is used to build the application. The build template is where everything is controlled with Vue.js. JavaScript code is used as well as template syntax. [00:06:27] So you build the template and then tell it how each part is supposed to behave with JavaScript? Yes. To get started use Vue instances, which are JavaScript objects, control parts of the page and it is marked by an id on an HTML element. Then, write a Vue template, which is basically HTML code where extra features can be used to easily output a variable. It makes it much easier to control via Vue instance. Then add a code, add a method which changes the property of Vue instance. It works together and is easy to build up templates and control your page with Vue.   [00:11:12] Vue’s Advantages That depends on the application. Vue.js is easier to learn, which is an advantage when trying to get new developers. The documentation on the website is excellent, which helps when learning the language. Vue also has it’s own single team that develops it’s products, such as the Vue Router and Vue X. It has better performance, but for extremely big projects Angular 4 may be better. [00:13:38] Does Vue have routing in it? Vue.js has its own router. The core Vue team develops it, which is a different package that is downloaded separately. The advantage to this is that if you don’t need the router, then you don’t have it in your bundle but can easily add it. Once it is added it integrates nicely. [00:14:16] How does the Vue router compare to the React router? The Vue router offers the same features as the React router: nested routes, passing parameters, route guards, etc. The Vue router integrates nicely into the Vue package. It also injects into every component you have and is very simple. All that has to be done is just to execute one line of code and then the router is in the project. [00:17:10] How often is Vue.js upgraded and how hard is it to keep up? Vue.js only has two versions. Upgrading from Vue 1 to Vue 2 is easy. The base syntax and framework is still the same, you just need to adjust and move on. Since Vue 2 they released bigger upgrades. There so far haven’t been any issues upgrading, they have added new features, and still use the old code. [00:19:09] What is the feature with Vue as far as adoption goes? It is hard to predict but there are indicators that Vue.js has a good future. Vue.js probably will not overtake Angular but it is becoming important for companies in Asia, which is an important market. They have developed an Ionic version of Vue.js. There has also been an ongoing trend on GitHub. [00:21:20] Why do we keep having new frameworks and versions? The language of JavaScript itself is seeing rapid development. New features have been added, new web technologies developed, etc. One reason is that developers do more on the web. They want easier ways of building applications. There is no perfect framework so there has to be tradeoffs between the frameworks. There is no perfect solution for every application so need a framework for every application. [00:23:16] What is left undone in Vue.js? It is complete as far as something can be complete. Developers are working on service rendering to improve search engine optimization and initial rendering performance. They are also working on progress web app support.   [00:28:02] What drives the way that Vue grows? There is simplicity in their documentation. While the documentation is simple, the framework is also easy to learn. Maximilian believes that the reason Vue.js took off is because the documentation and framework work together nicely. [00:31:19] What is going to keep Vue around? The support is not based on corporation, but there is an Asian company that is developing a framework that uses Vue to with their own product. Because of this, can draw an assumption that they will keep Vue.js around. Vue.js also has a strong community and core team, giving it a good support system. [00:34:15] What are people using if they want to use Native Apps but they want to use Vue? They are having a hard time right now. Frameworks for Quasar and Weex are in the early stages. A Vue.js app needs to be built but there are packages that are working in that direction. [00:37:25] How do you structure your Udemy courses and what do you think of that as a whole? Maximilian started teaching Udemy courses about one and a half years ago. He really enjoys teaching. Each course follows a similar pattern. He starts with a rough topic, researches the topic to see what is in demand, and builds a course around projects. He then fits all the things he wants to teach into the project, plans the course curriculum, records and edits the lecture videos, and then finally releases the course. [00:39:22] What do you get the most questions about with your Vue course? Questions are mixed. Students dive into the course quickly but then pause. Most questions are about the basics. They usually have something to do with the first few sections of the course or setup problems. Picks          AJ: Broke Eatery  Dream Dinners Aimee: Julie Evans blog  Nodevember Charles: The Ketogenic Diet 2 Keto Dudes Podcast  Max: Nuxt.js Framework  Slack “Chat with yourself” Channel Links Onsen UI for Vue Twitter Youtube https://academind.com/ Utemy Vue.js Course 

JSJ 276: Vue.js with Maximilian Schwarzmüller          This episode of JavaScript Jabber features panelists AJ O’Neal, Aimee Knight, and Charles Max Wood. They talk with special guest Maximilian Schwarzmüller about Vue.js. Tune in to find out more! [00:02:21] Introduction to Maximilian Maximilian lives in Germany and is a self-taught web developer. He mostly teaches web development on Udemy and his YouTube channel. Vue.js is just one topic that he teaches. He enjoys teaching and passing on information to other web developers: he believes it is the best thing you can do. [00:03:10] What other courses do you teach? He tries to cover basic web development topics. On Udemy Maximilian teaches Angular and generic JavaScript courses. He also teaches courses on Angular and Node.js. On his YouTube channel he teaches more back-end development and Node.js courses. [00:04:00] Elevator Pitch for Vue.js Vue.js is a new framework that is popular because it is similar to React but also has Angular features. It is easier to learn than React: not everything is in JavaScript and JXS is not included. It is more also flexible and has better performance than Angular 1. Vue.js is easier than Angular 2 both to learn and master. It is still a JavaScript framework, where developers build single page applications or drop in existing applications to enhance views, control parts of a page with JavaScript, get rid of jQuery, and have an easier time creating applications. [00:05:10] What are some challenges people run into as they learn it? If developers are brand new to Vue.js, getting started is easy. It has one thing that a lot of frameworks lack which is awesome documentation. Vuejs.org has a comprehension guide that makes getting started simple. There is a general idea that developers still need to learn of how to structure the app, which is similar to React. Developers have to learn how to build components which is used to build the application. The build template is where everything is controlled with Vue.js. JavaScript code is used as well as template syntax. [00:06:27] So you build the template and then tell it how each part is supposed to behave with JavaScript? Yes. To get started use Vue instances, which are JavaScript objects, control parts of the page and it is marked by an id on an HTML element. Then, write a Vue template, which is basically HTML code where extra features can be used to easily output a variable. It makes it much easier to control via Vue instance. Then add a code, add a method which changes the property of Vue instance. It works together and is easy to build up templates and control your page with Vue.   [00:11:12] Vue’s Advantages That depends on the application. Vue.js is easier to learn, which is an advantage when trying to get new developers. The documentation on the website is excellent, which helps when learning the language. Vue also has it’s own single team that develops it’s products, such as the Vue Router and Vue X. It has better performance, but for extremely big projects Angular 4 may be better. [00:13:38] Does Vue have routing in it? Vue.js has its own router. The core Vue team develops it, which is a different package that is downloaded separately. The advantage to this is that if you don’t need the router, then you don’t have it in your bundle but can easily add it. Once it is added it integrates nicely. [00:14:16] How does the Vue router compare to the React router? The Vue router offers the same features as the React router: nested routes, passing parameters, route guards, etc. The Vue router integrates nicely into the Vue package. It also injects into every component you have and is very simple. All that has to be done is just to execute one line of code and then the router is in the project. [00:17:10] How often is Vue.js upgraded and how hard is it to keep up? Vue.js only has two versions. Upgrading from Vue 1 to Vue 2 is easy. The base syntax and framework is still the same, you just need to adjust and move on. Since Vue 2 they released bigger upgrades. There so far haven’t been any issues upgrading, they have added new features, and still use the old code. [00:19:09] What is the feature with Vue as far as adoption goes? It is hard to predict but there are indicators that Vue.js has a good future. Vue.js probably will not overtake Angular but it is becoming important for companies in Asia, which is an important market. They have developed an Ionic version of Vue.js. There has also been an ongoing trend on GitHub. [00:21:20] Why do we keep having new frameworks and versions? The language of JavaScript itself is seeing rapid development. New features have been added, new web technologies developed, etc. One reason is that developers do more on the web. They want easier ways of building applications. There is no perfect framework so there has to be tradeoffs between the frameworks. There is no perfect solution for every application so need a framework for every application. [00:23:16] What is left undone in Vue.js? It is complete as far as something can be complete. Developers are working on service rendering to improve search engine optimization and initial rendering performance. They are also working on progress web app support.   [00:28:02] What drives the way that Vue grows? There is simplicity in their documentation. While the documentation is simple, the framework is also easy to learn. Maximilian believes that the reason Vue.js took off is because the documentation and framework work together nicely. [00:31:19] What is going to keep Vue around? The support is not based on corporation, but there is an Asian company that is developing a framework that uses Vue to with their own product. Because of this, can draw an assumption that they will keep Vue.js around. Vue.js also has a strong community and core team, giving it a good support system. [00:34:15] What are people using if they want to use Native Apps but they want to use Vue? They are having a hard time right now. Frameworks for Quasar and Weex are in the early stages. A Vue.js app needs to be built but there are packages that are working in that direction. [00:37:25] How do you structure your Udemy courses and what do you think of that as a whole? Maximilian started teaching Udemy courses about one and a half years ago. He really enjoys teaching. Each course follows a similar pattern. He starts with a rough topic, researches the topic to see what is in demand, and builds a course around projects. He then fits all the things he wants to teach into the project, plans the course curriculum, records and edits the lecture videos, and then finally releases the course. [00:39:22] What do you get the most questions about with your Vue course? Questions are mixed. Students dive into the course quickly but then pause. Most questions are about the basics. They usually have something to do with the first few sections of the course or setup problems. Picks          AJ: Broke Eatery  Dream Dinners Aimee: Julie Evans blog  Nodevember Charles: The Ketogenic Diet 2 Keto Dudes Podcast  Max: Nuxt.js Framework  Slack “Chat with yourself” Channel Links Onsen UI for Vue Twitter Youtube https://academind.com/ Utemy Vue.js Course 

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

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby A proposal of new concurrency model for Ruby 3 by Koichi Sasada, Five Rails Gotchas и Vim 8.0 released Ruby's Swiss Army Knife: The Enumerable Module, When abstraction is a mistake: ActionController::TestCase и Ruby Gems Could Harm Your Memory How Elixir helped us scale our Video User Profile Service for the Olympics, Unique partial indexes with PostgreSQL и Sneakers Exponential Retry Handler JavaScript Farewell to Node.js v5, Preparing for v7, Announcing Quill 1.0 и Stepping down as Nodevember organizer Node.js Best Practices, NaN and typeof и Oh shit, git! Awesome Grid - a curated list of grid(table) libraries and resources, Cookies.js - super simple cookie manipulation и Radiobox.css - a tiny set of CSS3 animations designed for your radio inputs

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)

Jason Myers came on the show to talk about his experiences running not one but TWO conferences in the Nashville, Tennessee area, along with how he ended up writing a book about a popular Python database abstraction tool, and why he prefers the hermetic lifestyle. Along the way Chris and Jason also managed to beat a dead horse for a few minutes. Special offer for listeners! Get 50% off Backup Pro’s CMS plugins by using the promo code devhell! And get trials of Backup Pro for ExpressionEngine 2, ExpressionEngine 3, Craft, WordPress, PrestaShop, and Concrete5! Also! Listeners can get a 50% discount on Jason Myers' book Essential SQLAlchemy, 2nd Edition! Discount will show when you add it to your cart. Go buy it now! Do these things! Check out our sponsors Backup Pro and WonderNetwork Buy stickers at devhell.info/shop Follow us on Twitter here Rate us on iTunes here Listen Download now (MP3, 68.4MB, 1:35:57) Links and Notes Jason on Twitter Jason’s book on SQLAlchemy PyTennessee Nodevember PyGotham PyOhio Adam Culp’s write-up about SunshinePHP and CoC violations Maus PHP Conference Australia The Combine Kalamazoo X OSMIHelp

Check out JS Remote Conf!   02:22 - Elijah Manor Introduction Twitter GitHub Blog LeanKit Eliminate JavaScript Code Smells (Elijah's Talk Abstract) A video containing the 30 min version of the talk: Eliminate JavaScript Code Smells The full slides (60 mins worth of material) 04:49 - What is a “Code Smell”? Martin Fowler: CodeSmell ESLint JSHint 10:21 - Copy/Paste Code Error jsinspect and jscpd ES6, ES7, Babel Support 13:11 - Using ES6 to Eliminate Code Smells 15:48 - Refactoring Case Statements The Strategy Pattern 21:29 - Juniors and Code Smells Code Reviews 27:29 - Isomorphic Code 31:12 - Framework Code Smells 33:47 - Identifying New Code Smells 36:33 - When Code Smells are OK 39:10 - Why use parameters? Picks Terms And Conditions May Apply (AJ) Nodevember (Aimee) Developer Tea (Aimee) Jake Shimabukuro (Joe) Screeps (Joe) react-styleguide-generator (Elijah) react-styleguidist (Elijah) The Phantom Menace - What it Should Have Been (AJ) Attack of the Clones - What it Should Have Been (AJ)

Check out JS Remote Conf!   02:22 - Elijah Manor Introduction Twitter GitHub Blog LeanKit Eliminate JavaScript Code Smells (Elijah's Talk Abstract) A video containing the 30 min version of the talk: Eliminate JavaScript Code Smells The full slides (60 mins worth of material) 04:49 - What is a “Code Smell”? Martin Fowler: CodeSmell ESLint JSHint 10:21 - Copy/Paste Code Error jsinspect and jscpd ES6, ES7, Babel Support 13:11 - Using ES6 to Eliminate Code Smells 15:48 - Refactoring Case Statements The Strategy Pattern 21:29 - Juniors and Code Smells Code Reviews 27:29 - Isomorphic Code 31:12 - Framework Code Smells 33:47 - Identifying New Code Smells 36:33 - When Code Smells are OK 39:10 - Why use parameters? Picks Terms And Conditions May Apply (AJ) Nodevember (Aimee) Developer Tea (Aimee) Jake Shimabukuro (Joe) Screeps (Joe) react-styleguide-generator (Elijah) react-styleguidist (Elijah) The Phantom Menace - What it Should Have Been (AJ) Attack of the Clones - What it Should Have Been (AJ)

Check out JS Remote Conf!   02:22 - Elijah Manor Introduction Twitter GitHub Blog LeanKit Eliminate JavaScript Code Smells (Elijah's Talk Abstract) A video containing the 30 min version of the talk: Eliminate JavaScript Code Smells The full slides (60 mins worth of material) 04:49 - What is a “Code Smell”? Martin Fowler: CodeSmell ESLint JSHint 10:21 - Copy/Paste Code Error jsinspect and jscpd ES6, ES7, Babel Support 13:11 - Using ES6 to Eliminate Code Smells 15:48 - Refactoring Case Statements The Strategy Pattern 21:29 - Juniors and Code Smells Code Reviews 27:29 - Isomorphic Code 31:12 - Framework Code Smells 33:47 - Identifying New Code Smells 36:33 - When Code Smells are OK 39:10 - Why use parameters? Picks Terms And Conditions May Apply (AJ) Nodevember (Aimee) Developer Tea (Aimee) Jake Shimabukuro (Joe) Screeps (Joe) react-styleguide-generator (Elijah) react-styleguidist (Elijah) The Phantom Menace - What it Should Have Been (AJ) Attack of the Clones - What it Should Have Been (AJ)

Sign up for JS Remote Conf!   Dan and Andrew's super awesome, helpful document that they made for the show during preparation 03:22 - Andrew Clark Introduction Twitter GitHub OpenGov flummox 03:39 - Dan Abramov Introduction Twitter GitHub JavaScript Jabber Episode #179: redux and React with Dan Abramov 04:03 - Flux Flux vs MVC 09:36 - Data Flow Why FluxComponent > fluxMixin Mixins Are Dead. Long Live Composition.   Higher-order Components Sebastian Markbåge's Tweet 22:52 - Conceptualizing React and Flux React.js Conf 2015 - Flux Panel Does redux limit ambiguity that exists in Flux? 27:50 - Documentation 30:38 - The Elm Programming Language 32:34 - Making Patterns Explicit in Frameworks Tom Dale @ TXJS 2015 Let a 1,000 flowers bloom. Then rip 999 of them out by the roots. Sebastian Markbåge: Minimal API Surface Area @ JSConf EU 2014 36:31 - Getting Started with React and Flux Classes 42:42 - Where Flux Falls Short 58:23 - Keeping the Core Small; Making Decisions Picks Strange Loop 2015 Videos  (Jamison) Typeset In The Future (Jamison) Open-source as a project model for internal work (w/ speaker notes) by Kevin Lamping (Jamison) Explanation of Zipf's Law (Dave) Will Conant's talk at UtahJS 2015 on Flux (Dave) The Legend of ZERO (3 Book Series) by Sara King (Joe) Camel Up (Joe) The Elm Programming Language (Joe) Boundaries: A talk by Gary Bernhardt from SCNA 2012 (Aimee) Nodevember (Aimee) TV Fool (Chuck) RCA Outdoor Digital HDTV VHF UHF Yagi Type Antenna (Chuck) The Michael Vey Book Series (Chuck) BusinessTown (Dan) Elon Musk: The World’s Raddest Man (Dan) Professor Frisby's Mostly Adequate Guide to Functional Programming (Dan) Abiogenesis (Dan) react-future (Dan) The Righteous Mind (Andrew) lodash-fp (Andrew) Inside Amy Schumer (Andrew) dataloader (Andrew) Careers at OpenGov (Andrew)

Sign up for JS Remote Conf!   Dan and Andrew's super awesome, helpful document that they made for the show during preparation 03:22 - Andrew Clark Introduction Twitter GitHub OpenGov flummox 03:39 - Dan Abramov Introduction Twitter GitHub JavaScript Jabber Episode #179: redux and React with Dan Abramov 04:03 - Flux Flux vs MVC 09:36 - Data Flow Why FluxComponent > fluxMixin Mixins Are Dead. Long Live Composition.   Higher-order Components Sebastian Markbåge's Tweet 22:52 - Conceptualizing React and Flux React.js Conf 2015 - Flux Panel Does redux limit ambiguity that exists in Flux? 27:50 - Documentation 30:38 - The Elm Programming Language 32:34 - Making Patterns Explicit in Frameworks Tom Dale @ TXJS 2015 Let a 1,000 flowers bloom. Then rip 999 of them out by the roots. Sebastian Markbåge: Minimal API Surface Area @ JSConf EU 2014 36:31 - Getting Started with React and Flux Classes 42:42 - Where Flux Falls Short 58:23 - Keeping the Core Small; Making Decisions Picks Strange Loop 2015 Videos  (Jamison) Typeset In The Future (Jamison) Open-source as a project model for internal work (w/ speaker notes) by Kevin Lamping (Jamison) Explanation of Zipf's Law (Dave) Will Conant's talk at UtahJS 2015 on Flux (Dave) The Legend of ZERO (3 Book Series) by Sara King (Joe) Camel Up (Joe) The Elm Programming Language (Joe) Boundaries: A talk by Gary Bernhardt from SCNA 2012 (Aimee) Nodevember (Aimee) TV Fool (Chuck) RCA Outdoor Digital HDTV VHF UHF Yagi Type Antenna (Chuck) The Michael Vey Book Series (Chuck) BusinessTown (Dan) Elon Musk: The World’s Raddest Man (Dan) Professor Frisby's Mostly Adequate Guide to Functional Programming (Dan) Abiogenesis (Dan) react-future (Dan) The Righteous Mind (Andrew) lodash-fp (Andrew) Inside Amy Schumer (Andrew) dataloader (Andrew) Careers at OpenGov (Andrew)

Sign up for JS Remote Conf!   Dan and Andrew's super awesome, helpful document that they made for the show during preparation 03:22 - Andrew Clark Introduction Twitter GitHub OpenGov flummox 03:39 - Dan Abramov Introduction Twitter GitHub JavaScript Jabber Episode #179: redux and React with Dan Abramov 04:03 - Flux Flux vs MVC 09:36 - Data Flow Why FluxComponent > fluxMixin Mixins Are Dead. Long Live Composition.   Higher-order Components Sebastian Markbåge's Tweet 22:52 - Conceptualizing React and Flux React.js Conf 2015 - Flux Panel Does redux limit ambiguity that exists in Flux? 27:50 - Documentation 30:38 - The Elm Programming Language 32:34 - Making Patterns Explicit in Frameworks Tom Dale @ TXJS 2015 Let a 1,000 flowers bloom. Then rip 999 of them out by the roots. Sebastian Markbåge: Minimal API Surface Area @ JSConf EU 2014 36:31 - Getting Started with React and Flux Classes 42:42 - Where Flux Falls Short 58:23 - Keeping the Core Small; Making Decisions Picks Strange Loop 2015 Videos  (Jamison) Typeset In The Future (Jamison) Open-source as a project model for internal work (w/ speaker notes) by Kevin Lamping (Jamison) Explanation of Zipf's Law (Dave) Will Conant's talk at UtahJS 2015 on Flux (Dave) The Legend of ZERO (3 Book Series) by Sara King (Joe) Camel Up (Joe) The Elm Programming Language (Joe) Boundaries: A talk by Gary Bernhardt from SCNA 2012 (Aimee) Nodevember (Aimee) TV Fool (Chuck) RCA Outdoor Digital HDTV VHF UHF Yagi Type Antenna (Chuck) The Michael Vey Book Series (Chuck) BusinessTown (Dan) Elon Musk: The World’s Raddest Man (Dan) Professor Frisby's Mostly Adequate Guide to Functional Programming (Dan) Abiogenesis (Dan) react-future (Dan) The Righteous Mind (Andrew) lodash-fp (Andrew) Inside Amy Schumer (Andrew) dataloader (Andrew) Careers at OpenGov (Andrew)

02:14 - 15 Minute Podcast Listener chat with Charles Wood 03:23 - Amy’s Upcoming Talk at Nodevember 04:45 - Junior, Mid-level, and Senior Developers 08:00 - Advice for Devs Straight Out of Boot Camp (How Job Hunts Work) 14:28 - Looking For the Right Job For YOU The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler 23:22 - Mentorship & Company Culture 27:16 - Nailing the Interview Salary Expectations Get to Know Potential Team Members Confidence 32:57 - Be Prepared: Coding is HARD Work 35:27 - Getting To Know People & Networking Hackathons Open Source Contribution Don’t Be Afraid … APPLY! Apprenticeships Saron Yitbarek: CodeNewbie Conferences 46:45 - Communication and People Skills Conway’s Law Get in touch with Aimee or Chuck! Tweet @cmaxw Fork Aimee’s Ask Me Anything! Picks JS Remote Conf (Chuck) Rails Remote Conf (Chuck) Remote Conference Talks (Chuck) Standing Desks (Aimee) We have a problem with promises (Aimee) Interview Cake (Aimee) Nodevember (Aimee) A standing desk for $22 (Chuck) SmartCells Anti-Fatigue Comfort Mat (Chuck) Pebble Time (Chuck) Pebble.js (Chuck)

02:14 - 15 Minute Podcast Listener chat with Charles Wood 03:23 - Amy’s Upcoming Talk at Nodevember 04:45 - Junior, Mid-level, and Senior Developers 08:00 - Advice for Devs Straight Out of Boot Camp (How Job Hunts Work) 14:28 - Looking For the Right Job For YOU The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler 23:22 - Mentorship & Company Culture 27:16 - Nailing the Interview Salary Expectations Get to Know Potential Team Members Confidence 32:57 - Be Prepared: Coding is HARD Work 35:27 - Getting To Know People & Networking Hackathons Open Source Contribution Don’t Be Afraid … APPLY! Apprenticeships Saron Yitbarek: CodeNewbie Conferences 46:45 - Communication and People Skills Conway’s Law Get in touch with Aimee or Chuck! Tweet @cmaxw Fork Aimee’s Ask Me Anything! Picks JS Remote Conf (Chuck) Rails Remote Conf (Chuck) Remote Conference Talks (Chuck) Standing Desks (Aimee) We have a problem with promises (Aimee) Interview Cake (Aimee) Nodevember (Aimee) A standing desk for $22 (Chuck) SmartCells Anti-Fatigue Comfort Mat (Chuck) Pebble Time (Chuck) Pebble.js (Chuck)

02:14 - 15 Minute Podcast Listener chat with Charles Wood 03:23 - Amy’s Upcoming Talk at Nodevember 04:45 - Junior, Mid-level, and Senior Developers 08:00 - Advice for Devs Straight Out of Boot Camp (How Job Hunts Work) 14:28 - Looking For the Right Job For YOU The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler 23:22 - Mentorship & Company Culture 27:16 - Nailing the Interview Salary Expectations Get to Know Potential Team Members Confidence 32:57 - Be Prepared: Coding is HARD Work 35:27 - Getting To Know People & Networking Hackathons Open Source Contribution Don’t Be Afraid … APPLY! Apprenticeships Saron Yitbarek: CodeNewbie Conferences 46:45 - Communication and People Skills Conway’s Law Get in touch with Aimee or Chuck! Tweet @cmaxw Fork Aimee’s Ask Me Anything! Picks JS Remote Conf (Chuck) Rails Remote Conf (Chuck) Remote Conference Talks (Chuck) Standing Desks (Aimee) We have a problem with promises (Aimee) Interview Cake (Aimee) Nodevember (Aimee) A standing desk for $22 (Chuck) SmartCells Anti-Fatigue Comfort Mat (Chuck) Pebble Time (Chuck) Pebble.js (Chuck)

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)

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:20 - Zach Kessin Introduction Twitter GitHub Zach's Books Parrot JavaScript Jabber: Episode #057: Functional Programming with Zach Kessin Testing Erlang With Quickcheck Book 04:00 - Mostly Erlang Podcast 05:27 - Property-based Testing (QuickCheck) 07:22 - Property-based Testing and Functional Programming jsverify 09:48 - Pure Functions Shrinking 18:09 - Boundary Cases 20:00 - Generating the Data 23:23 - Trending Concepts in JavaScript 32:33 - How Property-based Testing Fits in with Other Kind of Testing 35:57 - Test Failures Panel Nolan Lawson: Taming the asynchronous beast with ES7 (Aimee) Nodevember (Aimee) Hipster Sound (Jamison) Om Next by David Nolen  (Jamison) Gallant - Weight In Gold (Jamison) React Rally (Jamison) Better Off Ted (Joe) Armada: A Novel by Ernest Cline (Joe) Testing Erlang With Quickcheck Book (Zach) Parrot Universal Notification Interface (Zach) The Famine of Men by Richard H. Kessin (Zach)

02:20 - Zach Kessin Introduction Twitter GitHub Zach's Books Parrot JavaScript Jabber: Episode #057: Functional Programming with Zach Kessin Testing Erlang With Quickcheck Book 04:00 - Mostly Erlang Podcast 05:27 - Property-based Testing (QuickCheck) 07:22 - Property-based Testing and Functional Programming jsverify 09:48 - Pure Functions Shrinking 18:09 - Boundary Cases 20:00 - Generating the Data 23:23 - Trending Concepts in JavaScript 32:33 - How Property-based Testing Fits in with Other Kind of Testing 35:57 - Test Failures Panel Nolan Lawson: Taming the asynchronous beast with ES7 (Aimee) Nodevember (Aimee) Hipster Sound (Jamison) Om Next by David Nolen  (Jamison) Gallant - Weight In Gold (Jamison) React Rally (Jamison) Better Off Ted (Joe) Armada: A Novel by Ernest Cline (Joe) Testing Erlang With Quickcheck Book (Zach) Parrot Universal Notification Interface (Zach) The Famine of Men by Richard H. Kessin (Zach)

02:20 - Zach Kessin Introduction Twitter GitHub Zach's Books Parrot JavaScript Jabber: Episode #057: Functional Programming with Zach Kessin Testing Erlang With Quickcheck Book 04:00 - Mostly Erlang Podcast 05:27 - Property-based Testing (QuickCheck) 07:22 - Property-based Testing and Functional Programming jsverify 09:48 - Pure Functions Shrinking 18:09 - Boundary Cases 20:00 - Generating the Data 23:23 - Trending Concepts in JavaScript 32:33 - How Property-based Testing Fits in with Other Kind of Testing 35:57 - Test Failures Panel Nolan Lawson: Taming the asynchronous beast with ES7 (Aimee) Nodevember (Aimee) Hipster Sound (Jamison) Om Next by David Nolen  (Jamison) Gallant - Weight In Gold (Jamison) React Rally (Jamison) Better Off Ted (Joe) Armada: A Novel by Ernest Cline (Joe) Testing Erlang With Quickcheck Book (Zach) Parrot Universal Notification Interface (Zach) The Famine of Men by Richard H. Kessin (Zach)

In this episode of CG Talks, Marco, DJ and Michal sit down with Erin Woodford of Erindale fame. Erin is an artist, designer and entrepreneur specializing in creating procedural objects and surfaces in Blender. We learn about his discovery of procedural design and the experience he's had on the journey so far. Erin also demystifies proceduralism and explains how despite the nuances in this workflow calling for a less intuitive or conventionally artistic mindset, it isn't something reserved for people with coding experience or mathematical thinkers. If you've been curious but apprehensive about learning proceduralism, this episode is for you. Procedural workflows are certainly key for the future of CG so if you want to jump on the bandwagon, it's about time (and lots of fun anyway)! This might just be the thing that motivates you into participating in next year's Nodevember! Resources: Erin Woodford Youtube -https://www.youtube.com/channel/UCGMyyn2FdEFcDfP1wQRh5lQ Erin Woodford - https://www.artstation.com/erindale Prodesktop CAD tool - https://en.wikipedia.org/wiki/Pro/DESKTOP Nodevember 2020 results video - https://www.youtube.com/watch?v=JhLVzcCl1ug Nodevember website - https://nodevember.io CG Matter tutorials - https://www.youtube.com/channel/UCy1f4m64dwCwk8CBZ_vHfPg Erin's Discord server - discord.gg/qEmdVC3 Gabe interview - https://www.youtube.com/watch?v=r9Kpv8M4MxM&feature=emb_logo Future Systems architecture - https://www.dezeen.com/tag/future-systems/ Artlantis - https://artlantis.com/en/ Enscape - https://enscape3d.com Eevee renderer - https://www.youtube.com/watch?v=e-9rYUwY47Y Grasshopper - https://www.grasshopper3d.com Houdini basics tutorial - https://www.youtube.com/watch?v=Tsv8UGqDibc Bifrost Maya - https://www.youtube.com/watch?v=Tsv8UGqDibc Sverchok addon for Blender - https://www.youtube.com/watch?v=1UA_A-LLolw Plant Factory - https://info.e-onsoftware.com/more-info-plantfactory Mandelbulb 3D - https://www.mandelbulb.com Erindale Art Deco video - https://www.youtube.com/watch?v=8m8LeMBMwAg Simon Thommes - https://www.artstation.com/simonthommes Gumroad - https://gumroad.com blenderBinge Youtube channel - https://www.youtube.com/channel/UCrXMyWVRmiXdMTpxxCsPuCQ Gabe CG Matter website - https://www.cgmatter.com Scripting for Artists Sybren A. Stüvel - https://www.youtube.com/watch?v=sOS2ID1ZN3A AI proceduralism Kate Compton presentation - https://www.youtube.com/watch?v=WumyfLEa6bU Blender Python scripting beginner tutorial - https://www.youtube.com/watch?v=cyt0O7saU4Q LSystems in Animation nodes Blender - https://www.youtube.com/watch?v=-tsBZp5T2CU HERO – Blender Grease Pencil Showcase - https://www.youtube.com/watch?v=pKmSdY56VtY Blender Tissue addon - https://www.youtube.com/watch?v=IoQtC9qnX1Y Cell Fracturing Blender - https://www.youtube.com/watch?v=T2nsntEzlAw