Podcast appearances and mentions of robert deluca

Guests: Amanda Hickman: @amandabee | GitHub Amberley Romo: @amberleyjohanna | GitHub | Blog In this episode, Amanda Hickman and Amberley Romo talk about how they paired up to get the safety pin, spool of thread, and the knitting yarn and needles emojis approved by the Unicode Committee so that now they are available for use worldwide. They also talk about how their two path crossed, how you can pitch and get involved in making your own emojis, and detail their quest to get a regular sewing needle approved as well. Resources: Unicode Technical Committee Draft Emoji Candidates The Unicode Consortium Members Sewing-Emoji Repo Proposal for Sewing NEEDLE AND THREAD Emoji This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: ROBERT: Hello, everyone. Welcome to Episode 112 of The Frontside Podcast. I'm Robert DeLuca, a software developer here at the Frontside and I'll be your episode host. With me as co-host is Charles Lowell. Hey, Charles. CHARLES: Hello, Robert. Good morning. ROBERT: Good morning. This is an exciting podcast. Today, we're going to be discussing writing a proposal to the Unicode Committee, getting it accepted and rejected. This is basically making emojis which I think is really awesome. We have two guests today who have an amazing story, Amanda Hickman and Amberley Romo. Thank you both for joining us. You two have an amazing story that I would really love to dive into and we're going to do that today. It's about basically creating your own emoji and getting that accepted so everybody can use that and I think that's super, super cool, something that I've always kind of wanted to do as a joke and it seems like that's kind of where your stories began, so you two want to jump in and start telling? I think Amanda has a great beginning to this. AMANDA: Sure. I mean, hi and thanks for having me. I don't know where to begin and really for me, this starts with learning to sew my own clothes which is an incredibly exasperating and frustrating process that involves a lot of ripping stitches back out and starting over and Instagram was a really big part of me finding patterns and finding other people who are sewing their own clothes and learning from the process. I wanted to be able to post stuff on Instagram and it started to drive me absolutely crazy, that there's emojis for wrenches and nuts and hammers and there are no textile emoji. The best I could find was scissors which is great because cutting patterns is a place where I spend a lot of time procrastinating but that was it. I knew a woman, Jennifer 8 Lee or Jenny who had led a campaign to get the dumpling emoji into the Unicode character set. I knew she'd succeeded in that but I didn't really know much more about how that had worked. I started thinking I'm going write a sewing emoji. I can do this. I can lead this campaign. I started researching it and actually reached out to Jenny and I discovered that she has created an entire organization called... What was that called? She's created an entire organization called Emojination, where she supports people who want to develop emoji proposals. CHARLES: Before you actually found the support system, you actually made the decision that you were going to do this and you found it. You know, from my perspective, I kind of see emoji is this thing that is static, it's there, it's something that we use but the idea that I, as an individual, could actually contribute to that. I probably, having come to that fork in the road would have said, "Nah, it's just it is what it is and I can't change it." What was the process in your mind to actually say, "You know what? I'm actually going to see if I can have some effect over this process?" AMANDA: It definitely started with a lot of anger and being just consistently frustrated but I knew that someone else had already done this. It was sort of on my radar that it was actually possible to change the emoji character set. I think that if I didn't know Jenny's story and it turned out I didn't know Jenny story at all but I thought I knew Jenny story but if I didn't know that basic thing that that somebody I knew who was a mere mortal like me had gone to the Emoji Subcommittee of the Unicode Consortium and petition them to add a dumpling emoji, I am sure that I wouldn't bother. But I knew from talking to her that there was basically a process and that there were a format that they want proposal in and it's possible to write them a proposal. I knew that much just because I knew Jenny. I think at that point, when I started thinking about this, the Emoji 9 -- I should be more of an expert on that actually, on emoji releases but a new release of emoji had come out. There were a bunch of things in that release and it got a little bit of traction on Twitter. I knew that the Unicode Consortium had just announced a whole new slate of emoji, so I also was generally aware that there was some kind of process by which emoji were getting released and expanded and updated. ROBERT: That's interesting. Do you know when that started? Because it seems like Apple started to add more emojis around like iOS 7 or something but it was pretty static for a while right? Or am I wrong? AMANDA: I actually am tempted to look this up but the other piece that is not irrelevant here is that at the time, I was working at a news organization called BuzzFeed that you may have heard of -- ROBERT: Maybe, I don't know. It sounds kind of familiar. AMANDA: I do feel like people kind of know who they are. I was surrounded by emoji all the time: in BuzzFeed, in internet native of the highest order and we had to use emoji all the time and I had to figure out how to get emoji into blog post which I didn't really know how to do before that. I can put them on my phone but that was it. I was immersed in emoji already. I knew that there was a project called Emojipedia, that was a whole kind of encyclopedia of emoji. One of my colleagues at BuzzFeed, a woman named Nicole Nguyen had written a really great article about the variation in the dance emoji. If you look at the dance emoji, one of the icons that some devices use is this kind of woman with her skirt flipping out behind her that looks like she's probably dancing a tango and then one of the icons that other character sets use and other devices use is a sort of round, yellow lumping figure with a rose in its mouth that you sort of want to hug but it's definitely not to impress you with its tango skill. She had written this whole article about how funny it was that you might send someone this very cute dumpling man with [inaudible] and what they would see was sexy tango woman. I think there was some discussion, it was around that time also that Apple replaced the gun emoji with a water gun. There was some discussion of the direction that the various emoji's face. One of the things that I learned around that time was that every device manufacturer produces their own character set that's native to their devices and they look very different. That means that there's a really big difference between putting a kind of like frustrated face with a gun pointing at it, which I don't really think of it as very funny but that sort of like, "I'm going to shoot myself" is very different from pointing the gun the other way which is very much like, "I'm shooting someone else," so these distinctions, what it means that the gun emoji can point two different ways when it gets used was also a conversation that was happening. None of that answers your question, though which is when did the kind of rapid expanse of emoji start to happen. ROBERT: I feel like the story is setting in the place there, though because it seems like there's a little bit of tension there that we're all kind of diverging here a little bit and it's sort of driving back towards maybe standardization. AMANDA: There's actually, as far as I know, no real move toward standardization but the Unicode Consortium has this committee that actually has representatives from definitely Apple and Microsoft and Google and I forget who else on the consortium. Jenny 8 Lee is now on the consortium and she's on the Emoji Subcommittee but they actually do get together and debate the merits of adding additional emoji, whether they're going to be representative. One of the criteria is longevity and I tend to think of this as the pager problem. There is indeed a pager emoji and I think that the Unicode Consortium wants to avoid approving a pager emoji because that was definitely a short-lived device. CHARLES: Right. I'm surprised that it actually made it. Emoji must be older than most people realize. AMANDA: My understanding is that very early Japanese computers had lots emoji. There's a lot of different Japanese holidays that are represented in emoji, a lot of Japanese food as well are represented in emoji, so if you look through the foods, there's a handful of things that haven't added recently but a lot of the original emoji definitely covered Japanese cuisine very well. ROBERT: I definitely remember when I got my first iPhone that could install iPhone OS 2, you would install an app from the App Store that then would allow you to go toggle on the emoji keyboard but you had to install an app to do it and that's kind of where the revolution started, for me at least. I remember everybody starting to sending these things around. AMANDA: But if you look at Emojipedia, which has a nice kind of rundown of historical versions of the Unicodes, back in 1999, they added what I think of as the interrobang, which is the exclamation/question mark together and a couple of different Syriac crosses. Over the years, the committee has added a whole series of wording icons and flags that all make sense but then, it is around, I would say 2014, 2015 that you start to get the zipper mouth and rolling your eyes and nerd face and all of the things that are used in conversation now -- the unicorn face. ROBERT: My regular emojis. AMANDA: Exactly. CHARLES: It certainly seems like the push to put more textile emoji ought to clear the hurdle for longevity, seeing there's kind of like, what? Several millennia of history there? And just kind of how tightly woven -- pun intended -- those things are into the human experience, right? AMANDA: Definitely. Although technically, there's still no weaving emojis. CHARLES: There's no loom? AMANDA: There's no loom and I think that a loom would be pretty hard to represent in a little 8-bit graphic but -- CHARLES: What are the constraints around? Because ultimately, we've already kind of touched on that the emoji themselves, their abstract representations and there are a couple of examples like the dancing one where the representation can vary quite widely. How do they put constraints around the representation versus the abstract concept? AMANDA: You don't have to provide a graphic but it definitely kind of smooths the path if you do and it has to be something that's representable in that little bitty square that you get. It has to be something representable in a letter-size square. If it's not something that you can clearly see at that size, it's not going to be approved. If it's not something you can clearly illustrate at that size in a way that's clearly distinct from any other emoji and also that's clearly distinct from anything else of that image could be, it's not going to be approved. Being able to actually represented in that little bitty size and I don't know... One of sort of sad fact of having ultimately worked with Emojination on the approval process is that we were assigned an illustrator and she did some illustrations for us and I never had to look at what the constraints were for the illustration because it wasn't my problem. ROBERT: Sometimes, that's really nice. AMANDA: Yes, it's very nice. I ended up doing a lot of research. What made me really sad and I don't want to jump too far ahead but one of things that made me really sad is we proposed the slate and the one thing that didn't get approved was the sewing needle and it also didn't get rejected, so it's in the sort of strange nether space. That's kind of stuck in purgatory right now. I did all this research and learned that the oldest known sewing needle is a Neanderthal needle so it predates Homo sapiens and it's 50,000 years old. CHARLES: Yeah. Not having a sewing needle just seem absurd. AMANDA: Yeah. We have been sewing with needles since before we were actually human being. ROBERT: That's a strong case. AMANDA: Yes, that's what I thought. If I sort go back to my narrative arc, I wanted to do a sewing needle and started researching it a little bit -- CHARLES: Sorry to keep you interrupting but that's literally the one that started this whole journey. AMANDA: Yes, I wanted a sewing needle and I really wanted a sewing needle. I did a little research and then I reach out to Jenny and to ask her if she had any advice. She said, "You should join my Slack," and I was like, "Oh, okay. That's the kind of advice." She and I talked about it and she said that she thought that it made more sense to propose a kind of bundle of textile emoji and I decided to do that. She and I talked it through and I think the original was probably something closer to knitting than yarn but we said knitting, a safety pin, thread and needle were the ones that kind of made the most sense. I set about writing these four proposals and one of the things that they asked for was frequently requested. One other thing that I will say about the proposal format is that they have this outline structure that is grammatically very wonky. They ask you to assert the images distinctiveness and they also ask you to demonstrate that it is frequently requested. I found a couple of really interesting resources. One, Emojipedia which is this sort of encyclopedia of emoji images and history maintains a list of the top emoji requests. I actually don't know how they generate that list or who's requesting that and where but I think it's things that they get emailed about and things people request in other contexts and sewing and knitting, I've done on that list and I started compiling it in 2016. ROBERT: To be a part of the proposal process, to show that it is requested, without that resource, you just start scouring Facebook and Twitter and history and shouting to people like, "I really want this emoji. Why it didn't exist?" That seems pretty hard. AMANDA: Actually our proposals all have Twitter screen shots of people grousing about the absence of knitting emoji and yarn emoji and sewing emoji. I know that Emojipedia, they do a bunch of research so they go out and look at based what people are grousing about on Twitter. They look at places where people are publicly saying like, "It's crazy that there's no X emoji," and that's part of their process for deciding what kinds of emojis people are asking for. Their research was one resource but we took screenshots of people saying that they needed a safety pin emoji and that was part of making the case. One of the things that I found as I was doing that research was that, I guess at this point it was almost two years ago, when the character set that included the dumpling emoji came out, there was a bunch of grousing from people saying, "Why is there not a yarn emoji?" There was a writing campaign that I think Lion Brand had adopted. Lion Brand yarn had put in this tweet saying like, "Everyone should complain. We needed a yarn emoji," but it doesn't matter how much you yell on Twitter. If you don't actually write a proposal, you're not going to get anywhere. I had been told that the Emoji Subcommittee, they're really disinclined to accept proposals that had a corporate sponsor, so they weren't going to create a yarn emoji because Lion Brand yarns wanted them to create a yarn emoji. ROBERT: Right, so it was like counter-peer proposal. AMANDA: Right. But as I was digging around the other thing I found was this woman in... I actually don't know if you're in Dallas or Austin but I found Amberley, who also put a post on Twitter and had started a petition, asking people to sign her petition for a yarn emoji proposal or a knitting emoji. I don't remember if it was a yarn emoji or a knitting emoji but I found her petition and reached out to her to ask if she was interested in co-authoring the proposal with me because she had clearly done the work. She actually had figured out how the system worked at that point. I think she knew who she was petitioning, at least. I reached out to Amberley and we worked together to refine our proposal and figure out what exactly we wanted to request. I think there were a bunch of things that were on the original list like knitting needles, yarn and needles. I think crocheting would have been on the original list. We were sort of trying to figure out what was the right set of requests that actually made sense. ROBERT: So then, this is where Amberley stories comes in and it is interesting too because she has entirely different angle for this. Maybe not entirely different but different than outright. This kind of ties back to the word software podcast mostly. It kind of ties back to the software aspect, right? AMBERLEY: Yeah. I think, really they're kind of separate stories on parallel tracks. My motivation was also two-fold like Amanda's was, where I started knitting in 2013 and I had a really good group of nerd friends with a little yarn shop up in DC, like a stitch and ditch group -- ROBERT: I love it. AMBERLEY: It was a constant sort of like, where's the insert emoji here, like where's the yarn emoji? Where's the knitting emoji? And we would sort of sarcastically use the spaghetti emoji because it was the most visually similar but that was something that was in the back of my mind but it teaches you a lot about yourself too because I was like, "Oh, this is like fiber art, not really an emoji. It's kind of technical, like on a tech space," and I didn't really connect that it was relevant or that I might have any power to change it. It just didn't occur to me at the time. ROBERT: Interesting. I feel like a lot of people are in that similar situation or maybe not situation, even though you can make change on this. AMBERLEY: Right, so my brain didn't even make it like, "Why isn't this a thing? let me look at how to make the thing." When that happened for me, Amanda mentioned using emoji and everything in the BuzzFeed space. I love how you explained BuzzFeed a while ago, it's my favorite description of BuzzFeed I ever heard. Something similar that happened for me was I was a software developer and in 2016, the Yarn package manager was released and that kind of turned something on in my head. That was like I'm seeing all these software engineers now be like, "Where's the yarn emoji?" and I'm like, "Welcome to the club." ROBERT: "Do you want to join our Slack? We can complain together." AMBERLEY: Right. It has been like a pretty decent amount of time, I'm semi-seriously ranting and complaining to my coworkers who were primarily male software engineers. I remember I went to [inaudible] in the Frost Bank Tower after work and was just like, "I'm going to figure out how this happens," and I spent a couple hours at the coffee shop. I found the Unicode site and I found their proposal process and their structure for the proposal and everything and I just started doing the research and drafting up a proposal specifically for yarn. Maybe it was a bit naive of me but to me it was like, "Okay, here's the process. I follow the process. Cool." I mean, you have to make a case and it has to be compelling and has to be well-written and it has to be supported and all that and that to me it was like, "Okay, there's a process. At the same time, I did read about the dumpling emoji but I didn't connect it to Emojination and they had started the Kickstarter. We should talk about this later but I think the sort of idea the issue of representation on the committee and who gets to define language is really interesting but I saw that they had done the Kickstarter and there was a campaign aspect to it, so I ended up just building up this simple site so that if anyone Google, they would find yarn emoji. It's still up at YarnEmoji.com and that was how Amanda found me. I got this random email, I sort of like had this burst of energy and I did all the research and I wrote the draft, sort of piecemeal, filling out the different sections of the way they have it outlined on the Unicode site and then I feel like a month or two went by and I had kind of not looked at it for a bit and then, I get this random email from this website that I almost forgot about. It was like, "Hey, I'm working on this series of proposals. If you're working on knitting or yarn or whatever, maybe we could work together," and I was like, "Well, that's sweet." Then she opened up this whole world to me. There's this whole Emojination organization, sort of 100% devoted to democratizing the process of language formation through creating emojis and so then, I got really into that. My primary motivator was yarn. CHARLES: So what's the status of the yarn spool, those emoji right now? AMBERLEY: The yarn, the spool of thread and the safety pin, they're all approved emoji for the 2018 released. Amanda and I are actually at the end. Amanda, a couple of months ago when I saw someone used the spool thread emoji for a Twitter thread -- you know how people will be like all caps thread and have a thread of tweets -- I saw someone do that just out of the blue. I was like, "Oh, my God. Is it out?" and the thing about these individual vendors, it sort of gets released piecemeal, so at the time Twitter have I think released their versions of this series of new emoji but others hadn't. CHARLES: How does that work? Because you think the Twitter would be kind of device depending on what browser you're using, like if you're on a Windows or a Mac or a Linux Box, right? ROBERT: -- Emoji set, right? I know Facebook does this too. AMBERLEY: I'm painfully aware that Facebook does it because I can't use the crossed finger emoji on Facebook because it actually gives me nightmares. ROBERT: I have to go look at this now. AMBERLEY: Because it's so creepy-looking. CHARLES: Okay. Also like Slack, for example is another. It's like a software-provided emoji set. AMANDA: Right. AMBERLEY: I'm not totally sure that Slack actually adheres to the standard Unicode set. I think it's kind of its own thing but I might be wrong about that. AMANDA: Sorry, Slack definitely supports the full Unicode set. They also have a bunch of emoji that they've added that aren't part of the set. AMBERLEY: Slack emojis? AMANDA: Yes. CHARLES: Yeah and then every Slack also has its kind of local Slack emoji. AMBERLEY: Right. CHARLES: But how does that work with --? ROBERT: Okay, this crossed-finger Facebook emoji is... yes, I agree with you, Amberley. AMBERLEY: Thank you. I had yet to find someone who disagrees with me about that. AMANDA: I have never seen it before and I'm now like, "What is going on?" CHARLES: Yeah, so how does it work if a vendor like Twitter is using a different emoji set? How does that work with cut and paste, like if I want to copy the content of one tweet into something else? Are they using an image there? AMANDA: They're using an image. I think it's doesn't happen as much anymore but for a long time, I would often get texts from people and the text message would have that little box with a little code point in it and you were like -- AMBERLEY: More like an alien thing? AMANDA: Yeah. Definitely, if you don't have the emoji character set that includes the glyph that you're looking at, you're going to get that little box that has a description of the code point and I think what's happening is that Twitter is using JavaScript or generally programming. There were air quotes but you can't see. Twitter is using their software to sub in their emoji glyph whenever someone enters that code point. Even if you don't have the most up to date Unicode on your computer, you can still see those in Twitter. If I copy and paste it into a text editor on my computer, what I'm going to see is my little box that says '01F9F5' in it but if I get it into Twitter, it shows up. I can see them on Twitter but I can't see them anywhere else. AMBERLEY: Damn, you really have the code point memorized? AMANDA: No, I -- CHARLES: Oh, man. I was really hoping -- AMBERLEY: Oh, man. ROBERT: You live and breathe it. AMANDA: No, I'm not that compulsive. AMBERLEY: We definitely have our emojis on our Twitter bios, though. AMANDA: Absolutely. ROBERT: If you see Amanda's bio, it's pretty great. AMANDA: They started showing up on Twitter and I think that somebody in Emojination probably told me they were out and that was when I first started using them. Amberley might have actually seen it. It sounds like you just saw it in the wild, which is kind of amazing. AMBERLEY: I saw it in the wild with this tweet thread and yeah, it's just [inaudible]. I was like, "Amanda, is it out?" CHARLES: Yeah, I feel like I saw that same usage too, although I obviously did not connect any dots. AMANDA: This last week, October 2nd -- I'm also looking things up. I'm just going to come to the fact that I am on a computer looking things up so I can fact check myself -- after they actually released their emoji glyph set, so by now any updated iOS device should have the full 2018 emoji, which in addition to a kind of amazing chunky yarn and safety pin, there's also a bunch of stuff. There's a broom and a laundry basket. There's a bunch of really basic, kind of household stuff that certainly belongs in the character set alongside wrenches and hammers. AMBERLEY: I think one of the big ones too for this year was the hijab? AMANDA: No, the hijab actually came out with a dumpling. Hijab has been available -- AMBERLEY: It's been up, okay. ROBERT: So did it come with iOS 12 or 12.1? I don't know for sure. I just know -- AMANDA: I'm looking at it and it's 12.1. I really feel that I should be ashamed that I have used the internet and search for this. AMBERLEY: I would say, I have no idea what their release numbers are. AMANDA: [inaudible] as it appeared for the first time in iOS for 2018 with today's release of the iOS 12.1, Beta 2 for developers. ROBERT: That is amazing. Do you get some kind of satisfaction -- like you have to, right? -- from people using the emoji and it's starting to make its way out there? AMANDA: So much. Oh, my God, yeah. AMBERLEY: I didn't really expect it, like saying that random tweet using this spool of thread for a tweet thread. I just thought and I just got so psyched. For me, I'm a knitter. I have knitter friends and it started with yarn and then really, Amanda and through Amanda, Jenny really sort of broadened my idea of what it all really meant. To think someone using it in the wild for a totally different application than I had ever thought of was like, "That's legit." AMANDA: I definitely have a sewing emoji search in my tweet deck and sometimes, when I'm feeling I need a little self-validation, I'll go look over there and find people who are saying things like, "Why is there no sewing emoji?" and I'll just reply with all the sewing emoji, like it is part of my work in this life to make sure that not only do they exist but people know about them. ROBERT: That is awesome. I would do the same thing, though to be honest. You'll be proud of that. AMANDA: Totally. ROBERT: Were there any hitches in the proposal process? I know we're kind of alluded to it but the thing that you started off one thing, Amanda didn't make it. Right? AMANDA: I know. ROBERT: So how did that process happen from you two meet each other and then going through the actual committee and the review process and then being accepted. What would that mean? AMANDA: The process is actually incredibly opaque. We wrote this whole proposal, a bunch of people edited it, which is one of the other nice things about collaborating with Emojination. There was a bunch of people who are just really excited about emoji and the kind of language making that Amberley was talking about. There's a whole bunch of people who just jumped in and gave us copy edits and feedback, which was super helpful and then, there was a deadline and we submitted it to the committee and it actually shows up in the Unicode register which is also a very official kind of document register. I was a little excited about that too but then they have their meeting. They first have a meeting and there's like a rough pass and the Emoji Subcommittee makes formal recommendations to the Unicode Consortium and then the consortium votes to accept or reject the Emoji Subcommittee's recommendations. It's a very long process but unless you're going and checking the document file and meeting minutes from the Unicode Consortium meetings, you'll never going to know that it happen. AMBERLEY: -- You know someone connected through there because one of the things in our first pass, it wasn't that it was rejected. It was that we needed to modify something. We do have art for knitting needles with yarn because at one point, I think we weren't totally sure that a ball of yarn would be visually distinct enough in this emoji size to look like yarn and so, we had put it with sort of knit piece on knitting needles. AMANDA: Oh, that's right. There was a tease of a little bit of knitted fabric. AMBERLEY: Right and I think that, probably through Jenny or the people actually in the room, the feedback I remember is that there is a crocheter in the room who was like, "Yeah, why isn't there a yarn emoji but knitting needle?" so there was a little bit of like that was how I think we ended up from knitting needles with a fiber piece to ball of yarn, maybe. AMANDA: I think that sounds right. I'm actually sure of that. It's just all coincide with my recollection. There were some things that they had questions about and that happened really fast because I feel like we had a couple of days and they have stuck to our guns and said, "No, we're only interested in knitted bit of fabric." Also, we worked with an illustrator and went back and forth with her because the initial piece that she had illustrated, I feel like the knitting needles were crossing in a way. That was not how knitting works and so, there was a little bit of back and forth around that as well. But then once they decided that the they like the thread, yarn and safety pin, we're going to move to the next stage. I actually had to go back and look at the minutes to find out that the two reasons that they didn't move the sewing needle on to the next stage is when they thought it was adequately represented by the thread, which I wholeheartedly disagree with and they thought it wasn't visually distinctive. That's so much harder because a sewing needle, which is really just a very fine piece of metal with an eye at the end, you get down to a really small size and it is maybe a little hard to know what you're looking at. But I think there's such a big difference between the static object which is the spool or the thread which represents a lot of things and is important and the needle, which is the active tool that you use to do the making, to do the mending, to do the cobbling. CHARLES: Yeah. I'm surprised that it almost isn't reversed when certainly in my mind, which I think is more culturally important in terms of the number of places which it appears, it's definitely the needle as being kind of... Yeah. AMANDA: Yeah and I think that the thread and yarn, they're important and I think that the decision to have a ball of yarn rather than a bit of knitting makes sense because there's a lot of things that you can use a ball of yarn that aren't just knitting and they think that -- AMBERLEY: And it's the first step too that doesn't exclude anyone in the fiber art community. AMANDA: But there's so many things like in sutures and closing wounds, you're not using a little spool of cotton thread for that or polyester thread and stuff like embroidery and beadwork, you might be using thread or fiber of some sort that started on a spool but you might not. Embroidery floss was not sold in a spool and there's all these places where we use needles and all kinds of different size and you don't always use thread. Sometimes, you're using yarn. Sometimes, you're using leather cord. Sometimes, you're using new bits of, I would say Yucca. You're using plant fibers to do baskets and in all of these different practices, that process of hooking it through the eye and sewing it is how it's actually made. It still sort of mystifies me why they haven't accepted it but they also didn't reject it, which is really interesting. I don't know how many other emoji are sort of sitting in this weird nether space because sometimes they just reject them outright. I think there was a proposal for a coin that they just said no. ROBERT: They were a like, "A coin?" That would be [inaudible]. AMANDA: Oh, God. ROBERT: They have to add one for every -- AMANDA: [inaudible]. CHARLES: Literally, the pager of 2017. AMANDA: Exactly. CHARLES: So what recourse is now available to you all and to us, by extension, to get the sewing needle? AMANDA: I'm actually working on a revised proposal and I've been trying to figure out what are all the arguments that I'm missing for why sewing and the needle are not adequately represented by the thread and yarn. A bunch of things that a friend of my named, Mari who's half-Japanese, half-American but lives in Guatemala and does all this kind of arts in textile work, pointed out that there's a whole holiday in Japan devoted to bringing your broken needles and thanking them for their service. I thought that was really cool. I've been trying to formulate what are all of the arguments for the necessity of both a needle and a spool. If anybody has interesting ways to phrase that, I would love for arguments. CHARLES: Yeah but it's hard to imagine the arguments is just anything being more compelling than the arguments the you just laid out that you named about seven context: shoemaking, medicine, different fibers where the needle operates completely and totally independent of the thread. It's looming so large in kind of our collective conscious like holidays, being dedicated to them, except I think the Cro-Magnon pager, which is made out of stone, I believe, the being the artifact that pre-dates... AMANDA: There's the idiom landscape as well. Things like finding a needle in a haystack, that has a very specific meaning -- ROBERT: And for puns. I've been resisting saying a pun this whole time. AMANDA: Oh, share your pun with us. AMBERLEY: Yeah, you have to say it. ROBERT: Well, you could say that trying to get this through the committee is like threading a needle. Butchered but -- AMANDA: There's a biblical quote about getting into heaven -- a camel through the eye of a needle. I forget actually how it... CHARLES: To thread a camel through the eye of a needle than for a rich man to get into heaven. AMANDA: Exactly and there's this sort of do-re-mi, saw, a needle pulling thread. There are all these places where it's about the needle and somebody had -- CHARLES: It's primarily ancient. AMANDA: I know. CHARLES: It is the prime actor. Maybe, this is a good segue into kind of talking about the makeup of the committee and the decision making process and these kind of what seem like very clear arguments might not be received as such. AMANDA: I certainly don't want to say anything bad about anybody on the committee. CHARLES: No, no, I don't think that there's anything bad. I think that being receptive to things which are familiar to us versus with things that aren't is a very natural human thing and it can be interesting to see that at work and at play. AMANDA: The Unicode Consortium is also evaluating all of these requests for whole language glyphs sets. Lots of languages and lots of character sets that are kind of obvious, like there has to be a sort of like character set like there has to be an Arabic character set but there are a lot of languages that have been left out of that because they're very small minority languages or they are historical languages, where the actual writing is no longer written the same way but there's historical reasons to be able to represent those characters. One of the reasons why the Emoji Subcommittee cares about what gets into the formal character set is that everybody has to accommodate it and there's already been, I think some grousing. People start to moan and groan about how there's too many emoji, then it's too hard to find things. CHARLES: And there's no take backs. AMANDA: There's no take backs. You can't undo it. The committee is made up of representatives from a lot of tech companies primarily, although there's a couple of other kind of odd additional folks on there. I do try to find the committee list and I can find it right now. AMBERLEY: I have it from Emojination. I don't know if it's up to date but Oracle, IBM, Microsoft, Adobe, Apple, Google, Facebook, Shopify and Netflix. The other voting members -- ROBERT: Shopify? AMBERLEY: Yeah, right? The others being the German software company, SAP and the Chinese telecom company, Huawei and the Government of Oman. AMANDA: Yeah, the Government of Oman is a fascinating one. I don't think they're the ones that are biting us on this. Especially for those tech companies, every time the emoji character set adds 10 or 12 emoji, they don't have to accommodate it on their devices. They have to put illustrators on it, they have to deal with everyone saying that the crossed fingers emoji in Facebook looks like I-don't-even-know-what. AMBERLEY: Hey, Amanda. AMANDA: It's all your fault. There's a whole process and there's non-trivial work associated with every single new emoji, so wanting to put the brakes on a little bit and be intentional about where and when they apply that work, it doesn't seem crazy to me. I just want them to approve the thing that I want. AMBERLEY: I like the way that Emojination captures it. I looked at their website earlier and actually, they take it down but their goal quote "Emojination wants to make emoji approval an inclusive representative process." There has to be a process. There's overhead involved but looking at the makeup of the decision makers are not a trivial question. CHARLES: Right. This is a great example like [inaudible] metaphor but these little artifacts, these emojis are literally being woven to the fabric of a global culture and certainly, everybody uses them and they become part of the collective subconscious. It does seem like very important to be democratic in some way. It sounds like there is a process but making sure that everyone has a stake. AMBERLEY: Yeah. ROBERT: What was the reason that they gave for not accepting the needle and thread? Was it like a soft no? You said it's like just hanging out, not really rejected but not accepted. We're going to drop a link in the show notes for the proposal and your GitHub and everything. I'm looking at the PDF that was put together and it seems like it was all a package deal like we talked about. How do they just draw or they just take like a lawyer would, just like draw or cross it out like, "Well, no but we'll take the other ones." AMANDA: Yes, basically. What they did is they need to discuss and I don't know how long they've been meeting but they need to discuss all of the proposals that have been supplied by a particular deadline and -- ROBERT: That sounds painful. AMANDA: Yeah, I mean, it's -- ROBERT: Just imagine the power of thinking about emojis. AMANDA: One of the things that they rejected, I think because there's the smiling poo face. Somebody wanted a frowning poo face and they rejected that. There's a bunch of things that actually do get rejected. I don't know if they've been really care about a smiling poo face versus a frowning poo face. ROBERT: What about an angry one? AMANDA: We got all the feelings of poo. ROBERT: We got important work to do here. AMANDA: But they go through when they're trying to figure out. I think to some degree, you want to get them when they're not tired but I think the status that it's listed right now is committee pushback, so they've set it aside until we have some concerns. We're not going to reject it outright but we're not really sure why this isn't adequately represented. Then their most recent meeting, they just kind of passed on reconsidering it, which is fine because I think I was traveling and my proposal is not done. I really want to make sure that I have consolidated every imaginable argument in one place so -- ROBERT: And make it strong as possible. AMANDA: Yeah. If people want to help the other thing that would be amazing is any and all idioms that you can think of, especially ones that are not in English or European languages, idioms in Central European languages, idioms in Asian languages that refer to needles, either translations of the kind of classic, 'finding a needle in a haystack,' but also any idioms that are kind of unusual and specific to a culture outside of what I have experience with would be amazing for making the case, so this is an international need. ROBERT: Do they need any specific or actionable feedback or do they just say, "We're going to push back on this. We're just not quite sure?" AMANDA: The two things that we're in the minutes -- there are minutes and they publish the minutes to Unicode.org -- were it was not visually distinct, which is not totally crazy. We actually worked with an illustrator to get a different image. The first image was almost at 90 degrees. It was kind of straight up and down and it is a little hard to see and the second is -- ROBERT: Especially, because it's thin. AMANDA: The second image is actually a kind of stylized needle because it's fairly a little fatter and the eye is bigger but it's much more distinctively a needle. I'm hoping that that will also convince them but you have to be able to tell at a very small size that it's a needle. The other thing that they said was that sewing was already represented by the thread, that we didn't need thread and needle but it was literally one line in the minutes that referenced that and then it sort of like, "Did you have somebody in the room or not?" and so, if there is somebody on the committee who is willing to tell you really what their concerns were, then you have some sense of what they're looking for and why they're pushing back. When you can very much see in the earliest emoji character sets that I have a hammer and I have a wrench and I use them but there's these very conventionally male tools. We have all of the kind of office supplies but all of homemaking and housekeeping and textile production, none of them were there until very, very recently. I think it does reflect the gender of the people who've been making these tools, that sewing and knitting weren't important enough as human practices to be included in this glyph set. AMBERLEY: I guess, that's non-trivial to mention because that wasn't an argument that I made in my original yarn draft and Amanda and Jenny sort of pushing to open it up to this whole slate of craft emoji. I didn't realize until they brought that up. I took a stroll through pretty much the whole slate of emoji and you can count on almost one hand the number that represented the creative endeavors or sort of more traditionally known as creative things like camera or painting palette and stuff like that. It was extremely limited. AMANDA: I think they have stuff like that. I think there's a few different variations on the camera and then there's painting palette and that's it. AMBERLEY: Oh, there's the theater mask. AMANDA: Oh, that's right. There is the theater, the happy and sad -- AMBERLEY: And I don't know it exactly and I haven't read the minutes like Amanda has but I think and I hope that that was a particularly compelling piece of that argument. AMANDA: I think they definitely heard it. AMBERLEY: Yeah. CHARLES: Opening it up then, what else is coming in the way of craft? It sounds like this is historical but these pieces are being filled in not only with the work that you all are doing but by other emoji which you're appearing. AMANDA: Yes. CHARLES: And are you in contact with other people who are kind of associated with maybe craft and textiles and other kind of what you're labeling historically creative spaces? AMANDA: I don't think there are anymore with a possible exception. Someone's working on a vinyl record proposal which I think is great. CHARLES: Yeah, that's awesome. ROBERT: Antiquated, though. AMANDA: Maybe not, I don't know. AMBERLEY: Take a stroll through the Emojination Slack and people discussed that. AMANDA: Yeah. If you click at Emojination.org, the whole Airtable database is on there. There's not a lot of other creative ones. A friend of mine got really bent out of shape about the lack of alliums and wrote a whole slate proposal for leeks and scallions and garlic and onions. ROBERT: Oh, there is a garlic one, right? AMANDA: No. I mean, there is -- AMBERLEY: Actually, I'm looking at the Unicode page for current emoji candidates. They first get listed as... I forget the exact order. They become draft candidates and then provisional candidates or vice versa but I don't see any pending further creative ones but garlic and onion are on there. AMANDA: Yes. ROBERT: That makes my Italian a little happy. AMANDA: I think there's some prosthesis, the mechanical leg and the mechanical arm, a guide dog -- AMBERLEY: Ear with hearing aid, service dog. AMANDA: Yeah, there's a good chunk of interesting things that have been left out. I guess they've been approved by the subcommittee but are still waiting on final approval by the Unicode Consortium. ROBERT: Okay. What are the next steps that we can do to help push the thread and needle proposal through it. You mentioned a couple things like coming up with idioms that are in different languages and whatnot but how can we contact you and push this effort and help? AMANDA: That's such a good question. I don't even know. I mean, I am Amanda@velociraptor.info and you're totally welcome to email me if you want to help with this and I will -- ROBERT: That's a great domain, by the way. AMANDA: Unfortunately, there's no information about velociraptors anywhere on that site. ROBERT: That's the way it should be. AMANDA: But also, if you're excited about working on emoji proposals, Emojination is an incredibly great resource and folks there, including me actually will help you identify things that are on other people's wish lists that you could work on if you just want to work on something and we'll help you refine your proposal if you know what you want and we'll help you figure out whether it's worth putting the time in or not and how to make it compelling. You can definitely check out Emojination.org. I think there's a path to get on to the Slack from there. AMBERLEY: Oh, yeah. The Slack and the Airtable. AMANDA: Yeah. ROBERT: It sounds like there's a whole community that was born out of this, where everybody is trying to help each other and collaborate and get their shared ideas across. AMANDA: Definitely and there's a woman, Melissa Thermidor who is fantastic, who actually is a social media coordinator. It's her actual title but she works for the National Health Service in the UK and was tasked with getting a whole series of health-related emoji passed. There's a bunch of things that she's -- AMBERLEY: Is she's the one doing blood. AMANDA: She's doing blood. AMBERLEY: That's a good one. AMANDA: Because there's a lot of really important health reasons why you need to be able to talk about blood and getting blood and blood borne illnesses and -- AMBERLEY: That one was listed on the emoji candidate page or blood donation medicine administration. AMANDA: Yeah. ROBERT: That's really interesting, so she works for the government, right? and that was part of her job to do that? AMANDA: Yes. ROBERT: That's awesome, actually. I love that. AMANDA: Yeah, I think the drop of blood, the bandage and the stethoscope are the three that are in the current iteration, which is interesting because the existing medical emoji were the pill and that gruesome syringe with a little drops of fluid flying off of it, which do not do a lot to encourage people to go to the doctor. ROBERT: No, not at all. AMANDA: So a few more, we're welcoming medical emoji. ROBERT: You have a GitHub. Is that where you're still doing for the follow up and the prep work for the sewing emoji? AMANDA: Yeah, that's probably the best place. I do have a Google Docs somewhere but that's probably a better place to connect even than my ridiculous Velociraptor email. The GitHub -- ROBERT: But it's still awesome. AMANDA: It is awesome. I won't lie. I'm very proud of it. I am AmandaBee -- like the Bumble Bee -- on GitHub and the sewing emoji, the original proposals are there and I will make sure that there is information about how to plug into the revised needle proposal there as well. You guys are a tech podcast, so if people want to just submit suggestions as issues on that repository, that's awesome. We'll totally take suggestions that way. ROBERT: That would be pretty rad. Well, I appreciate you two being on the podcast. I love hearing your stories and how it ended up converging in parallel tracks but it end up achieving the same goal. Still unfinished, right? Let's see if we can help push this over the finish line and get it done because I would really like to see a needle. I could definitely use that in many of my conversations already now, making all kinds of puns. Thank you, Amanda for coming on and sharing your story. AMANDA: Thanks for having me. ROBERT: And thank you, Amberley for also coming on and sharing your story. This was super awesome. AMBERLEY: Yeah and thank you for connecting us to finally have a voice conversation. AMANDA: I know. It's great to actually talk to you, Amberley. CHARLES: Oh, wow, this is the first time that you actually talked in audio? AMANDA & AMBERLEY: Yeah. ROBERT: We're making things happen here. The next thing we have to do is get this proposal through and accepted. AMANDA: Yes. CHARLES: You've converted two new faithful sewing and needle partisans here and I'm in. AMANDA: Awesome. ROBERT: I know you've already gotten, what? Three through accepted? AMANDA: Yeah. ROBERT: We talked about that, it's got to be really awesome. I think I want to try and jump in and get that same satisfaction because a lot of people use emojis. AMANDA: Exactly. CHARLES: It definitely makes me think like you look at every single emoji and there's definitely a story. Especially for the ones that have been added more recently, there's a lot of work that goes into every single pixel. That represents a lot of human time, which I'm sure you all know, so thank you. AMANDA: Thanks for having us on. AMBERLEY: Yeah, thank you guys. ROBERT: Cool. That is the podcast. We are Frontside. We build UI that you can stick your future on. I really love this podcast because it wasn't necessarily technical but had a lot of interesting conversation about how to work with a proposal and probably make a bigger impact than any of us with software, just because the sheer reach that emojis have are insane and the fact that you can influence this process is new to me and really cool, so I hope a lot of other people learn from that too. If you have any feedback that you would like to give us on the podcast, we're always open to receive feedback. We have our doors and ears open, so if you like to send an email at Contact@Frontside.io or shoot us a tweet or DM us at @TheFrontside on Twitter. We'd love to hear it. Thank you, Mandy for producing the podcast. She always does an amazing job with it. You can follow her on Twitter at @TheRubyRep. Thanks and have a good one.

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.

Robert DeLuca gave the sermon today.

Special Guests: Brian Douglas and Bex Warner of GitHub. In this episode, the panelists talk about automating GitHub with Probot. The origins of Probot are discussed, as well as making GitHub apps with the GitHub API, automating workflows with Probot, must-have Probots for every repo, and GitHub's V4 GraphQL API. References: Microstates README Probot github.com/integrations/slack github.com/marketplace/pull-reminders platform.github.community/c/integrations probot.github.io/apps/unfurl-links/ probot.github.io/docs/deployment/ probot.github.io/docs/extensions/#scheduler probot.github.io/community This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: ROBERT: Hello everyone and welcome to Episode 105 of The Frontside Podcast. I'm Robert DeLuca, the director of open source here at the Frontside and I'll be your episode host. Today, we're going to be discussing automating GitHub with Probot with Brian Douglas and Bex Warner. I'm really excited about this topic. The idea of automating GitHub workflows with bots is amazing. This is something that I've been wishing the GitHub have the platform support for since I even started using GitHub for open source. Just being able to have a bot to take care of certain things like somebody doesn't leave enough of a PR description and they open up a PR, you can have a bot that just responds to it and saying, "Can you provide more information?" It's pretty awesome. With me as co-host today is Charles Lowell, who is also a developer here at the Frontside. Hey, Charles. CHARLES: Hey, Robert. ROBERT: Before we get into the discussion, I like to make a tiny little announcement. We've been building a composable and an immutable state container called Microstates. I'm sure Charles can talk about this more at length, then we will in the next podcast episode -- 106, but I would like to make a small announcement that Taras who is an awesome developer here just wrapped up a month's worth of work, creating a new ReadMe to describe the vision of Microstates and what you can do with them and everything about Microstates. If you're interested in that, I highly recommend checking out the ReadMe. I'll drop a link in the show notes for you that are interested. CHARLES: If I can add, it really is [inaudible] because it isn't like any other state management solution out there. ROBERT: No, absolutely not. I've been building something with it in React Native over the weekend of the 4th of July and it's amazing. But enough about that, you'll hear about that next episode. For this episode, I want to talk about Probot with Brian and Bex. Hi are you two doing? BRIAN: I'm well. BEX: I'm good. Thanks for having us. ROBERT: No, thank you for joining. This is really exciting. Like I said in the intro, I've been really excited about this project. I do a good amount of open source, I would say and this has been really helpful in all of our repos. We have, I think like 78 open source repos on the Frontside. We have Microstates, like we just talked about and Big Test and all of those repos use some combination of Probots that people have built and it's really nice, especially with the new Checks API that has just come out. You can integrate Probot into that, right? BEX: Yes. I, actually am currently working on shifting one of our bots from using the commits Statuses API to the Checks API. ROBERT: That's awesome. Before we go too deep into it because I want to come back to that because that sounds really cool and what the integration of that is like and what changes because I'm not even really that familiar with it. I just know it was released. I kind of want to go from the beginning here. Where did Probot come from and can we get a little bit of a history for everybody that might not know what Probot is? BEX: Sure. Probot originally started out as this simple idea to make GitHub scriptable. The original idea was you have a single file in your repository that would be like a JavaScript file and it would essentially spell out how the bot would act on your repository and the goal was to make GitHub apps accessible to people because if you ever look through our GitHub apps documentation, I think it can be a little tough to get started. There's, honestly, a lot of nonsense that you have to go through in order to get set up. For one thing, the way our GitHub app authentication works is it requires a JSON web token followed by using that JSON web token to request an installation access token and that process would be really tough for new people to get started. ROBERT: Yeah, it sounds like it. BEX: Yeah, so Probot was created to abstract all of that away and handle all of that authentication automatically and simply leave you with the payload that you get from listening on web token events and in authenticated GitHub client to make authenticated API requests while authenticating as an app. ROBERT: Cool, so that's where it started like a flat JavaScript file in the root but today, you use like EMO files and a .GitHub folder. How do that kind of progress? BEX: Originally, their use case was much simpler and it quickly became clear that a single JavaScript file in the GitHub repo was not scriptable enough and not easy enough to understand. The goal was to make like an API that could make that JavaScript file really, really easy to customize for every API of GitHub and it quickly became clear that that was not really a feasible thing to do. as time went on, it turned into this way to build Node JS applications and essentially, what the configuration files you're referring to are the way in which we make it customizable because right now, there's no way to be officially supported GitHub apps channels to pass secrets because it means you're a [inaudible] and the owners of GitHub apps, so that was just a way to kind of stop that problem. ROBERT: Gotcha, okay. BEX: The actual code for GitHub apps still lives in a Node JS module basically and the configuration file just specifies how that module runs. ROBERT: Right, so they're deployed like Heroku instances, if you want, like anywhere you can host a node app. BEX: Yup. Heroku, Now, yeah. ROBERT: Interesting. BRIAN: As a reason to that, some explorations of doing serverless deployments for Probot, I think there's a couple of issues of them. I'm not sure if anybody's shipped anything like the way they at but it's pretty much it's possible to. BEX: Just a week ago, we even released a new version in which we update our core from Node JS to TypeScript and now that things are typed, we have big plans for serverless. ROBERT: Nice. That's awesome, so then you'll be able to deploy to a Lambda and off to [inaudible]. BEX: Exactly. CHARLES: Can I actually interject here, as kind of a person who doesn't really know the relationship between GitHub apps and the GitHub marketplace and what exactly a Probot is before we hear the origin story. I would love to hear a very high level view of how this ecosystem fits together. BRIAN: I think a lot of people are pretty familiar with interacting with the GitHub API and OAuth integrations. I think I've just spent a lot of time at different companies previously to GitHub, just like making calls, either to cURL or through Node JS or more recently, [inaudible]. GitHub apps itself are a way to take all the things that you had to do to make an integration to GitHub much easier. It has a lot of cool things like OAuth, scopings, so you no longer have ask for all your repos ask access whenever someone logs in with GitHub and the connection between like, "Now have gone from OAuth to Now to GitHub apps," there was a lot of, as Bex mentioned earlier, ceremony that happens to getting set up with GitHub apps and integrations that Probot is like this tool to speed up the process of getting to the point where you just want to script some automation or some sort of workflow and it gives you all that bullet play for you. I don't know if that was a good high level for you Charles. CHARLES: Yeah. I've kind of witnessed this second hand with Robert installing a bunch of things here, so let's use an example, like you did some sort of automation on our repos, Robert, where when someone files a ticket, there's this workflow that automatically adds a triage label, so that we know that this thing hasn't even been dealt with, so we really need to address that issue. It doesn't need to be as a high priority. It doesn't need to be closed as a duplicate of something. One of the different aspects that you described there, how do they fit in terms of serving this workflow onto the end user? Or was that a good example, even? BRIAN: One of the cool thing about GitHub apps and what Probot does for you is that normally, if you want to add a label to an issue, either you Charles or Robert, would have to be admin or maintainer on the team for the Frontside and you could add labels. But somebody who opens up an issue, doesn't have that ability to have write access to your content, which is adding a label. What a GitHub app does, it actually takes a spot as if you would have another user on your platform, instead of creating a dummy account or a dummy user. Probot is basically building a bot for you to then, give you the ability to add that issue. That's sort of workflow that normally would have to happen through an actual real human could not happen through a bot without taking up a spot of like, "I guess, I probably shouldn't speak so ignorant about our platform and what we actually pay for nowadays for GitHub," but I know we used to have like a limited amount of seats for organization, like that seat no longer has now taken up and now, it could be just be used a bot can do something that normally us would take. ROBERT: Right. You no longer have to create a user to do these things. BRIAN: Correct. BEX: [inaudible] within GitHub. It's sort of built in a way that apps can take a lot of power in your repositories. CHARLES: So then, what is the relationship between Probot and an app? BEX: Probot is essentially the framework for building an app. You can definitely make the equivalent of any Probot app outside of Probot. It abstracts away all of, basically, the horrible parts and leave the easy part. CHARLES: Now, I think I'm ready to participate in this discussion. ROBERT: That was perfect, though. That's a great intro because I actually didn't have a total grasp or understanding of the relationship between GitHub apps and Probots. That's really good. BEX: Yeah. Additionally, going back a second. You mentioned the marketplace before. One thing to note that is that there actually are several Probot apps on the marketplace right now. The marketplace is essentially the home for any larger, usually third-party companies that have made apps and Probot is essentially supporting some of those. ROBERT: Interesting, so then my question would then be, do you know anybody selling their Probots. Does the marketplace charge? I'm going to assume it does. BEX: Yes. ROBERT: Okay. Is there anybody charging for their Probot? BEX: Yes. There is a quite a few, in-fact, charging for it. Recently, a pretty popular example is the GitHub Slack integration, which is if you open new issues, you can have them appear in your Slack channel. That whole application was recently rewritten by GitHub. It was previously owned by Slack and that was built on top of Probot. CHARLES: And I actually remember, we upgraded to that version. It's actually way, way, way better. BEX: I'm glad you feel that way. CHARLES: I didn't know the story behind there. I was like, "Oh, I just got a lot of... Awesome," you know? Although I don't know what's the costing. BEX: Yeah, I think that integration is actually free, so that wasn't the best example. I think it's for open source projects, at the very least. BRIAN: Brandon, one of the maintainers for the Slack integration and work at GitHub, also did a really cool talk at the SlackDev Conference a couple of weeks ago, so if you're interested what were the behind the scenes. That integration is all open source as well, so if you have request or you have features that you would like to add to the Slack integration, you can pop into the repo that hopefully will show up on the show notes because I'm not sure if it's like GitHub/Slack, but I guess we'll find that out in the show notes later on. BEX: It's Integration/Slack. BRIAN: But for an example of a paid app of a non-third party, we're not talking like Travis or Circle or another one with the big names but rather, a solo dev created. It's Pull Reminders, which is on the marketplace as of today and essentially, this gives you reminders of your pull quest, so you can actually ping inside the comments and tell Pull Reminders to say, "Tell me about the pull request like next week because it's Friday and I don't have time to look at this." ROBERT: That's awesome. I've also seen the one that's kind of related, that is like you can set your out of office at GitHub, which is actually kind of a neat concept. BEX: Was that the one where we are already changing that profile photos to have the overlay or the one where is just auto-replying to messages because I've seen a couple of -- ROBERT: I think, it's just auto-replies. BEX: Okay. CHARLES: So, it can change like your profile pictures and really, not just related to repo and history related activities but everything? BEX: Anything that you can access via the GitHub API, you can almost access via GitHub apps. There's a list of end points that I specifically enable for GitHub apps because there's something such as delete a repository that there's basically, a very few circumstances under which you want to give that permission to an app. Also, to things very specific like your profile or your personal page. About a year ago, there was an official internal audit of all of the API endpoints because there are lots of inconsistencies over what was and what wasn't enabled for GitHub apps, so they went there and kind of decided, what endpoints should be enabled and what endpoints actually get enabled. Now, that list is much longer than it was a year ago. Now, it's much more comprehensive. ROBERT: That's awesome and is this for the Rest API and the GraphQL API? BEX: Yes. Probot does support both. The Rest API is the one that specifically had all of these endpoints audited. The GraphQL, since it's a bit newer, we sort of built those and more. ROBERT: Cool. I really like working with the GraphQL API with GitHub. It makes it easier than trying to do a bunch of Rest calls. BRIAN: Yeah, there's a community form, it's like a discourse form that the API team actually manages and sort of pipes in there. Again, going back to like, if there's not something in the Slack integration that you would like to have, the form, that community is actually in there, if there's something not in the GraphQL API, that you would like to see. No promises on shipping it within an x amount of time but if enough people are requesting it obviously, there's going to be some resources [inaudible] at. ROBERT: What do you mean? We're doing open source. It has to be done yesterday. BRIAN: Yeah, exactly. And that form is at Platform.GitHub.Community, just a URL to get there. ROBERT: Awesome, that will be helpful to look through and get some recommendations in there. One of my favorite things I was going to say about the new integration for Slack and GitHub is the fact that I can highlight line numbers, paste that linked in and then it just expands it and the chat in Slack. That is so nice and I use it all the time. BEX: Yeah, I love that they built that feature. Actually, the original feature that was built on GitHub to allow those line expansions in the first place, like on GitHub itself, was actually built last summer by some folks who were also a part of my intern class at GitHub last year. ROBERT: Hey, intern power. That's awesome. BEX: Yeah. ROBERT: Everyone there is doing amazing work. I'm also following along with somebody that is also an intern and it's building a weekly digest program. BEX: Oh, yeah. That's actually a Google Summer of Code student. ROBERT: Oh, interesting. BEX: So, being sponsored through Google Summer of Code by Probot as an open source support. ROBERT: Is there anything more to unpack there? That sounds really interesting. BEX: Essentially, we submitted an application for Google Summer of Code because we thought it'd be a cool way to get more people, more students, a mentorship opportunity for the maintainers, basically and we were honestly overwhelmed. We got like almost 100 applications and it ended up being a huge of a deal but we're -- ROBERT: That's a great problem. BEX: Yeah, definitely a good problem but we were really happy. We, initially wanted to accept more students but Google limited us to only two students, so we have two Google Summer of Code students working on projects and one team of women from Rails Girls Summer of Code working on Probot. ROBERT: That would be awesome. What do they working on? BEX: I'm not sure yet. They actually just started a couple of days ago but the other Google Summer of Code student is working on a background checks API to eventually do sentiment analysis of comment history of someone new to your repository. ROBERT: That's interesting. That sounds like there will be some machine learning in there. I might just throwing out buzzwords? BEX: Most likely, I think they're just using some sentiment analysis API, like the perspective API. I don't think they're actually doing that themselves. ROBERT: Okay. CHARLES: Actually, I have a couple questions. Back on the subject of Probot. How does this square with the classic mode of integration because there was a lot out there? I think the first one that I remember that stuck in my mind was like Travis and I don't know if there had to be like a special relationship between the Travis developers and the GitHub developers, that's like, they was able to make that integration happen so many years ago. I don't know how that happened. I just remember it popped up and I was like, "Woah. This is incredible," and we see kind of the integrations gets more and more rich. For someone who's got, like you mentioned a couple of the big names, is the idea that eventually those would be able to be completely supported is GitHub apps or is it they're always going to be kind of a separate track for kind of the really deep integrations? BRIAN: I wasn't around when Travis first integrated with Lyft GitHub and I think that's a really cool integration and I know they have a very nice sized team that's able to do that. I think if we zoom back out like Probot, the way to get started with Probot is that we have the CLI command, which is to create Probot app. I believe it was intentionally copied off of create React app and the cool thing about create React app and create Probot app is that they abstract all the ceremony and boilerplate to get started really quickly. It was like, what developers or smaller teams can get started with integrating with GitHub apps. I highly doubt that Travis is going to rewrite their entire application with something like create Probot app but they're definitely going to be moving towards the new API calls, which would have been like GitHub apps. Part of the Checks API that we had launched at the end of May, Travis had blog post on how their integration with the Checks API works. They're making, though they have a lot of what Legacy endpoints and a lot of Legacy integrations in the way they integrate with GitHub, they are actively moving towards a GitHub app. I don't know if I could actually comment on their status of where they are today, to be honest but actively, we want all new apps and new integrations to follow the model of being a GitHub app, so that way, out of the box, you have access to all the newer features. You have all the access to all the newer GraphQL endpoints, if you want to use GraphQL and that way, we can serve one market, as opposed to everybody who had a GitHub integration from five or six years ago, that was all piecemeal together and sort of duct tape, like we run move away from duct tape everything together. CHARLES: I see. BEX: I definitely agree that I don't think Travis is going to switch to using Probot anytime soon and I don't think most of the large companies will be doing that but I do think, there will be shift towards GitHub apps in general. For those companies that don't already have the buildings of the GitHub app started, I think that Probot could be, in time to free some of them. BRIAN: In addition to that too, Travis and Circle and all the CI integrations, they're doing a really good job. I think the cool thing about GitHub apps is what you take away all that ceremony of getting your checks to work, now we can start opening up the door of like what's the next sort of CICD thing like? There's another term or another, I guess category of applications that can now be built to improve GitHub. CHARLES: The most amazing thing about having a great platform is the apps that you don't foresee, like it just come completely out of left field and you're like, "Woah. I can't believe that's actually a possibility now." When you have started to see some of those, some Probot or GitHub apps, you're like, "Man, I didn't see that coming. That's awesome." BEX: A hundred percent. I think it's the most exciting part of Probot because I think GitHub as a platform, we all know GitHub is the largest developer platform in the world and I think the idea that developers can build on top of this platform is the most exciting idea right now. I have honestly already seen apps that really excites me. The other day, I saw this app that was definitely not near completion but it was essentially updating and issue a comment box over and over and taking response through like checking a box and then listening on that common edit, in order to specify your coffee order. ROBERT: Woah. BEX: I was like, "Do you want an ice coffee or regular? Do you want milk or sugar and cream?" and it was going one at a time. It didn't actually order you your coffee at the end but it was super exciting to watch that. You're just editing the comment. I had never seen that before. ROBERT: That's pretty slick and that's taking the API pretty far. I'm sure there were some parsing in there and each Webhook response are like, "Was this box edited or not." That interesting. CHARLES: Yeah. Actually, now that we're having this discussion is kind of like changing my mind a little bit. Robert and I were actually talking yesterday about trying to standardize on our release management and our plan was basically to have some software that was going to run inside of our CI provider and have kind of a shared library, just a little ntm package that was shared by all of our repos but I'm thinking now, man, we should really explore doing this as a GitHub app. ROBERT: Yes, please. I've had three ideas that I really want to build out as a Probot. I'm just going to list them off and then we can build them all together and take equity and you know. I'm kidding. But the two that really excite me, that I kind of want to do is one concept that we work on this open source project for our clients and if somebody from the outside that doesn't have commit bits to be able to push to master, it would be really cool if we had a Probot that after it had an approved on the PR, from the maintainer, that the person that open the PR could then tell a Probot say, "This is approved by somebody that manages this project. Can we merge?" and then the Probot would then actually merge. I don't know if that's possible. That's something that I definitely wanted to explore. Then the other one, which is less cool, would just be like if we have a couple branches on some of our projects that we want to continue and we're not ready to put it back into master but we want to continuously run the test suite against it, so the idea there would be to have a Probot that would watch for changes on master and rebase as needed and continue to run the test suite and see where you're at. Those are the two things that I'm really excited about to do with Probot but I just want to automate everything with GitHub now. CHARLES: Right. BEX: Yeah, definitely, that first idea was actually pretty viable. I'm curious to know like how you actually get those commit links -- is that what you called it? ROBERT: Commit bits are more like commit permissions, I guess. BEX: Oh, I see. ROBERT: An outside contributor. CHARLES: Yeah, we want to push responsibility to the person who is the maintainer who can approve it but actually, the way we do it at Frontside is the person who actually is making the change is responsible for merging it. Once you get approval, you still have to hit the go button and that's just going to make sure that you're taking responsibility for saying it's done but that doesn't work for open source because people coming off the internet are going to have the right to push but we would like to give it to them, maybe via an app, if there is a maintainer who's approved it. BEX: Yeah. That's definitely something you can do. I've seen quite a few apps that, essentially add outside collaborators to the repo. Are you familiar with the... I forgot what it is called, like the all contributor section, where you cite everyone in your repo and everything and who's worked on it. There was a GitHub app that would add someone automatically after they merge their first change. CHARLES: That's awesome. ROBERT: I may have seen that on React State Museum but I'm not sure. It's a repo that we've contributed to and it has all the contributors at the bottom. It seemingly just kind of popped up there. BRIAN: There's an app that, I would like to mention too that I'm pretty excited about, that it sounds trivial too and it's almost similar... Not similar but it's sort of related to what you were talking about, Rob, with your first app, which is the WIP bot, which is the work-in-progress bot. This is a pattern of whenever I open a PR and I might not ready for a merge but I want to share my code so I can get feedback earlier on, I'll type in WIP so that append to my title of my PR. What this engineer did was every time you do WIP, it's going to go into the GitHub API and actually block the PR for merging, which is a feature available to GitHub. It's nested in your settings but the cool thing about this it actually blocks the PR for merging, so you don't have to worry about getting your, sort of like show and tell code merging the master without being ready. ROBERT: That's one of the first bots that I installed on all of our repos and then you can correct me if I'm wrong, it didn't always have the ability to block the PR from being merged but with the new Checks API, is that something that was introduced? BEX: Not exactly. The way that blocking of merging works is if you set it as the required status, so you can install any sort of CI on your account and have it not being required and ignore it whenever you feel like it, so it's really up to you to make it required. Otherwise, it just isn't checked and that's true for anyone who uses the Statuses or the Checks API. ROBERT: Okay, so that's a Statuses API. Okay, sorry. BEX: Yes. ROBERT: Also, the cool thing about that that I noticed when that was rolled out was I was now able to pick and choose and use workflows on Circle CI and each workflow is broken out as a different status check. I am now required like linting and the build and the test have to pass for these browsers before it can merge, which is really cool to be able to pick and choose. BEX: Yeah. It's awesome. I know personally on some of my repos, I have a few checks that I just don't require because I know I have to make them pass. ROBERT: Yeah. Speaking specifically about the work-in-progress bot, do you know how that works? It's open source, so I am sure I can go look. I think we want to go make a PR. We had some back and forth about this, Charles. CHARLES: I actually just [inaudible] we disagree. ROBERT: Yes. Charles opened a PR and one of his first commits in the PR had work in progress and the title had work in progress and we have this this Probot on our website and it was a blog post. You know, you make a couple more commits and you're further down, you move the work in progress in the title but the PR were still blocked because the first commit on a PR have work in progress in it. I think if it's the most recent commit or if it's in your PR title with work in progress, it should block but otherwise, it should not and Charles feels differently. CHARLES: I have about six commits and the very first one have WIP in the title or in the commit message and it blocked the whole thing but I kind of felt like it actually made me go back and I had to squash it down to two commits because I actually feel that your commit history should tell the story of the development, not like it should an absolute one-to-one journal of what happens but what you are intending. I actually felt that it could help me out because there's six commits that we're kind of all over the place and just kind of slapdash together have made me kind of go back, rethink it and tell a coherent story. I think it did me a service but it was not obvious. I definitely agree with that but I was like, "Why? Why were you still blocking?" ROBERT: Do I really [inaudible] admin privileges? BEX: I would say, I am friends with the creator of the web app. His name is Gregory Mantis and he is actually got a huge work in progress PR shifting work in progress over to using the Checks API and one of the features that he's using with the Checks API is essentially this mark as now work in progress button that will add the special line, like feel free to merge or something like that into your original PR description at the bottom. If that is there, the work in progress app will no longer be blocking. It's essentially like a hard override and honestly, that's the power at the Checks API versus the Statuses API. That's really exciting. ROBERT: Because I have seen the work in progress bot to get into a weird state, where I did remove the work in progress from the title but it didn't quite update and I'm still blocked. It's okay for me because I have admin privileges but other people on the team maybe not and they might be blocked from something that's actually work in progress. It's a lot like that hard override will be probably pretty helpful. BEX: Yeah, definitely. I think sometimes, there's some confusion with that just because of the way what perks work on GitHub and the way our pages are rendered, that you may need to refresh the page before you actually see it take effect. ROBERT: Right, yeah. Overall though, I love that bot. I go weekly, probably to the Probot apps listing and just go shopping. BEX: Wow. I'm actually the person who approves all the Probot apps to the listings so that's pretty motivating there. ROBERT: It's really nice. I am not even joking when I say shopping, I go through and I open up a bunch of tabs, I read through them, "Oh, this could be useful," that kind of thing. BEX: The first app you mentioned, which was like the one that requests more info is actually one that I built, so that was kind of funny. I guess you got that from the Probot apps too. ROBERT: Yup. That one, we definitely use on a couple of our organizations and repos. It has yelled at me a couple of times because of a blank PR. BEX: It yells at me all the time. I think I get yelled at more than people who are actually doing it wrong. ROBERT: I'm a little embarrassed like, "I should do better. I need to set an example." BEX: Definitely. ROBERT: Cool. I'm curious what both of your favorite Probot app is. This ought to be interesting. BRIAN: The app that I'm really impressed with so far, that I actually only use on a junk project at the moment, is the weekly digest one and it's mainly because I built something for this in my previous role at the company but then we shift it, which is basically go through every single repo. I worked at a company called Netlify previously and we had way too many repos to maintain... Oh, sorry, to keep track of and I was moving further and further away from the backend at the time so I was unable to keep up to date with all that was changing. I built a Lambda to watch Webhooks and then give me a digest of what was shipped like issues and PRs closed. It was way over-engineered and I never actually shipped that to actually make it work. But then the weekly digesting came out maybe a couple of weeks ago and it blew me away because I was like, "This is exactly what I needed," and I was trying to make it overly complicated through like a Lambda and like a bunch of Webhooks and this person, with only a few weeks, has the scaffolding of what I needed. That's the one thing I'm pretty excited about. It was already mentioned earlier too, as well. BEX: I guess, I would say one of my favorite ones is the unfurl a link app. I think that one it so simple but so nice. I don't know. I think having that unfurl link preview is just beautiful. Essentially what it does is it listens on issue comment creation or pull request comment creation or issues your pull request or whatever and read through the text or whatever was that issue or pull request and looks for links and then, essentially unfurls them so you can get a really nice preview of what you're going to. I think that's really beautiful and just so simple. ROBERT: Yeah. I love that one too. I have that added to all of our repos. BEX: It's so much nicer. Why would you not unfurl your links when you could unfurl your links? ROBERT: Exactly. CHARLES: I actually have a question. I think it's been touched on, probably at least twice throughout the conversation. I want to actually create a Probot, how do I actually go about deploying it? What does that look like? What does it look like to deploy and maintain it? BEX: We have a page on our docs about deployment and essentially the TL;DR is you can deploy it on any normal cloud hosting service that you wanted to deploy it. There are a few things you need to specify. For example, GitHub gives you a private key that you need to create your JWT and that private key means to be passed into your hosting service however you do that and then, there's a few bits of information that need to be pass in. We have pretty intense docs about it. Honestly, I'm not a deployment person. I usually try to let other people do that and I have never had a problem going through our docs and just getting it working immediately. BRIAN: It's also mentioned that there are examples like Heroku and Now and a couple of other ones. If you have a service that you already like, it's possible it's already in the docs, like steps to how to get that deployed. BEX: Yup and any other services are more than welcome to be added to the docs. Pull request are welcome. ROBERT: Sweet. It sounds like we need to set up a hack date to create a Probot, Charles. CHARLES: Seriously, my mind is brewing. ROBERT: I guess it's not directly related to GraphQL but there's something that I've always wanted to build. For prior history to everybody [inaudible], then the podcast, Brian and I used to work at a company called IZEA and one of the things that we built and I worked on a lot was we would create a collect metrics on people's social accounts that they're connected and do that and graph it over time. This idea came from when I was building up that feature all the way back in 2013, I want to graph the change in GitHub stars. Is there an API available for me to see like weekly GitHub stars or is that something that I still have to manually store and track? BEX: There's definitely an API endpoint to get the amount of stars and I don't see why you couldn't just do that on weekly basis and compare but I don't think there's any track that change API. ROBERT: Gotcha, like a history of it. I could do this by just stealing and looking at what the weekly digest Probot is doing because there is a change in stars section in there. I was just curious if there was now an API that was available. BRIAN: Yeah, that's more unlikely. I'm going to say no without looking at all the reference documentation. I think as far as that database, it's something you'd probably have to collect on your own but it's also a good candidate for a GitHub app, where you build a service that you can actually track stars once you've installed it and then if you want to monetize it, you can actually pay for private repo or whatever stuff like that, if you wanted to. But it sounds like a great opportunity to see this in the GitHub/Probot listings. BEX: I actually just look this app really quick in our docs because I was curious but apparently, you can receive the star creation timestamps. That could be doable through timestamp usage. ROBERT: Oh, and then I just kind of loop through back and build your graph in there. BEX: Yeah. ROBERT: Interesting. All right. Well, [inaudible] I was going to do today. BEX: Yeah. But I think it's exciting to bot the weekly digest and then what you could extract from that into stargazing is that Probot scheduler, which is essentially this all Probot extension we made that triggers a Webhook on a scheduled time period because right now, the way GitHub apps works are so centered around Webhooks. It can be difficult to find a way to trigger an action on something outside of a Webhook, like on a schedule basis. ROBERT: Yeah, that would be really helpful. I can definitely see how that would be a problem, if it's very, very central to reacting to Webhooks and events that happen on the system. BEX: Exactly. ROBERT: You're just hoping that somebody comes through and creates an event at a specific time. CHARLES: Can I ask you a question about, it's definitely on topic of extending GitHub but currently, just a question about, where the line is between what you can and cannot extend? You mentioned, for example in the rewrite of the WIP bot, being able to throw out a big button that says override this merge. Are there any plans to be able to actually extend the UI in novel ways? Everything there right now is happening with API calls, with I assume, UI elements that are related but the UI elements are static. If someone wants to put a novel piece of the UI, that button is going to require an extension of the GitHub UI by GitHub itself. Are there any plans to be able to, I know it's a dangerous waters, perhaps at a limited fashion at first but maybe more so, add different interactions and the actual application. BEX: I think this is actually the most exciting future of GitHub as a platform. In the past, GitHub APIs have only specifically supporting things that you can do through the command line or you can do through GitHub's UI itself. The Checks API introduced the very first non-integration specific UI element essentially and the merge button that I was referring to in WIP is exactly that. It's essentially this button that you can change the text of it to be whatever you want and you can listen on that action and then you can do as an integration or an app, anything that you want based on that. I think that's the most exciting direction for GitHub. Because if you look at Slack, Slack is a platform that has sort of really impressive integrations in that response. Your apps on Slack can really do all of these things, use custom UI elements, so I think the most exciting features for GitHub as a platform is all of this customization and giving the power to the apps. ROBERT: Yeah, that sounds an awesome way to be able to extend GitHub without having to try and throw the feature on to GitHub developers. BEX: Exactly. I feel that a lot of the struggle right now is that there aren't these nice ways of communicating via apps because I feel lot of the apps and bots end up just commenting on issues and pull requests and taking up a ton of screen real estate as a result and I just think that that's not the way that bot should ideally interact with the GitHub platform. They should have their own space to exist and that's the feature I'm most excited for. CHARLES: Yeah. I can think of having like progress bars for CI checks and your various appointments. It's too exciting. I'm glad. That's definitely the response I was hoping to hear. BEX: Yeah. We're excited for it too. ROBERT: Basically, you all have a massive community of a bunch of developers that would want to do this and are willing to get their hands dirty on it. Enabling that community is probably the root of all Probot is about. That's super awesome. BEX: Yup. CHARLES: That's a good place to end, because gosh, it's going to be so exciting to have the millions of developers on the planet, just like surgeon to the APIs that you're developing. BRIAN: One thing to add to that too, about the whole million developers, there's a number that's been thrown out from Stack Overflow and also, some other people who are saying like there's 50 million developers, there's 24 million developers. As far as GitHub, our public user number is 28 million, the cool thing about Probot and GitHub apps is that there's a good chance that all those people that are using GitHub today are not actually developers. They're like PMs or designers and what's really cool about this, like having interactions with that kind of platform in this way is that you can now enable all the non-developers to be able to interact with your GitHub repos and start bringing more designers and PMs onto to the GitHub platform to interact with the developers. ROBERT: That is an interesting point. That is awesome and something that I'm always looking for is a different ways to collaborate with non-developers on my team because... I don't know, developers tend to think everything is always centered around code but it's not. The shifting at work that are awesome, needs a lot of collaboration from non-devs and non-dev skills. That would be really interesting to see. I'm excited for that to play out. BRIAN: Yeah. There's a blog post that was published a month ago, I think about where the design team, design system teams rather, built the integration to Figma to update their icons effectively. I just posted that in the chat to look into but they also built this as a Probot app as well. ROBERT: That is awesome. BEX: Yeah, that one is super exciting. You would have the app comment, the diff between what the old icon versus what the new icon look like and it's just such a beautiful design change to be able to see that shift. ROBERT: Man, I'm happy that this is happening. The future seems super bright. Where can we direct people to get resources to contribute, to get involved and start really going at this? BEX: Basically, Probot.GitHub.io has all the Probot stuff, /app has all the listings for apps you can install today, /docs is where the docs are, if you want to get started and hopefully from there, we link up to the necessary things that you need to do. BRIAN: Also, what I mentioned too via Probot Slack channel, there's a Slack channel as well and they do a weekly call. I think, it's weekly or bi-weekly call to actually chat with the Probot community. If you have questions, you can actually bring your questions to the team. BEX: Yeah, we call it 'Office Hours' and it's once a week and it's under our community page, where we also have a link to our Slack. We have a link to another podcast we run and basically, how to get involved in the Probot community. ROBERT: Those are really helpful resources. I do remember seeing that Office Hours. It's on Thursdays, right? BEX: Yes. ROBERT: I was going to drop in for one and then, I actually forgot. Actually, it might be going on as we talk right now in this podcast. BEX: It starts in half an hour, I think. ROBERT: That's awesome. Cool. Well, thank you Brian and Bex for having a conversation about Probot. This is really awesome. Is there anything that you would like to plug for yourselves? How people can get in contact with you? BRIAN: Yeah, I am BdougieYO on Twitter. Everything you need to know about me is there and I am happy to say hello. I'm also helping with the GitHub developer program, which is sort of getting a soon-to-be announced rebranding. If you go to Develop.GitHub.com/Program and you want to have more conversation about the API and GitHub apps on the GitHub side, you can go there to sign up. BEX: And I am HiImBexo on Twitter. You can ping me in any Probot stuff. I'd be happy to look at any Probot code. I've been looking at it for a while now so I'm happy to do that. ROBERT: That's awesome. Thank you all for having a conversation with us. This was really fun. I'm so excited about everything you can do with Probot. This is a really fun project. I'm happy that this is happening and I will make a Probot in the future. CHARLES: I'm looking forward too. Robert has been excited for quite some time and he definitely talks a lot about it and now, I have some insight as to what -- ROBERT: It's happening, I'm telling you. Well. Thank you for being here and we are the Frontside. We build UI that you can stake your future on. We are specializing in JavaScript. We can build anything that you want throw at us. We do functional programming, React testing, Vue, anything in JavaScript, we specialize in. As always if you want to suggest anything for us to have on the podcast or talk about, you can reach out to us at Contact@Frontside.io and like I teased earlier in the podcast, next episode is going to be all about Microstates, the immutable and functional state container, composable model system that we've been building, it's controls as a brainchild for the past two years. That is next episode and I'm really excited about that. It's a really fun API and expressive to build models with. Thank you, Mandy for producing our podcast and we'll see you next episode.

In this episode, Michael Jackson of React Training and Rob DeLuca and Taras Mankovski of The Frontside talk about what is a component, and what a component is specifically in the context of React. They also discuss when it stops being a component and becomes something larger, how it has changed the way we develop UI, and thoughts on container and presentational components being synonyms for controller and view. References The Tweet that started it all Wil Wilsman: Does my application work in real life? Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: ROBERT: Hello, everyone. Welcome to Episode 103 of The Frontside Podcast. I'm Robert DeLuca, a developer here at the Frontside and I'll be today's episode host. We're going to be discussing what is a React component or what is a component with Michael Jackson. I'm pretty excited about this topic, a sort of off from a tweet that I sent out after a long workday, when it is something being called "component" because it was built with React components but it was more like a mini application? Then Michael replied to my tweet, as they're happening and he said, "What is your definition of a component?" which is exactly what we're going to be discussing today. I thought that was a really great question. With me, as a co-host is Taras Mankovski. TARAS: Hello, hello. I'm also a developer at Frontside. ROBERT: Before we get into the discussion, I would like to make a little announcement. We've been working on building a suite of testing tools to make acceptance testing JavaScript apps like React or Vue or Ember or anything else kind of JavaScript, fast and easy to maintain over the past few months. We call it BigTest. If you follow me on Twitter, I'm kind of loud about it. I love this project that we were working and one of my coworkers just published a blog post, giving an introduction to acceptance testing on React applications with BigTest. If that sounds interesting to you, you should check it out. We'll leave a link in the show notes. Now, let's jump right into it. Hi, Michael. How are you doing? MICHAEL: Hi Robert, I'm doing well. Thank you for inviting me to be on the podcast. ROBERT: Oh, no. Thank you for joining. I feel like this going to be really fun conversation. We went back and forth on Twitter a little bit and I was like, "You know what? This serves really well like a free flowing conversation." MICHAEL: Yeah, it's something I really like to talk about, specifically, when we're talking about components or when we're talking about React components. I think there's a lot stuff there to discuss and I think that React, specifically has really, at least defined that word for me. When you were talking about your mini application, I was like, "Oh, yeah. That's cool," and to me, that's kind of what these components have the potential to be, what these React components have the potential to be. It's kind of like almost these miniature applications that you stitched together to make a bigger one. ROBERT: Yeah, that's really cool. I was frustrated at the end of that day, just because that had so much logic crammed into it and you can kind of see that come through in the tweet but I'm not going to lie. After I sent that tweet, I was a little disappointed with myself because it came off a little bit like flangy but I guess we could just kind of jump right into defining what is a component. MICHAEL: When I saw your tweet, I was like, "Oh, you know like --" and of course, I don't know the component that you're looking at. It could have been terrible. Totally, it could have been terrible. I'm totally willing to believe that it was not a good component. But writing React is hard, especially writing good React is actually hard. At first, I thought it was easy but I think it's easy to solve your immediate problems but to write React to that is generic enough to solve lots of different problems, I think it's actually very, very hard and it's something that I've spent the last couple years learning. Anyway, that's kind of a tangent. But regardless of the component that you were looking at, the way that I've tend to think about these components is we used to have a model for thinking about how to build frontend applications -- ROBERT: Like MVC? MICHAEL: MVC, that's the one. That's the one that talking about. You have, here's your model, here's your view, here's your controller. You know, there are separate logical entities and lots of times, those even live in separate files on the file system and we keep them sort of separate and spaced out. As far as I can tell, that's a sort of paradigm. I learned it in school. By the time universities catch up with industry is at least, like twenty years, so it's probably something that was invented back in the 60s or 70s. ROBERT: I think it was like the 80s because Charles talks about it a lot and sort of Taras, actually because we're building something that's like a composable model, just like the Vue of React is a composable view, its components. I think it's interesting because I was listening to the Changelog Podcast and it sounds like you worked with Ember for a while. MICHAEL: I did, yeah. ROBERT: I forget, which podcast that was but we can find it and we'll link it to the show notes but I thought that was really interesting that you also came... Oh, maybe not came from Ember. You had experience with for, at least a couple years and that's where I came from. That's kind of where that tweet came from and was like, "Man, I don't like what happened to the word component," because when I think of component, it's like something that is encapsulated in a small piece of UI. But I'm okay with letting go of that. MICHAEL: Well, yes. Ember came out of something called SproutCore, which actually originated at Apple. Tom Dale used to be a developer at Apple. I'm sure you all know all of this but just for some sort of back story for others who might not. Apple was a place where MVC was really, really big. The whole Cocoa frameworks. They're all very much like, here's your controller, here's your view, core data has all of your models, that kind of thing. It's a software development philosophy that goes back a long time and has deep roots and I'm not here to suggest that because it's old it's bad, because lots of old things are actually very, very nice and good, especially in programming. We're starting to see a resurgence of functional programming ideas, for example, which have been around forever, since at least, the 60s or even earlier than that. It's not necessarily that I think that because it's old, that it's bad. I don't. ROBERT: Right, right. MICHAEL: But the thing that I do see in these React components is they kind of go very much against the grain. If you had, for example your model, your view and your controller as these vertical silos, just imagine turning that whole thing on its side and then cutting a slices of that, so that each of your React components has elements of MVC in it. They're all sort of mixed together. I run a training company called React Training and whenever I'm doing one of my training workshops, the way that I talk about it is a component is able to encapsulate three things: markup, which is the view essentially; state, which is essentially your data or your model; and behavior, which is essentially the controller, so what happens when the user is interacting with the view and clicking on the buttons? What do we do in response to the user input? You've got all three of those MVC elements in the React component. In fact, I've been meaning to kind of coin the term for a while. Instead of MVC, I call it MSB -- markup, state and behavior. ROBERT: You heard it here first. MICHAEL: That's right, here on The Frontside Podcast, we're coining new terms. ROBERT: That's pretty great. I guess coining off of that, is it fair to say that MVC kind of still lives on, except it's now in React? Or it's kind of more sliced up into smaller, more digestible pieces? We can always come back to this composability element, right? Would you say like really React would made it possible to compose many little MVC apps? MICHAEL: Yeah, exactly. The thing that people really, really love about MVC, I think you still have it in React. MVC, the thing that people always come back to is the separation of concerns. Let's just say, "I don't want everything sort of mingled together. I want it to be very clear. What is my model? What is my controller? And what is my view?" The cool thing about a React component is if you look at it, you still have very clear separation within the single component. You have a very clear separation of all three of those concerns: your state lives in an object called 'this.state,' then your view is whatever you return from your render method. That's in a completely separate spot, since still in the same component and then your behavior or your controller usually has its own method, so you can inline those in your render method or you can pull them out if this is how you'd like to do it. You can pull them out into instance methods. You can still have kind of that separation of the concerns within a single component. I think to your point, the React component model is all about composition, so this is kind of a term that we've actually adopted in other areas in technology. It's sort of just coming to frontend. The idea is you've probably heard of a service-oriented architecture for design in backend systems. These servers over here are application servers, these are database servers, here's our caching tier, here's our Ingress or LoadBalancer and maybe, you stitch them all together on the backend into one coherent system. You know, here's our storage and our image-resizing services. You stitch them all together on the backend into one coherent system but it benefits you to not build them all as one part of sort of monolith. We've got a lot of benefits from the decoupling. For one, if one piece of the system fails, the whole thing doesn't go down, so you can like swap it out or upgrade it and replace it with something else. I feel like that is kind of a similar idea to what is going on the frontend with these React components. ROBERT: Oh, microservice components. MICHAEL: Yeah, exactly. Each component is kind of like you said. It could be like a miniature application and it could be totally self-sufficient and I could drop it onto a page and it could just do its own thing or what I could do is I could take that app, that component and I could drop it into a larger app that can speak to it and can communicate state to it via the props that it sees and then can get state back out of it via these callbacks. I kind of view it as like all of these miniature systems that they can either be completely encapsulated and self-governing on their own or you can take them and compose them with a larger app. ROBERT: That's really interesting. I guess what is a component specifically in the context of a React. I guess, we kind of just answered that, that you can bundle all these things together, right? Does that make sense? MICHAEL: Yeah. The beautiful thing about this composition model is you can have all three of those things in the same component: markup, state and behavior. You can have all three of them right there, encapsulated in one component or once you discover more advanced patterns with React, you can actually make it so that a component only has two of the three or one of the three. ROBERT: And then it kind of like passes callbacks or props or state around? MICHAEL: Exactly. It can essentially delegate the responsibilities for handling the other pieces that it misses to other components around it. There's a pattern that I kind of coined last year called render props. ROBERT: Oh, yes. I remember hearing this on Changelog Podcast. I was actually one of the people that at first thought it literally was a prop name render. MICHAEL: Well, I mean it's not a bad way to think about it. It could be a prop name render. ROBERT: But then I found out it actually is a prop that you send JSX too and render whatever is there. MICHAEL: Yeah, exactly, a prop that you used to render stuff. It's the way that I describe it. When you think about it, any component, for example that accepts a render prop is really just delegating it's rendering to some other function. It can contain the two pieces: the state and the behavior, but then it can sort of delegate this third piece, which is the markup and say, "You know what? I don't really care about, specifically what I have to render." I don't have an opinion about that. You just give me a function and I'll give you my state and possibly, some behavior callbacks and then you can tell me what to render. I'm like a component that I have two of those three pieces. I don't have the markup, you just give me a function, that I will call when I need the markup. ROBERT: That's really powerful. MICHAEL: Yeah, exactly. I can have all three in one place or I can also with this component model, just delegate one piece or even two pieces, using these kinds of patterns to other components, so it's really nice. ROBERT: I'm always have to come back to this because this is where I kind of cut my teeth in the frontend world. I feel like render props are very similar to the yield pattern in Ember, where you can yield out a component and place it anywhere inside that template block. I think it's really similar. Because we have a large base of Ember developers that listen and they needed a draw like a parallel, I would say that's almost a parallel. I might be off on that. Taras, would you agree with that? TARAS: Yeah, it's very similar. There is one little 'gotcha' with render props in React, which I think Ember deals with a little bit more gracefully. I do use React all the time now. I use it much more often than I use Ember but -- ROBERT: Same. TARAS: Yeah and I'm kind of curious, Michael if you would think about this. Because there are certain things that, for example, JSX does, like one of the attributes of using render prop is that you want to pass stable functions, like something that is actually defined in init hook, so you're not necessarily recreating a new identity for this function every time that you pass into the render prop. Is that right? I think for someone who is might not be familiar with this, it's a little bit counterintuitive because it just kind of like, you just pass something and then you later realize, "Actually, I can't really do that because now your components were rendering over and over again." I'm curious like where can we kind of innovate in that? Because in Ember world, for example, it's really safe to use render props. If you're delegating to the context to do the rendering, you can very easily pass a block of template into the component and then the component will know how to render that in a performant way. My experience with render props in React was that the pattern in Ember is it's a very common behavior to delegate to the context of how the children of a component are rendered. This is the primary purpose of the yield in Ember and this is used by a lot of the components to provide APIs, so essentially, you're yielding, you're sending into the children function behavior that you want the developer to use while consuming your component. The parallel with React is that you would have, essentially a function, like you have a children render prop, which is a function that receives so that when a component is rendering the children render prop, it's passing some data into that function and it's invoking the children function and it's passing to it some data and then that data is being used inside of the children render function. Now, this mechanism works really well in Ember because Ember is using its own templating engine, so it manages every placeholder in the entire template as being passed into the component. It knows exactly what has changed in the function. Looking at that, the value just passing through component as a whole thing. It's actually managing each individual spot where the dynamic elements needs to be rendered. What that does is it allows it to manage the entire children function so you don't need to worry about stabilizing the render props. You don't need to assign them. Because there's also other challenges that kind of arise when you have to move the actual function that you pass into children. You have to move into the body of the actual component. Your ability to compose the state that is within the render function is kind of limit because you now have kind of broken up into different places. I'm a little bit curious what are your thoughts about this? And if there's any innovation that's going to require or improvements that will require in the way that React handles render props. ROBERT: I definitely remember seeing some tweets from you, Michael about this, like very recently. MICHAEL: Yeah, just yesterday in fact, I was talking about this on my Twitter. First of all, thanks for the question, Taras. I appreciate it. I think you kind of nailed it with the difference between Ember and for example, just JSX -- Handlebars, really and JSX is that Handlebars is not JavaScript. Handlebars is a language of its own, really. As the implementers of that language, the Ember team or the Handlebars team has complete control over how things work. For example, when functions are allocated. If they have a yield block, for example, that yield block does not have access to things like JavaScript Scope. It really is just a block within the templating language and so, they can decide when they're implementing that language. They can say, "We're only going to ever allocate one function for this yield block." JSX on the other hand, it really is just sort of some syntax sugar over JavaScript, which is nice lots of times because you can use things like JavaScript functions scope. You can do things like refactor it, like you would any other piece of JavaScript and pull that function out into its own variable or something like that. In a lot of ways, it's more flexible but with that flexibility comes this extra concern of what happens with the prop passing and it's a real concern but I don't think it's as big of a problem as most people have heard or might think it is. The real problem, the root of the problem is that if you have a pure component in React, the pure component is optimization tool in React, if you find that your component really is a pure component of just a pure function of its props and state, and that it will never render anything different, if it receives the exact same props and state, you can declare that that component is a pure component. Instead of just a regular component, it's now a pure component and so, it will actually opt out of the render cycle if it receives the exact same props and state on subsequent render. By exact same, what I mean is like identity triple -- ROBERT: Yeah. MICHAEL: -- Same. That's an optimization tool that you can use in React to say for example, maybe I've got a component and for some reason, it's always receiving the exact same props and it's rendering a lot. I can say, "You know what, React? Don't even waste your time re-rendering this component and doing the reconciliation around it and everything like that. If it receives the exact same props, don't even waste your time. This is a pure component. It received the same props. It's going to render the exact same stuff as it rendered last time, so it will completely opt out of the render cycle," so React won't even call the render method, won't even bother doing the reconciliation for that component or its descendants. It's actually a really, really nice way to get a little performance boost in that situation. ROBERT: Interesting. Does that mean, rather than passing some JSX that returns out an anonymous function, you would rather have like a pure component over that? MICHAEL: All it really means is that when you identify a place in your app where this is happening, instead of extending React component, you can extend React.PureComponent and now you component opts out of the render cycle. ROBERT: Gotcha. Because I see a lot in React applications, it will just return some JSX out of anonymous function, kind of think, Taras was getting at, when each re-render happens, it's recreating a new function and all of it were done inside of it, from the JSX because it's just a new function that's being bound each time. I think my takeaway from that and correct me if I'm wrong, is don't pass JSX and an anonymous function or I guess, from your tweets yesterday, that's kind of a premature optimization. Maybe, not pass as anonymous function but pass as pure component. MICHAEL: I hadn't yet gotten to directly addressing Taras's concern but the idea is -- ROBERT: -- Jumping the gun. MICHAEL: Yeah, it's fine. If you do have a pure component, that is when you're going to have a problem with this render prop pattern because you can't pass a render prop to a pure component. They just don't go together. Well, sorry. I should actually qualify that. You can pass around a prop to pure component but you need to make sure that it is always the exact same function, otherwise why are you making this thing a pure component, so there's a little bit of a problem there. I actually wrote the documentation on React's website on render props and there's a little caveat section where I discuss how you could get around this, you could convert it into an instance method or something else but then the concern at this point and this is why I said it's not such a huge problem because we're getting very, very specific now. Let's assume that we've got a pure component that is the child that we want to render and it accepts a render prop and that render prop depends on state and/or some sort of scope that it needs in the render method. Now, we've got a problem because we need to generate a new function in the render method and the fact that we're generating a new function and passing it to a pure component means that we are essentially negating all the benefits of extending pure component in the first place. First of all, in order to experience the problem, you have to get very, very specific and it's not easy to actually get into a point where the problem manifests itself. But then for the second part, fixing the problem is actually not tricky, so the way that you would fix this issue, there's a couple of ways to fix it. The most common way, I think to fix it would be to just say that pure component, let's just move that down one level and we'll put it inside the render method of the component that takes the render prop. The component that takes the render prop is no longer pure but the pure component has dropped down one level and we can still get all of the benefits of a pure component and again, its whole descendant tree lives underneath it. ROBERT: That make sense. MICHAEL: So, we can still get all the benefits of having a pure component, while still being able to use the pattern. But again, just getting back to what we were saying at the beginning. The render props is just one example of an advanced pattern that actually lets you delegate one of these three pieces to somewhere else. It's just one pattern. It's not like there are others as well. ROBERT: Yeah, so getting back to what is a component, is there ever a line that's drawn, like when does it stop becoming a component and it becomes something larger. MICHAEL: It's actually interesting because for a long time, we didn't have a component model on the web and I think -- ROBERT: It's very true. MICHAEL: -- still, like we mix to all three things together in our jQuery code. It was just like there was some state mixed in with some markup, mixed in with some behavior. It was all kind of mixed into one place. ROBERT: Nice plate of spaghetti. MICHAEL: Yeah, exactly. As soon React came along and actually gave us a real component model that really worked where we could actually identify these pieces, then all of a sudden, everything is a component and you really can make if you want, like if you really wanted to, you could make your entire application out of components. It could just even behavior stuff like, "I want to fetch some data," that could be a component or, "I want to listen to the window scroll or the window size," that could be another component. "I want to render an image or a bit of text or do some measuring or I want to do some parsing of some data or something like that," all of this stuff could be represented as components if you wanted it to. Of course, you can still extract those functions out into their own bag of utility methods and lots of times when I write a React Apple, I have a little bag of utils and I'll go and reach in there and grab those as I need them. But for the most part, most of my React apps are just components all the way down, so there's not much that I can't do with a component. The cool thing about that is what do you get when you have components, where you get reusability and sharability. I can make a component and I can just share it with you, Robert. I could say, "You want a component for listening to the windows size? Here you go. Here's the components. Got to render --" ROBERT: Drop it in. MICHAEL: "-- It will give you the size when you need it," so that ability to share code is, I think super important. ROBERT: Yeah, I think so too and it really helps you build applications rapidly because you can just start dropping these little components that are contained in composable throughout your entire app. I guess, I'm still clinging onto like there is maybe a line that is drawn and I think from the React community, there were a couple of terms coined called the container component and the presentational component, in which I immensely mapped those to basically being synonyms for controller and view. It's like the container components is kind of like a controller, like it delegates the view... Or decorates the view, not delegates. And the presentational component is just like we're talking earlier -- pure component. It's just taking props and rendering that. Is that fair to say? MICHAEL: Yeah. As far as I can tell, that's a pattern that was first talked about by the redux community, specifically I think Dan is the first to discuss that that pattern and it's a pattern that I think can work well. I haven't ever found it to be especially useful in my code but I can see how other people could like it for their code. I really just think it has to do with how your brain works. If you prefer structuring things like that, if you prefer like the vast majority of your components to just be these little view layers and then your main container components to hold all of the logic, I want fault you for that. I'd say, that's fine you can build your app like that. But I do think that when you're thinking about components like that, you are thinking about the much less like these miniature applications. Basically, in my opinion it's kind of a false separation. It's a separation that doesn't really need to exist because essentially, the thing that I really love about these components is you have encapsulation. You encapsulate everything. As soon as you adopt this pattern of containers and essentially, just these presentational leaf nodes, they're not as useful on their own. They just encapsulate some of the rendering logic. ROBERT: That's very true and they're not reusable. I mean, it's very, very hard to make those reusable. MICHAEL: Well, yeah. Most of the time, they're designed to be used with a very specific container. It is like, "Why couldn't we just put that in a container." Like I said, I really don't fault anybody for using them. It's just not how my brain works. I tend to think more about components as if they were these miniature applications and they're going to be useful on their own for the most part. One place where I have started to do that, the fourth thing that your components can encapsulate is style information, which is really just kind of the markup but it's the fourth thing and I think that I've really started to employ that kind of pattern when styling comes in. But it's not for this separation of containers and leaf nodes. It's just because I would like to encapsulate some of the styles down at a lower level or be able to reuse some of the styles down at a lower level, so that's when I'll typically start breaking up one of my components into multiple kind of tightly-coupled components but it's just for the sake of the styling, not really in any of the control flow or the logic. ROBERT: Right. When I first got into doing React, I was first like a little befuddled and then, I fell in love. I was like head over heels. When I hear about separation of concerns, it's always talked about like we need to separate HTML, JavaScript and CSS. They're all different things. They just need to be separate. I understand that. I kind of come from there but for me, my personal opinion is coming from the context of single-page apps, there is no feature that you can ship without the three. I don't think there is a complete feature that exists. Sure, there's edge cases that's like a blanket statement but I think those lines of separation is way more blurred these days and I think that's what React just unlocked. That's kind of where all of this is sort of rolling downhill and it's not a train. It's really powerful to be able to encapsulate all of those things together and then just think of your UI as these components. That's why we call them components. They componentized. Like when I have a butt-in and I drop it on the page, I don't want to have to go and make sure that I have the right class that's wired up in some other file. I can just drop the button in there and it's going to do its thing. I can pass the props, it'll change it, that's fine. It lives within itself. MICHAEL: Yeah, I would say you're absolutely right. You can't ship anything meaningful without having, at least some styling in there, unless you're shipping very, very basic behavioral style components. It's kind of one piece, I think like the React components are able to encapsulate their own styles but there's no, I guess officially recommended way to do it, which is where I think React get some of the critique, like some people come in and say like, "There are a million different ways to do styling in React and therefore, React is supposed to something like --" I guess, yeah, some of the other frontend frameworks have like, "This is how you do styling in our framework." ROBERT: Right, like the lack of convention. MICHAEL: Yeah, exactly. It's a blessing and a curse, though. If there's a lack of convention, it's harder for newcomers to know exactly what to do. ROBERT: Yeah, or like what's best for their use case. MICHAEL: Yeah, exactly but then on the other side, it's kind of a blessing because people are free to experiment and they don't have to feel like if they're experimenting, they're going sort of against the grain of what the community has already accepted to be the answer. I think that freedom to get out there and experiment is really valuable as well. ROBERT: You can see but I'm nodding. TARAS: I'm just curious what your thoughts were. This Suspense API is something that's... React kind of lead the way with components and now, the changes that are coming in with Suspense API coming in and it'd be great, if you can, are you able to explain a little bit about what it does for people that are not familiar and I'm curious what your thoughts about it. MICHAEL: Yeah, for sure. The Suspense API, I think is actually, with regards to what we've been talking about, with the encapsulation of markup, state and behavior and possibly styles, I think the Suspense API is kind of the React teams attempt to sort of encapsulate or generalize, at least one more thing, which is asynchronous behavior. The truth is, the most common async behavior that we know of, that most people are familiar with is a fetch, a data fetch -- you go and fetch some data. But there are others, there are things like loading of images and animations and navigation and things like that, where you have some time that passes in between when you initiate an operation and when you're actually able to render as a result of completing that operation. How do we manage or how do we generalize that and how do we think about it? The Suspense API is basically a way to declaratively say, "I need this async operation to be done." Let's just use the example of a fetch. I need this fetch. I need to have fetched this data in order to render this view and don't even attempt to render this view, unless the data has been fetched. Before the async API or Suspense, as they're calling it, you would basically have to manage this asynchronous behavior yourself. You would basically have to say, "Go and do the fetch," and while we're doing the fetch, maybe I'll set a loading flag in my state and say, "Loading is true," and then when the fetch gets back, I'll say, "Loading is false," and then I'll render. Maybe, while loading is true, I'll show like a spinner or some loading dots or something. What the Suspense API allows us to do or what they're hoping to do, again it's all very like... I don't know if I made this clear. It's still very, very, very, very early days for this API and I don't actually know when it'll be ready. But anyway, the idea is to be able to say -- ROBERT: Would you say the Suspense is killing the community? MICHAEL: The suspense around suspense. ROBERT: A terrible pun. MICHAEL: Anyway, the API is basically just a more declarative way to indicate where this asynchronous stuff is happening and give React sort of clues, if you will, to say, "There's some asynchronous stuff happening here, just so you know." That has many applications in the real world. Let's say for example, you were navigating in a master detail view and you're tapping down the master view and loading these detail views, if you tap a master view and you haven't yet loaded the information for the detail view, instead of sliding to the detail and showing the data still loading there in the detail view, you might want to show some sort of loading indicator while you're still in the master view. Then, if it's taking a while to load, they can actually select something else from the master view and in that case, you would cancel the old fetch and start another fetch. It's just supposed to make things like that, kind of feel a little bit more fluid and a little bit more intuitive to the programmer, so you don't have to think so hard about managing a lot of that complexity in your own head. ROBERT: Yeah. By the way, I love the mobile first language that you used. You tapped here, you tapped here, that slides in. MICHAEL: Yeah, for sure. It's all we're building these days. ROBERT: Yeah, it's very true. TARAS: It's interesting because the Suspense API, you wouldn't really imagine it to be within the scope of a view in a traditional sense, to [inaudible] but considering the scope of a component in React, it makes sense but I think people might not imagine as being something that would become part of core, potentially in React. I'm curious like what do you think other areas of React and I'm glad that the scope of components in React is so broad because it kind of opens up this question to be pretty much anything in React ecosystem. But is there an area of React building or the aspects of applications that you would like to see an improvement in or some kind of a change or something that hasn't seen the right amount of innovation in the same way that we've seen in other areas? MICHAEL: Basically, is there a place where I would like to see the React ecosystem improve? TARAS: Yes. MICHAEL: I know this goes kind of contrary to what I just said but I would like to see a little bit more cohesiveness. I feel like in some ways, the freedom is good but I also feel like in some ways, for the last couple of years, we've been just sort of like rehashing the exact same old problems again and again because React really made everything else so easy, like a lot of the stuff that was hard about building web apps, just got really easy when React came along. I'm not saying that because I have React training company. Of course, my livelihood right now depends on React but honestly, if it wasn't for React, I think I probably would have quit and done something else because it was actually getting really, really difficult for me. I was trying to build an app in Ember before I started with React and I just couldn't do it, you know? I just couldn't get the level of polish that I wanted in my app and get all the bugs out and get it working exactly how I want it to. It frustrated me, actually that I've spent a lot of time. I spent about 18 months, about $100,000 of my own money, just down the drain trying to build this app, trying to get it out the door and I wasn't able to finish it off. At the end of the day, I really started to question like, "Was it me? Do I just suck? Am I not a great developer? Is that the problem?" You really have to start asking ourselves hard questions like that when you put everything you have into something and it doesn't work out and then React came along and I was like, "I was just using the wrong tools." The tools were the problem. It wasn't me. There is a different way to think about this about building stuff. I thought the way that I was doing it was the only way that existed to build things but it turns out, it's not. I used to not understand what were people talking about when they were talking about functional programming or what do they talk about when they're talking about composition, solving problems with composition, instead of inheritance. I didn't even understand what that meant. But all I knew is really smart people would say stuff like that and I was like, "What are you talking about?" Now I feel like, because of React, I've gotten it. Again, to get back to your question, Taras, React made a lot of the stuff that we used to worry about, that we used to think about. It made it easy and so, we could build amazing things now a lot more easily. But now, for the last couple of years, I feel like we've just been sort of rehashing a lot of the same stuff. I would really like to see us, as a community sort of tackle the next level problems. I think the React Suspense stuff is definitely getting there. That's a problem that I really don't see anybody else sort of address, which is how do I make it easy to deal with the fact that applications by their nature -- these networked applications -- are asynchronous. How do I deal with that in a declarative way? That's why I'm encouraged by that work because I do think that it's kind of one of the more forward thinking things right now that's going on in the React community but I would like to see us in general, sort of like get past talking about styling and get past talking about service and rendering and move on. ROBERT: Right and I'm going to assume you have this really unique experience since you do a lot of trainings. I follow you on Twitter and it's just always talking about where you're flying to and who you're training, so the things have to come up there where you see these things in pattern over pattern over pattern. MICHAEL: Yeah, exactly. I see like a lot of and this again, gets back to Taras's question. I train a lot of people who are very new to React and I see people who are new to React, they really don't have a ton to go on besides just like blog posts and Medium pieces and podcast like this one and who am I? A lot of people in their React community don't even know or care who I am. It's like, "There's a guy out here who are saying stuff about React. Maybe I should listen to him. Maybe I should listen to somebody else," and it's confusing. It's confusing, I feel like, for people who are just getting into React. It's confusing. Like I said, experimentation is good but I guess, I wish the experience of coming to React was a little bit more like the experience of coming to Vue because -- ROBERT: Oh, like it was a beaten path. MICHAEL: Exactly. I don't actually think there's not a whole lot about the Vue technology that is compelling to me and let's not dig on it. It's just -- ROBERT: A personal preference? MICHAEL: Yeah, exactly, just preference but I do think the thing that is very compelling about the Vue experience is just the cohesiveness of it all. You go to Vue and there's like a way to do server-side rendering with data fetching and styling and -- ROBERT: They have a CLI and -- MICHAEL: And a CLI and a component and all these stuff. Yeah, and a router built right in. Anyway, I think that's a way that the React community could improve. I don't know if that'll ever happen because the React community at heart is artists and hackers and those people are traditionally very reluctant to be corralled and like I said, it's a blessing but I think from the perspective of people who are new to the community, it does tend to cause some confusion. TARAS: I want to add to what Michael is saying. What's interesting and I'm sure Michael sees this in his training but the kind of people that use React is very diverse. There's this kind of original group or there's kind of mentality that prompted the early adopters of React and now, we're seeing these companies that are traditionally enterprise-y with MSE backgrounds and coming into React. It's really interesting to see all this kind of worlds collide and then see what's happening as a result. It's definitely interesting on what's going on now. ROBERT: This is an excellent stopping point. I really agree. I come from Ember background so I would like to see a little bit more convention but I think it's okay. It would be nice to see that. Thank you, Michael for coming on. Is there anything that you would like to give a quick plug for and where people can reach you? MICHAEL: If you want to support the work we're doing, you can sign up for one of our upcoming workshops. We've got one right now on ReactTraining.com. We've got a workshop coming up, actually in my hometown of Carlsbad. You can come out here in July and hang out with us and do some React training. We got a really awesome host here who's right here in town. We're doing some React training workshops on July 25th through 27th, I think and then, other ways that you can support what we're doing is publish in all my open source code at GitHub.com/ReactTraining or you can follow us on Twitter at Twitter.com/ReactTraining or at my personal account at @MJackson -- Michael Jackson. ROBERT: Awesome. I really appreciate you taking the time to come on. MICHAEL: Yeah, thank you so much. It's been a pleasure. ROBERT: This is a great talk. Cool. Thank you everybody for listening. We are The Frontside and we build UI that you can stick your feature on. If you would like to give us feedback, you can always reach out to us on Twitter at @TheFrontside or you could email us at Contact@Frontside.io. We're always looking for any new topics or things you would like to talk about or things that are interesting to you. As always, thank you Mandy for producing our podcast. It's @therubyrep on Twitter and on June 28th, we're going to have Chris Martin on to discuss blockchain development.

In this episode, Harry Kaplanian of EBSCO joins the show to talk about the FOLIO project: a community collaboration to develop an open source Library Services Platform (LSP) designed for innovation. He discusses the why behind the the decision made to embark on this project, the benefits it brings to the market, and what makes it different from current offerings and other open source projects. Harry also shares where he sees FOLIO going in the future, challenging and unexpected outcomes of making the choice to go open source, and advice for other businesses that are considering embarking on a similar journey today. Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 102. My name is Charles Lowell. I'm a founder and developer here at The Frontside and I'm going to be today's host. So today, we're going to be talking about the business of open source with Harry Kaplanian. Harry's someone that we've had the pleasure of working with over the past year and collaborating with on a very unique project, which we are going to get into later. With me is Robert DeLuca. Hey, Robert. ROBERT: Hello. CHARLES: And before we start out today, we just wanted to take care of some quick news. Just so you know, we released BigTest React. This is actually something that grew out of the work that we've been doing with Harry. It's a set of React helpers to acceptance test your React applications so that you can make sure that you know that your application is actually working on actual browsers in actual life. So, that's exciting. You can go check it out at BigTestJS.io. And with that said, let's get on with the project. So first if all, welcome, Harry. HARRY: Thank you. CHARLES: I teased this in the intro, but we'll go ahead and say it outright. The project that we've been working on with you and with EBSCO is a project called FOLIO. And it's one of the more unique projects we've ever had the pleasure of working on. So, maybe you could just give us a brief overview of what exactly FOLIO is and how it came to be. HARRY: Sure. So, FOLIO I think can best be described as an open source platform for services. Our focus has always been the library market and so, currently this platform exists in the library space. That said, there's nothing about this platform that is library-specific. It can actually be used anywhere, anytime, for anything. The platform itself, all communication occurs basically via HTTP. It's microservice-based. It's language-agnostic. And it is really the core of what we're building. However of course, a platform on its own is not very useful. And at least for right now, libraries are overall expecting to get to a point in terms of features, functionality, apps, and services that are being built. So FOLIO can actually take over the enterprise-wide day-to-day operations of what it takes to actually run a library. CHARLES: And these are libraries like university libraries, the Library of Congress, the library at Alexandria. I mean really, when you think of library, like library [3:00 inaudible]. HARRY: Yes. However, we decided to focus on a particular market, at least initially or I guess a subset of the library market. And so, that subset we've actually chosen to focus on is the academic library market. And so, really mainly colleges and universities all around the world. That said, there is no reason why others can't use this software. And it is all open source. So, if any changes are ever needed, modifications or additional applications are needed to support those additional markets, that can certainly happen at any time. CHARLES: Historically, it's a very complex problem, right? There is a lot that goes on at these libraries. But historically, the software that's driving it has not been open source. HARRY: That is correct. So, it's sort of an interesting history. And I guess you're leading into what I think was maybe your second question [Chuckles] which was: What are the circumstances or the thinking that lead to the creation of a project such as this? And really, libraries have been pretty much operating the same way, to be honest, for probably about the last 40 years. And I'm sure we either all know or have heard, most libraries are facing shrinking budgets. They're really challenged in terms of space and storage requirements. And just in general, users have changed dramatically in the last 40 years, the last 20 years, maybe even the last 10 years. Most people don't really ever expect to walk into a library and actually conduct research anymore. They expect that to happen elsewhere. And so, in many ways, they're really facing what amounts to Google and others, because that's where people expect to go. The vendors that typically created the systems and software that supported these libraries, the day-to-day operations over the years, many of them have consolidated. And there are just actually very few options left. These are really old, monolithic systems. They were built initially with the best intent. And for the first couple of years, many features and functionalities were added. But over time, these systems grew to be so large. There really was never any one person anymore that fully understood it. They find themselves in situations where if they add a little feature here or modify something there, it breaks something somewhere else within the system. And so really, they've gotten to a point where libraries have generated lists of features and functionality that they need that are frankly years long. And the vendors just can't deliver any of it. They just don't have the ability anymore. The systems are too old. In addition, really they're sort of building these walled gardens where they really try to take over all the day-to-day operations of the library but are actually starting to try and expand out in other areas of the university as well. And as they do this, they really tend to lock the system down. They're not really open to integration with other systems or other vendors. And they really see it as they are the one company you should go to that can completely manage and operate everything that goes on in your library. And when we talk about innovation in these systems, really they've been operating the same way, as I mentioned earlier, for the last 40 years. Really, the only major, major innovations is there's maybe one company now that's offering these services on the cloud. One size fits all. And the real issue there is, all of these libraries we talked to, all of them see themselves as being unique in some certain and specific way or sometimes multiple ways. All of them believe they're bringing something special to the world in terms of knowledge, research, understanding and learning. And they tend to cater or specialize often to the institution they're a part of. And so for example, if a library belongs to a medical school, of course their collections are tailored that way. A lot of their workflows and operations tailor to students that conduct research in that field. And oftentimes, even to a hospital that may be associated as well. And this will oftentimes be very different from what might exist for example in an engineering library. And so, for most of them, they look around at what's available to them. Not only has nothing changed, not only has there been no innovation, but on top of it, they're forced to choose essentially a single system. And that's not really getting them what they want or where they want to be. So I, as well as some others, spent quite a bit of time looking around at the market and trying to assess and understand all of this. And one of the things we felt was, as we look at all of this, really we're living in a world, these libraries are living in a world of closed systems, lack of transparency, lack of change, lack of innovation. How do we change that? How do we spark that innovation? And it seemed like what we really need is some sort of an ecosystem, a sustainable ecosystem or really, openness and transparency. And it seems like the only way to get that really is open source. And in fact, we actually conducted a survey and out of that survey, 100% of the libraries we spoke to really believe in open source. And when you think about it… ROBERT: Whoa. HARRY: Open source really in many ways aligns itself really nicely with the mission of the library, right? The library is there to not only promote learning but to make sure information and knowledge that normally you may not have access to is accessible to everyone. They're really leveling the playing field. And that really is a really nice analogy for what open source is doing in the marketplace as well. And so, this seemed like really, and at least, an initial ideal path to head down. And so, we did. CHARLES: Yeah. And so, you did. And I'm curious to explore more about that decisions. Because – now this is a little bit of a dated quote – but Steve Balmer, when he was the head of Microsoft, called open source communistic and un-American, then how do you reconcile that? Because obviously you represent a business that ultimately needs to be profitable and is engaging in this in order to make a profit. And so, where does the balance lie and how do you reconcile that? And obviously you all perceive this as a strong business move. And so, yeah, how do you balance those two concerns? HARRY: I think from our perspective, we looked at it as if a single vendor or maybe a group of two or three vendors end up locking up the entire market with systems that operate the entire library that are not open and they're not willing to integrate with other systems and services that exist out there, in essence that's an attack on what is the basis of our business as a company. We provide services and we provide content that libraries use and ingest and make available to their users. And essentially, it looks like they're trying to lock us out. And how does that really help in terms of creating an open and fair marketplace where people get to make choice? It doesn't. And so, what can we do to disrupt that? And building a system that allows everyone to play at least puts us on a level playing field where if an organization or a library chooses to adopt it, we're now back in a very competitive situation where really, the vendor or the organization or the individual that provides the services that best fit that library's needs wins. And that's what we really want to happen. And so, that's in essence how we win. We believe we offer better services than most others in the industry, if not everyone else in the industry. We think there's a sizable percentage of the market that truly believes that. And we just need to make sure that the mechanisms or the systems are in place that allow us to compete in that manner. And in the end, if what we end up with is a platform that allows 3, 5, 10, or 20 companies to actually compete in a reasonable manner fairly, really it's the customer in the end that wins. It's these libraries and it's the users and everyone else conducting research. ROBERT: So, I'm still kind of reeling from 100% of libraries said that they would like to have an open source platform. How many did you survey? HARRY: So to be truthful, it wasn't a large number. ROBERT: That's still insane to me. [Laughs] HARRY: Right. We focused on, however, surveying different segments of I guess really representation within the library. So, the people that do the work, the middle managers, and then really, the folks at the director level that are really responsible for running and organizing a library. ROBERT: The ones that will experience that pain of being locked in, right? HARRY: Right, right. And trying to get decision-makers at many different levels. And we tried to also cover both very small libraries to very large, enormous libraries as well. And all of them saw a benefit. One of the pieces where things sort of maybe went in the other direction as far as the statistics are concerned, if you ask them though “How many are willing to adopt open source?” the numbers aren't quite the same. In fact, they're rather dramatic. And so, at that point it's roughly about 33% said they'd be willing to adopt. CHARLES: So, why is that? HARRY: So, we asked. And interesting question. And what most of them came back and stated was, “Well, we love the idea of open source. We fully support it. We're willing to do what we can to help it and make sure this happens. However, we ourselves don't believe we've got the staffing, the resourcing, or the knowledge to host this ourselves.” And so, this leads to another really interesting thought or idea as far as open source is concerned, is so this really implies that there really needs to be sort of an ecosystem of organizations that are providing these types of services. And to be honest, the faster we can make that happen, the better off the market is. Libraries are now getting to choose vendors that they get to get their services from, which is rather interesting. Because for the first time, not only do they get to choose the vendor but if they're not happy with the vendor, they should be able to switch vendors but keep the software and the data the same. Today, in the library market, if a library chooses to switch vendors, that means essentially they're completely starting over in their library. They completely have to migrate to a fully new system which means enormous amounts of training, enormous amounts of data transfer, and all the pain that goes along with it. I had a librarian tell me once, “The next time we migrate to a fully new system, I either want to die or retire.” I just want [14:30 inaudible]. ROBERT: Man, that sounds painful. HARRY: That's how painful it was. CHARLES: Yeah, wow. Because the complexity intrinsic to these systems, it does, it boggles the mind sometimes. Just even the little slices of the ecosystem in which we're operating, there's just a lot at play there. ROBERT: Yeah. Like trying to work with other vendors and be agnostic so anybody can adopt these things that we're building. And since we had that vendor lock-in, it's hard for you to adapt the two systems, because they were built in complete silos. So, trying to merge that is an interesting challenge. HARRY: And I think everything I'm saying here, I'm talking about it from the library perspective. But if you look at other industries, I don't think it's really any different. If you look at any of the enterprise-wide management systems that are used in corporate organizations today, most of these corporate entities will stick with the system they chose for a very long time. Because it's incredibly painful, it's disruptive, and it's expensive to switch from one system to another. And so, the idea of you're not happy with a vendor and hey, I can go to somewhere else and maybe keep the system I have in place is really kind of interesting. And even better, if the vendor's not able to provide some of those features that I need but for the most part I like the system, wouldn't it be great if I can hire someone to do that work and to have those pieces built for me? And those are some of the things that open source offers. CHARLES: Right, right. So now, I understand that for example to kind of put a concrete bow on this, [Chuckles] to move away from abstraction of what it means and provide an example, so we have this open source platform, this FOLIO platform. Which if I'm a library, I could in-house, I could either use it on premises on my own servers or I could run them on AWS or I could run them on Google Cloud – there are all these different deployment options and some libraries are doing that, but that's something that they might not want to do. So, I understand that EBSCO is actually going to be for example one of the services that y'all are going to be offering around FOLIO, is actually hosting the platform so that the overhead of managing all of the servers and provisioning accounts and doing all that stuff is going to be taken care of for you. So, I can just sign up. HARRY: Yes. So, that really fed into the results of the survey. For those libraries or organizations that felt they couldn't do it themselves, where would they go? And who could provide those services? So, we're absolutely going into the business of providing these services for libraries that choose to. But at the same time, we're really strongly encouraging other vendors and organizations to provide these services as well. Because for instance, you may represent a series of libraries in let's say Hungary. You may have a vendor there you enjoy working with in the past. It's provided great services for you. There really ought to be no reason why you should not choose that vendor to provide those services for you. And again, it's an open system. There's nothing there that's excluding me and the organization I work for to provide additional services, to provide content or what have you. It's an open system. And so, we should strongly encourage that. And the reality is, if we're going to have a disruption in the market, it seems we can either have one organization or one company trying to usher this disruption along. But what if we could get 10? Or what if we could get 20? Or more companies out there ushering this disruption along simultaneously worldwide. It feels like we've got a lot more of a disruption happening in that case. And so, that's what we're strongly encouraging. CHARLES: Right. But at the same time, I can see it from if I were considering making a play like this, one of the things that would worry me is, “Okay, so we're going to disrupt the market by allowing a large tent where lots of vendors could compete.” But then, I immediately experience fear of, “Well then, how do I differentiate myself?” Because ultimately I want to be competitive. How do I make it so that I'm not a commodity in this new market? HARRY: So really, I think that's key for any vendor that chooses to compete in a market like this. Do you believe as an organization you have not only what's needed to compete but those key differentiators that at least a certain segment of the market would be interested in you and the services you offer? We believe we do. Another company that just recently announced that they're going to be supporting FOLIO and providing services around it is a company called ByWater Solutions. They've actually been in another segment of the library market for many years providing services to libraries as well. Longstanding, actually, with open source codebases. And so, this very much appeals to them. They believe… ROBERT: Oh, interesting. HARRY: They have a niche that they can provide and they are going to be doing that. And we strongly encourage it. What's again great about it is if they set up a library with FOLIO, they're not building the walled garden. They're building or providing the open platform that we can connect our services to. So in many ways, yeah there are some areas we're going to compete. But there are actually many areas that we're also going to be complementary. And I think that's what's really, really interesting to us. CHARLES: So, it sounds like you're also counting on just by having the ecosystem in place and having this sea as it were filling the ocean to enable trade, one of the bets too is that you're going to open lines of business that weren't even possible before. HARRY: Correct. So, another way to look at it – we've got our iPhones or Android devices. Apple built a platform is really what that phone is. When it was released, you could make voice calls. You could do some simple text messaging, some basic email, and I'm sure there are a couple other of things in there that I've forgotten. I do not believe that Apple had any idea that they'd actually be able to create a marketplace that had hundreds of thousands of people and vendors providing features and functionality for that platform. I am pretty sure no one at Apple had ever imagined the guitar tuner would be released. I don't know, a compass app, flashlight apps, whatever. You name it. And not only that, as a user of that platform, you're not happy with the standard email app? Well you know what? I can get a different one. In fact, I've got a choice of many and I can find the one that suits me best. And that's fine. It's an open marketplace. And so, with FOLIO today, we're in early stages. We're building out that platform. We're building out some of the basic functionality for that library that they need to operate as a library. But once this gets released, it's at that point when we believe the more interesting things are going to happen where we build a cataloging app for FOLIO. Well, we know already that there's other organizations that are starting to look at and think about, “You know what? We've got a whole other way or a whole other interest in terms of how we'd like to support those workflows on the FOLIO platform.” Or even better, librarians starting to think about, “Hey, if I've got this open platform just like Apple does, this means I now have the option to build features and functionality that take me where I want to be five years from now, 10 years from now. And I've never had that ability on the existing systems that we use today.” And so, one of the other I think advantages or benefits that something like FOLIO or a platform like this brings to the market is the ability to create that marketplace very much like Apple has done and Google has done with Android as well. ROBERT: So, we're pretty far in, but you mentioned FOLIO a couple of times. Do we want to unpack what FOLIO actually means? HARRY: Yes. FOLIO actually stands for the Future Of Libraries Is Open. ROBERT: Right there in the name. I love it. HARRY: Absolutely. CHARLES: So, we've talked about this platform. We've talked about this marketplace. We've talked about the business incentive of why you would want to do this, why it makes a lot of sense. Clearly, this takes an enormous investment. So, we think, I think, a lot of people think of open source as a bunch of wild developers running around. ROBERT: Pushing commits wherever they want. CHARLES: Pushing out code and doing stuff. And then it kind of organically grows into something that someone then picks up. ROBERT: And then you burn out. CHARLES: Yeah. [Chuckles] But that's I think a lot of people's experience with open source. But an initiative like this takes a staggering investment both in terms of capital resources but also in terms of will, in terms of management, and putting all these enormous forces in motion. There's developing the software, developing the awareness, and I think right now there are hundreds if not thousands of people working on this right now. How do you even go from zero to 6,000 like that? And I'm not talking about people. I'm talking about velocity. [Laughs] HARRY: Right. Early on, when we were conducting research, market research, one of the things we did, we spent some time looking at what we believed were successful open source projects. And I think what was interesting was in many cases it took a single individual or a company to actually create what amounts to that first piece, that first core building block that others could start to expand upon. And very often, they literally just created it themselves, made it available out there as open source, and basically told the world, “Here. Have at it. Have fun. Do with this whatever you wish.” So, we actually thought we'd like to do that. However, building a system on this scale is not that easy. Understanding the operations of a library day-to-day is not that simple. We need help. And so, what we decided early on was: could we kick off and start this project while at the same time [25:42 inaudible] that community as early as possible? To get people excited, interested, and to get this project in a place where we're not the only contributors, where there are many others contributing as well. And when I say ‘contribute' I don't necessarily mean software developers. But that is certainly one aspect of it. But one of the key pieces of building software is gaining access to subject matter experts as well. And it's absolutely key and critical. And so, our goal of course was to build this community, have that community start to provide that in-depth knowledge, those subject matter experts that we need so we can determine what it is we need to build, how we need to build it, and really go from there. And by including those people as early as possible, I think one of the things we find that happens with this project which is really sort of incredible is the excitement that starts to build. The word of mouth advertising, marketing, as librarians, libraries, vendors and individuals start to talk to others and really spread the word about this project. In many ways, it starts to compound or snowball and build on itself. But that was really challenging. And it was really actually kind of slow going in the beginning. Because we started with nothing. And one of the issues you face is, “Well, you want me to contribute my time to this project, yet I see nothing.” Right now it's just a dream. And so, one of those early, early issues was, “Can we build a team small enough, focused enough, where we can start to build some of the basic, basic, basic core pieces, to really prove to the world that this project is real? This project is actually moving forward and this project is actually delivering.” And now that we're in a state where people can actually see working software, the excitement is just starting to expand and compound rapidly. And we see it everywhere. CHARLES: So, do you find libraries or people in the target market, there's that key point where they start to feel empowered? It's real and then the thing that I think that you're going for is to have the realization dawn that not only is it real, I can put my hands on the wheel and I could control my destiny. And I can contribute now because there's this critical mass. ROBERT: You have the power to make change, which never existed in the library world before. HARRY: Or at least, not in this specific area. Because to be truthful, I think libraries as a whole believe they're making change around the world all the time. But it's really related to content. But this is actually making changes in the actual operations of the library. And they are actually empowered to get involved, to contribute, and to help us get this done. And it seems to really resonate with folks. Because it's something they haven't been able to do previously. And it seems genuinely exciting. And we announced this really, well the market learned that this was happening I'd say a little over two years ago. Maybe more like two and a half years ago. And it was sort of a gentle drip in terms of a roll out. People started to learn because we started talking to them. There was no real active marketing going on. But of course, those people started to talk to other people. And so, it happened. And when we were able to provide those first demonstrations, no matter how rudimentary it was, that's when things seemed to really kick into a much higher gear where people started talking to each other. Librarians started talking to each other and say, “Hey, this is real. This is exciting.” ROBERT: It's not vaporware. HARRY: And this is happening. Right. It's not vaporware. And we need to get involved. And so, they have. CHARLES: Yeah. And the energy and involvement just in the course of the time that we've been a part of the project is apparent. Every kind of gathering is larger and the diversity of topics that are discussed is increasing. And yeah, the conversations have burned from “What can we do with it?” to the last time the project got together as a group, it had much more of a conference-y feel. And the topics being discussed were like, “How do we actually deploy this to our real systems?” Which has been fantastic to see. And so, just to actually feel the traction is just, it's so gratifying. So, I guess one of the questions that is on my mind is – so you mentioned that you had been at this for about two and a half years. What is in your mind the most pleasant, unexpected outcome of this project that you didn't foresee two and a half years ago that you're experiencing now? HARRY: So, I think one of the one's that's surprising is I've never actually personally been involved in an open source project before. And I think one of the fears constantly working for organizations that really have been closed source – in fact, I've been that my adult working life – and you sort of walk into this with some [trepidation]. Because oh my gosh, everything I'm doing, everything I say, everything that gets documented is going to be out in the open for everyone to see? Including competition and everyone else? And I have to say, one of the most interesting things, or one of my favorite pieces here, is: it is so freeing. It's a release. It's actually amazing to not care about what your competition or anyone is doing or thinking. And it's even more amazing whenever you've got a question and someone's out there asking you for access to documentation, you can simply point them to the website, to the URL and say, “It's there. It's all there. Anything you want is there. Go take a look.” I think that's pretty amazing. The other one of course are the relationships between many, many different people who I've just never really been – or I never would have had the chance to work with before. And really hearing all these different perspectives and points of view as far as what people think are right, correct, or what we should be doing – it's great to see. And it's great to see this wildfire word of mouth message that seems to be moving everywhere. We're hearing back from people not just in North America, not just from the EU, but from the Middle East, from South and Central America. There's really just people interested everywhere. And it's amazing to me, because I don't think I spoke to anyone over there. So, it's happening. And that's just an exciting thing to see. CHARLES: Yeah, yeah. ROBERT: It's really cool that open source can connect you with the rest of the world like that. It's just so powerful. HARRY: It does. And it's an amazing thing. ROBERT: And the amount of collaboration that happens, I've never experienced it in any other way. It's really cool. [Chuckles] I don't know how else to put it. It's just, it's almost mind-blowing that you are able to across timezones, across the world, collaborate with somebody on something that you both feel passionate about and you're pushing it forward in an open manner. HARRY: Right. And it's also amazing when you have these meetings and there's people you've been collaborating with for months if not a year or more. And getting to meet them face-to-face for the first time. That's really a pretty amazing experience. ROBERT: Yeah. And it's pretty awesome. At our last gathering that we had at WolfCon, I had the absolute pleasure of chatting up a bunch of different librarians. And hearing their experiences and what they're looking for out of an experience, it's just really cool to be able to talk to those people and see how they work and help build this into the platform that they're wanting to use. HARRY: Right, right. CHARLES: Yeah. I would say on the whole, there's been a lot of those wonderful, unexpected outcomes. Were there any that presented a particular challenge or wasn't quite so much a walk along the path of roses? HARRY: So, you know I think the biggest one is – I mentioned earlier we embarked on this project a little differently versus what we saw as normally successful open source projects, right? We did not have that core, beautiful, shiny object to unleash onto the world and let them know, “Hey, have at it.” And so, it wasn't so hard in terms of getting interest. But what's been hard is the amount of interest has generated enormous numbers of organizations that are interested in contributing to the project. Which also implies then that now, not only are they coming to us asking us, “Hey, how can we help? What can we do here?” but then there's a certain aspect, because this is a first version of, “How do you manage the building and construction of that very first version of this software project when the reality of the matter is, you're not really responsible for most everyone working on the project?” And how do you get everyone aligned and organized? How do you get everyone onto that same path along with those same milestones that we've all agreed on? And even worse, how do you get agreement on those milestones so we can all walk that same path and deliver that first version? And so, I get asked sometimes by folks that are involved in other open source projects, “How do you handle this situation? Or how do you manage all the work that goes on?” And when we tell them, it's kind of surprising because it's not what they're used to seeing. And a lot of it is because of the way we started, the interest that was generated early on, and the fact that we did not have an initial version. And I don't want that to sound like, “Oh, this is a huge problem,” or, “If I were to do it again, I would not do it this way again.” I in fact would do it this way again. I think there are a lot of benefits and it's been a great and interesting way to go. It's just the management aspects of it are definitely challenging. And I think more than maybe we had initially anticipated. Going into this next time, though, I definitely know what I'm facing and I'll be prepared. CHARLES: Yeah. So with that in mind, given that you've been through this, do you have any advice to offer someone who might be considering embarking on a similar journey? And undertaking a similar Herculean task. HARRY: Well, I think you'll find it's harder than you think. And be sure to plan for that. But I guess at the same time, I think my biggest advice or my best advice would be: you need to keep an open mind. And when I mean an open mind, you need to be open to other thoughts and ideas. And I think you need to put yourself in the perspective of what if you were one of these other people that are working on the project or trying to contribute to this project? What are the things that you're doing or rather the things that you're doing now, the way you're acting, the way you're reacting, how does that look to others on the project? Because you're not the only one contributing. You're not the only organization contributing. And are the things you're doing reflecting badly in terms of others' perception or optics as to what this looks like as an open source project? And I think for me and others, there was a huge learning experience. Because your first thought is, “I'm going to tackle this like any other software project,” and it's not. It's not like that at all. CHARLES: I think that's… ROBERT: That makes sense. CHARLES: Yes, that makes sense. That's excellent. That's excellent advice. And I think that's one of the things that makes open source so powerful, is because there's that aspect just baked into it from the get go, you have to be mindful of a bunch of different perspectives. And that ultimately results in a solution that's going to be workable for a bunch of different perspectives, that's going to be flexible to accommodate for all the different use cases that all the different participants in the community might bring to the table. HARRY: And you have to be very mindful of how your actions are perceived. Because normally, your actions are perceived by the company you work for, what tends to have a particular culture. But on an open source project, you're actually dealing with many different cultures. CHARLES: Yes. HARRY: And so, that's a tight line that you have to walk. CHARLES: That was a powerful note to end on. Thank you everybody for listening. We are The Frontside and we build software that you can stake your future on. If you want to get in touch with us, continue the conversation, you can reach out to us on Twitter at @TheFrontside or drop us an email at contact@frontside.io. Thank you so much Harry, for being on the show today and talking to us about FOLIO. HARRY: And thank you very much for having me. This has been great. CHARLES: And if you want to, if there's something that you want to learn about or a topic that you want to discuss, please, please let us know. We always are open for your feedback, especially when it comes for things that you would want to hear. And if you want to get involved or learn more about the FOLIO platform, you can just head on over to FOLIO.org. There are resources for librarians, developers, and anyone who is curious about becoming a community member. Thanks as always to Mandy, our producer. And we've got a really great podcast coming up on the 14th of June. We're going to have Michael Jackson on the podcast to talk about separations of concerns in React. So again, thank you Robert. Thank you Harry. And we'll see you all next time.

In the first episode of the Bytesized podcast, Kristian talks with Robert DeLuca, a staff engineer at Visa working on web accessibility.

FUMC Eastland Sermon

Show Notes: 01:11 - Doing Dumb Stuff aka “Throwaway Projects” 06:06 - Combatting Burnout 10:01 - Dumb Projects That Pay You Back 17:00 - Brainstorming and Abstraction 25:19 - chillestmonkey.com 20:19 - “The Iron Triangle”: Creativity, Accomplishment, and Learning Resources: React Native and Chill: A tale of stupid made fast by Charles Lowell Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 59. We're getting up there, 59. That's like, I don't know, it's not a milestone but it's something. ROBERT: It's like one away from 60. CHARLES: Yeah, it is. It's past middle age. It's like elderly. ROBERT: Start thinking about retirement. CHARLES: Yeah, exactly. JEFFREY: These are our golden years. [Laughter] CHARLES: Welcome to the golden years. ROBERT: All right. Possibly, we need to go and watch the Golden Girls. [Laughter] CHARLES: Actually, I think it was only five or six episodes, maybe 10 episodes, we were singing The Golden Girls theme so it all comes back around. We're here with a very special guest and that guest is nobody. It's just folks from The Frontside -- JEFFREY: I was hoping you would say it was Betty White. [Laughter] CHARLES: We're going to fly it solo or like tri-lo or like trio. ROBERT: Trello? CHARLES: Trello. I, of course, am Charles Lowell. With me is Jeffrey Cherewaty and Robert DeLuca. Hey, guys. JEFFREY & ROBERT: Hey, what's up? CHARLES: We were kicking ideas around and something that's been kind of percolating around the offices is a theme for 2017 is doing dumb stuff, just stuff that has no apparent value but that you can learn from. I think, we each have a bunch of these experiences where we've done something a very little import that ends up being really, really helpful, either both in the short-term and the near-term. JEFFREY: And who knows, maybe this episode will turn out the same way. ROBERT: Oh, how meta. This could become a black mirror episode. I'm start to questioning my values. CHARLES: I know for me, I recently did some explorations into React Native, which I found to be very edifying. I could obviously talk about that experience quite a bit I did on a blog post but I'm curious, if you guys recently had something that was a throw away, something that you did that wouldn't really matter if it had come into existence or it didn't but it's just so happens that in this thread of reality, it did. ROBERT: You know, I have. It's always been centered around the impagination library that we wrote here. I was always kind of intimidated by impagination for some reason because it was this big library that I didn't necessarily understand. I was like, "You know what? I'm just going to go for it. I'm going to go do something dumb with it," and then I just decided to implement the most useless infinite scroll. It solved absolutely nothing and as you're paginating through 500 records of robots from Faker, I sat down and spent six days and wrote some code and implemented it React Native and it was actually the most informative and fun thing I've ever did. I don't feel tied to it. CHARLES: Yeah, so what kind of inspired to do that? Because usually, it feels like there's this pressure to ship something. Ship something is like just go build something but the idea is that you're going to build something that people actually might use. ROBERT: Yeah, I always had that idea. Maybe you can think about it as like feeling getting cornered, like the pressure of shipping sort of pushing me into a corner. Then eventually, I just kind of lash it out like, "No, screw this. I'm out." I'm going to go do something that's not even useful. I don't care. I'm not going to try and support people or make it to something that other people can use. If that is what falls out of this, that's cool but I'm going to totally sidestep and this needs to be something that other people can use. Sometimes, when I go to build a project, I start thinking, "This is going to be in my GitHub public profile. What if somebody comes and finds it? What are they going to think about my code?" And I just shed all of that fear away, then what happened is I learned a ton. After that experience, I was like, "Whoa. This is massively valuable." CHARLES: Yeah, like hearing you talk about it makes me think about one time I went to a Picasso art exhibit and they had all these sketches that he'd made just in pencil from when he was younger and they were in studies. I guess, apparently artists do this a lot where it was like just a goat's leg. Or some old man's nose. You know, just in pencil or charcoal and these are little tropes that he later integrated into all of his painting -- ROBERT: That is an amazing way to put. JEFFREY: It's funny. When you see engineering tutorials are like, "This is how you learn to make software." A lot of times that is the way they're structured it is around studies. Like, "Make this little tiny thing that by itself is worthless but can be part of a greater whole." ROBERT: Yeah, take that impagination infinite scroll thing, I think three months later, it turned into a full on talk about co-chairing between React and React Native but it started with this dumb little project that I decided, "If I don't finish it, nothing bad happens. It just kind of sits there and rots." I feel no guilt. No pressure. JEFFREY: Would you say that was part of your blue period? [Laughter] CHARLES: Yeah, I like you [inaudible] point to like ship it. It's like we have a culture of ship it or don't. In any way, it's entirely up to you. ROBERT: I kind of thought to think about it as the extreme of ship it. Literally, just ship it even if it doesn't work. CHARLES: Right, ship it even if it's wrong. ROBERT: The other thing that I figured out was who is to determine what's wrong or right. I figured out that no one like I figured that out and I choose if it's wrong or right. CHARLES: Right, and it's like whether I learned something or whether I didn't or whether I get to be the arbiter of what I get out of this experience. ROBERT: And you almost always learn something. Always. CHARLES: Yeah, you definitely do. I think it can pay off, both in the short term and in the long term too. I know with my recent experience, I was feeling extreme burnout. I don't know... You feel like the code that you're working on or the things that you're doing have become a burden. I guess that's kind of to your point, Rob like when you are building something that it creates users. It creates code. It creates maintenance cost. It creates contributors. There's all this mass and inertia and momentum that are for it and that can be great if you own something massive, you can have a lot of momentum and it can be extremely energizing. But it can also be a burden, if it's something that you have to carry and you feel obligated to carry. ROBERT: Yeah and when you have those huge successful projects, things that come to mind like Ember or React or Babel or things like that, those are awesome. But I was always experiencing that responsibility with things where I had big plans for them but nobody knew that just by looking at the projects like it was still very much a work in progress. But I felt that feeling in my gut. CHARLES: Right and that mass and that inertia can come completely and totally from an internal source. It's both important for the project to be like these throwaway projects to be completely and totally free from all attachment, especially from your own dreams and your own ego and things like that. ROBERT: And when I learn to let go, that's when I learn that I'll learn. [Laughter] ROBERT: I'm going to learn-learn. CHARLES: I guess, the kind of greater point that I was making is that when you are able to approach a project like that, then it can be a really intense cure for burnout because you are just allowing yourself to create, you're allowing yourself to feel creative and actually deliver something whose success parameters you define entirely. I think, Brandon actually talked about this almost like two years ago with that robot. That project that he did where he was kind of in a similar situation and he really, really needed to do something that was not a web app. I think there was a series of talks that came out of it but that was primarily for the burnout case. ROBERT: I think I can agree with that. I might have been in the similar situation where I was starting to think about the feeling cornered. It was maybe because of burnout. CHARLES: Maybe those are one of the same. ROBERT: Because I felt like I wasn't producing anything and I was like, "I should be doing this stuff but I feel like I should be but I'm not," and the things that I'm doing aren't great enough because the things that I have done in the past and that's a bad way to think about it. JEFFREY: There's something so refreshing about being able to switch contexts of I've been working on this same app for a few months and doing kind of similar tasks over and over and that's such a nice way to create at really recharge like, "I'm just going to do something completely different and see how that feels." ROBERT: Yeah, I've gotten really good at writing computer properties but I want to write something else. JEFFREY: Just like anyone who does a lot of Ember, they're great at computer properties. CHARLES: It really is the equivalent of throwing a dart into a map. If you're feeling burnt out and you're looking for what to do, There are so many things like you actually aren't cornered. You have the universe of possibilities and the dumber the better. Choose something random that you can do in five minutes, do something random that you can do in an hour or a week or something like that so it has that payoff for being an answer to burnout. I've experienced where these types of activities come back and pay you back down the road. ROBERT: It doesn't have to solve a problem. I was always looking for the next project that I could build that would solve a problem. I always felt like I needed to solve a problem and I was just looking at it backwards. You should also be looking at things like it solve a problem. That's cool. But why not take a piece of technology and like, "How can I bend this? What can I do?" And exercise the different corners of this framework or do just something that's totally useless. CHARLES: I remember actually, that was something that Ryan, when he first started coming to the Ember meetups, he was asking questions about it and I think he was coming from Backbone and was -- ROBERT: Just Ryan from [inaudible]? CHARLES: Yeah, [Ryan Ralph?] from [inaudible] and he was asking questions and like, "Yeah, it's pretty good. The only disadvantage right now is you can't have multiple apps inside of a single tab," so literally he comes back the next month with a talk of how I embedded more than one app in a tab and here's what I had to do it. First thing was like, "Let's see how does it break." Let me prod at it and poke it in and just see what happens. I know I had an experience recently where I had done something really, really stupid with Amazon Lambda and I just very recently came back like the fact that I had actually gone through the process of just deploying a very dumb -- ROBERT: How dumb, Charles? Tell me how dumb? CHARLES: Remember when I was going on and on about badges and how we needed to have our own custom badges. I kept on trying to get everybody excited -- JEFFREY: I don't know that we need that. CHARLES: That was pretty much the response that I got from, I think in a poll of nine out of ten. It was 9.11 or something like that. ROBERT: -- That was cool but -- CHARLES: It was cool but no one wanted to put it anywhere. The badge was just a static SPG that was served on top of the Amazon Lambda but as part of that, I had to go through all of the steps through actually getting it to deploy. While that thing was completely useless and it was thrown away, that knowledge ended up becoming useful almost a year later or maybe six months later, something like that. I feel like it was sunny so it had to have been at least six months ago and so -- ROBERT: You know, that it's always sunny here. CHARLES: Uhh... Ish. I mean -- JEFFREY: It's not Philadelphia. ROBERT: I was trying to work somewhere. CHARLES: It was warm but it's a practice that often has long term payoffs. I guess that's just the learning aspect of it, the fact that you're going to learn something. ROBERT: The thing I want to stress here is you don't have to go into it expecting that. CHARLES: Yes, that actually is critical. ROBERT: Yeah, that absolutely is critical because then if you expect that, then the problem with all the things for me started with setting expectations. It was always I had expectations. You take them and throw them out. Toss those things out the window. CHARLES: Zero expectations. JEFFREY: Really, it's an adjustment of your expectations to where at any point, you can say, "No, I'm kind of done with this. I learned something but it's not going to turn into anything," versus the expectation of, "I'm going to make something amazing that thousands of people are going to use." ROBERT: Yeah, that's the way I always start out as like, "Here we go." CHARLES: "I'm going to take over the world." [Laughter] ROBERT: "I'm writing another JavaScript frameworks. Next step, world domination." CHARLES: Yeah, I know it's absolutely important to make sure that if this thing that you're doing just cease to exist, you wouldn't feel good or bad. It wouldn't make any difference. Very Zen, I think. Some people try to approach every aspect of their life that way. I'm not sure if that's healthy. ROBERT: That's another podcast. [Laughter] CHARLES: But I certainly think it is, if you at least allocate a portion of your projects to be that way. I think that applies to any creative endeavor that you try to undertake. Jeffrey, you had some actually some non-programming examples that you were talking about earlier. ROBERT: It ties in nicely to the Picasso thing. JEFFREY: Yeah, actually I was I'm moving right now to a new apartment and I have no architectural background at all but I am comfortable with vector graphics in Illustrator and doing things mathematically precisely in there. I do have a little bit of problem solving that comes out of this. It's not purely exploration but I've been like, "I'm moving to this new place. These are the pieces of furniture I have. How can I rearrange them and play and --" ROBERT: Did you actually set the scale correctly to your -- JEFFREY: Oh, absolutely. ROBERT: Oh, that's amazing. [Laughter] JEFFREY: --Otherwise it's worthless. ROBERT: This is a whole new world. This is awesome. CHARLES: -- Like there's an atomic gauge on the couch. [Laughter] JEFFREY: My couch is six feet, three inches and 24 angstroms. I have not reached that level -- [Laughter] ROBERT: Does Illustrator have that level precision? JEFFREY: It can go pretty far. But yeah, it's just an opportunity to play around and like in a situation where actually moving those pieces of furniture in 30 different ways would be a pain and just unrealistic but thinking about it more in the abstract and just being able to play with it at a scale that's playable with, turns it into something fun and creative. CHARLES: Yeah, I guess that's a luxury that we have, I guess in the modern era of being able to simulate so much and be able to apply this practice of total creativity in a consequence free zone where people might not have been able to do so before. Before the advent of computer-aided design, I don't think that would've been a possibility. ROBERT: There will be a lot of manual hand-drawing and sketches and stuff. JEFFREY: And now software it's at point where -- CHARLES: Or you just get your children to do it. [Laughter] CHARLES: "Move it over there." You guys are sweating but man, I'm feeling really creative. JEFFREY: Yeah, really making stuff happen here. But software has kind of reach the point where we have similar abstractions there to be able to do it, move pieces around like that. Maybe not as fluidly as I'm going to move all these squares around in Illustrator but we're at the point where we can kind of plug in pieces and see how it performs and plug in another piece and see how that performs in a way that feels maybe more creative and less scientific than getting lower down in the code. ROBERT: Honestly, I wonder if this is where React began because the idea of rerendering the entire dom every time was more performant like you just throw something at the wall. See if it sticks. I don't know but -- CHARLES: Yeah, you have to wonder. I'm actually become surprised at the origin story is not more widely known. ROBERT: Yeah, I also don't really know it. I kind of heard of it like -- CHARLES: I remember hearing about it the first time I was like, "That's crazy." ROBERT: Yeah, that sounds like it'd be massive performance hit. That sounds really slow. Why would you rerender everything? CHARLES: Right but then again, it's always getting into pre-[inaudible] optimization. We always fall down these paths of optimizing in our heads. Of course, we want to do incremental rendering. Why? Because it's faster but nobody's actually measured then realized that it's actually the dom that's slow. ROBERT: It's like opening up your world to this. It's just like you explore everything. JEFFREY: That's another thing we can take from design thinking and the philosophies around the design field that maybe aren't as recognized in engineering is the idea of simply brainstorming of being open to dozens of ideas, trying out dozens of ideas and seeing what feels right and being able to have so many ideas that you can throw most of them away. In software, so many times we get to the point where maybe we'll have two or three ideas but none of them are worth throwing away. We feel uncomfortable throwing out any work. CHARLES: Part of it is you were so busy. You have so much invested in your current track that it's very easy because your current track is on Rails. It goes forward, there's clearly a path forward and to hop off of those Rails, it require some sort of energy and are you going to be leaping into like a chasm? I don't know. ROBERT: Or in Jeffrey's case, if your computer dies and you're forced to think without a computer -- JEFFREY: That actually happened the other day. CHARLES: That was amazing. That was worth a story. JEFFREY: I forgot to bring my charger to the office so I have one of those new [inaudible] MacBook with the USB-C charger and we didn't have any backups in the office. I was hacking along on some configuration devops kind of stuff and just kept running experiments and eventually my battery died. Then I was forced to whiteboard out by what I was doing and I came way over to conclusion that I would have ever come to, if I had just been sitting on my computer the whole time. It was another case of where I needed that abstraction away from looking at the code to be able to rearrange the blocks in a way that made sense. ROBERT: Pull yourself out of the [inaudible]. JEFFREY: Yeah, definitely. CHARLES: I really like that idea. Again, I'm not being too familiar with the way that the design world works. Is that kind of like a modus operandis to have too many ideas that you can throw a bunch of them away at any given point? ROBERT: Where you start stealing pieces from all of them and you make one master design. In my digital design class -- shout out to Miss McDaniel -- she would always make us start off -- JEFFREY: Check for that in the show notes. [Laughter] CHARLES: -- She would always make us start off in a sketch book and I remember because I'm not an artist at all. If you know me, I draw even the worst stick figures: my arms and stick figures don't line up. That's how bad it is. She would always make us start off in a sketch book and it drove me nuts. But after doing it for two months, I finally realized the value because she would make us come up with five or six different design concepts. Then after I did the process a couple more times, I realized, "This actually has a ton of value." I sort of picking things from one of the other. It makes you think outside the box. The first couple of ones that I would turn into her she would be like, "You actually have three of almost the same design here. You need to think more outside the box. Think of something that's completely different." Seriously, it's just like you're throwing things at the wall. Whatever freestyle off top of the brain and just let it go. JEFFREY: I'm thinking of a concept side of exercise where maybe you're playing around with layouts for selling a magazine or something and you'll sketch them out and you'll sketch out maybe a few dozen of them but you don't get into the nitty-gritty details. You do it at a very-low fidelity where it's just pencil and some boxes and rearranging those boxes and maybe mark what that box is but you don't worry about the details of that box until you mix and match like, "That layout is not going to be great. This layout seems like it might be along the right track. I like this piece of this one. Let's combine them and make something completely different." Then once you have that high-level view, that make sense to you and you've gone through lots and lots of iterations, then you can start honing in on the high-fidelity details. CHARLES: This conversation makes me feel like there's definite poverty in our processes as software developers in the sense that what I'm hearing is that these things are just taken for granted, that these are the activities that you're going to be doing as part of design and what are we doing if not design. Each of us has these experiences that are kind of these one off things where we actually experience this creative space. It seemed very special and it seemed revelatory but really, it almost sounds like you need to make sure that it's something that you're revisiting again and again and you're doing it as integrated with your work. But I feel like it would be hard to pitch that -- JEFFREY: That's not understood to be part of the software design process. CHARLES: Maybe that's a little bit of what happens when we've put together our design documents -- ROBERT: Yeah, it just occurred to me like looking back through my history of how I landed to be a software developer, I actually wanted to be a designer first. That's why I was in digital design and stuff. I rejected design so much because I thought it was super... What's the word I'm looking for? Flighty? CHARLES: Wishy-washy? Non-committal? [Laughter] ROBERT: Anybody could walk in and say, "I don't like that design. It looks ugly. It doesn't look good," and I thought I was going to programming because it was more black and white like, "This is the right solution. That's not the right solution." As I've worked my way into my career, I actually realized they're actually really similar because you're designing software and software is abstract. As much as you want to try to think about as it's not, you start to develop this mental picture of the programs that you're developing. You're designing these things. It's just a different form of design and design is problem solving. CHARLES: In digital design, it's not artwork. It is measured by some quality. It's just hard to put your finger on but there is some kind of external measure of, "Does this fit the purpose for me, which it was made?" JEFFREY: "Does this solve the problem?" Usually, there are some expectations just like there are software of, "There's been best practices established. Did you stick to those best practices? And if you didn't, Why not?" Because sometimes there is a good reason to break those best practices. CHARLES: Right. I wonder if it would be interesting at integrating into our process like what we think of as the ideal pull request or issue reporting or design document have. It kind of similar to some of the RFC processes out there. It's like, "What are some crazy alternatives?" Not just any alternative -- JEFFREY: I don't just need viable alternative. CHARLES: Yeah, I don't need viable. Give me the in-viable. Give me the ones that are like, "What crack are you smoking? Oh, wait a second... Hmmm..." [Laughter] ROBERT: "All right. Here we go. I got it. It's got to be powered by nuclear --" No. [Laughter] CHARLES: Curious. I'm very, very, very curious. ROBERT: Let the curiosity fly. JEFFREY: Charles, do you had a blog post recently about a dumb project you built. Would you tell us about that? CHARLES: Sometimes, it gets stressful around here. Sometimes it gets stressful in life. Sometimes you just feel stress and there are a lot of things you can do to deal with it. Everybody has their coping mechanisms. For me, one of my secret weapon coping mechanisms -- ROBERT: Not a secret anymore. CHARLES: It's not secret anymore. [Laughter] CHARLES: This also will be in the show notes but I'll go ahead and say it right now is ChillestMonkey.com. If you need to enhance your chill, you can just go to ChillestMonkey.com and I guarantee you will not be disappointed. You will feel instantaneously better. I was in the point where I was feeling a lot of stress. I don't know exactly how it came up but I was actually with Stephanie and she was like, "Charles, you just got to do something stupid. You just got to do exactly what it is that we've been talking about on this podcast. You've got to just do it and you've got to do it fast and you've got to not look back and look forward." I was like, "Oh, my God. You're right." That planted the seed in my brain but then, I think it was the next day, I was talking about ChillestMonkey.com -- go check it out. You can pause the podcast right now and go have a look at it. It's really awesome -- And I was showing it to everybody and then I think Rob were like, "Oh, my goodness. We've got to have this on the Apple TV." ROBERT: It just lands itself perfectly. CHARLES: Yeah, I was like, "Yes. Absolutely we need it on the Apple TV. We need it on the Apple Watch. I need this on my iPhone," so right that minute, I hearken back to the conversation I had with Stephanie and I was like. "This is it. This is perfect scope." I have been looking to build something in React Native. Something that I can just completely and totally throw away, something that fits in a small time box and I also have this opportunity to build this thing that I really need but if it doesn't work out, it's fantastic. I went home. I think that was that very night and started hacking on React Native and took the Chillest Monkey, then put it first into an npm package. You can include it in any React Native application. Then once that was accomplished, I went out and checked the support for Apple TV had dropped literally ten days before, maybe even less. I was like, "It's a sign and this has got to happen." It was a little bit of a slog but we were able to get it up on our Apple TV and with a remote and feel that glassy touchpad, move it over to the Chillest Monkey and open it up and just see those wisps of hair and those tranquil eyes up there and six feet across. It was just such a great feeling. But it was something that was accomplishable within a day or two. I don't think it was more than that but it serve the purpose that I was able to learn a lot about React Native. I was able to learn about packaging, shared components. ROBERT: Actually, I remember we fought about flex box and what not for a little while. CHARLES: Yeah, that's right. I learned about laying out images and kind of the best practice around there. Also, I think this is important as I got to experience a win and it felt good to be able to experience that win. It felt like if I hadn't experienced it, it probably wouldn't have been that big of a deal. But the fact that I was able, it was a low-hanging target but it felt like a big-hanging target. It's hard because there's no such thing as a free lunch but kind of there is, when it comes to little projects like this because when you see something totally stupid come together and it works exactly you wanted it to work, then it feels like you've accomplished something major. I don't know if that's some sort of brain hackery or some sort of life hack or what but that was extremely good for my internal morale. JEFFREY: This is an example of a project where, maybe you didn't get as much creative juices flowing out of it. CHARLES: No. JEFFREY: But you've got a high accomplishment and learning value, which I guess are all, I call that the iron triangle of building dumb stuff. [Laughter] JEFFREY: You can have two of the three. CHARLES: On one side is creativity, on the other side is what? JEFFREY: Accomplishment. CHARLES: -- Is accomplishment, just shipping it and then on the third is time? It's the iron sticks -- [Laughter] JEFFREY: The third side was learning. That's creativity, accomplishment and learning. You can't have all three, sorry. It doesn't work that way. CHARLES: It doesn't work that way. Okay. [Laughter] ROBERT: Then you'll take on a big project, that's how you'll get all three. CHARLES: I like that. JEFFREY: In a particular project where you're having to throw tons of ideas at the wall, You're probably going to be learning, you're probably have to be very creative but your chance of shipping here is much lower. CHARLES: It's almost a detriment. ROBERT: Yeah. CHARLES: Whereas in this case it was take something that is easily accomplishable and accomplished it. JEFFREY: And you learned something from it. CHARLES: You learn and you accomplish but you're not particularly creative. But it's still a feather in your cap. I like that. It's a good way to categorize it. ROBERT: And the accomplishment is how you define it. In this case, you actually finished this project. CHARLES: Yeah. I finished it. We have it on Apple TV. ROBERT: Yeah, and like you said, you have to do that. For me, after I did a couple of these things, actually what I just do, a newsletter has come in and somebody was like, "Look at this new thing," and I'm just going to put it off to the side and then eventually, I'll stack two or three of those things together and decide, "We're going to take all three of these things, we're going to put them all together and see what happens," and that's how GraphQL and dove in to create React app. CHARLES: That's actually a good idea. I like the random newsletter driven development -- [Laughter] CHARLES: -- You're like, "I'm going to subscribe to this newsletter. I'm going to pick one thing from each week and after I have five things, I'm going to build something with those things. ROBERT: Wait. I have a dumb app idea. We could make this just a random app idea generator. It takes ten packages and you see like -- JEFFREY: A bunch are required to build the Hackernews clone. Isn't that a classic newsletter driven development? ROBERT: Or the Reddit clone? This feel like that's the React thing -- the Reddit clone. CHARLES: Yeah. I think it's more like Frankenstein driven development like you've got GraphQL, Vue.js and I don't know... Datomic. JEFFREY: Like a GRD stack -- CHARLES: No, like a rando stack. [Laughter] CHARLES: Rando.js, that would actually be a good -- ROBERT: You hear it first. It's our new JavaScript framework. CHARLES: A stack generator. JEFFREY: It's going to be a high on learning and not so much on accomplishment. ROBERT: You won't ship anything but damn will you learn? Every week! CHARLES: What is an example then? We've talked about the one where the accomplishment. I'm wondering if there's an affinity between those sides of the triangle. What would be an example of a project that was high on creativity, low on shipping? How do you approach projects like that and then make it okay to fail? Because I think, one of the things that was great about the Chillest Monkey Native was I did get to ship it. It wasn't much but it felt great. How do you prepare yourself for those projects which are high on creativity that you're not going to ship? What is one of those look like? JEFFREY: I think those kinds of projects are usually tend to be ones where you're more comfortable with the tools already so that you do have the space to be creative and you're not having to fight against, "I don't know how to do this." The learning is already been done, at least to a point to where you're comfortable enough to go, to feel loose and creative and be able to brainstorm without having to bump up against walls over and over. CHARLES: I guess, tender love is a master of that, where it's really has a deep knowledge of Ruby and systems programming and does some fun and creative. Do I say zany? ROBERT: The Ember example of this, I think it's Alex Matchneer. Matchneer? CHARLES: Matchneer, yeah. ROBERT: Sorry, I cannot pronounce names. The Photoshops, I mean those aren't exactly -- [Laughter] ROBERT: -- Those aren't exactly programming related but -- JEFFREY: High on creativity and accomplishment, low on learning. [Laughter] ROBERT: And then the Ember Twiddle is the one that I laughed out and I was like, "Can React router do this?" CHARLES: I don't actually see that one. ROBERT: Actually, it was broken when I went to look at it but the responses were hilarious. They're like, "Actually, no. I'm happy. I can't." [Laughter] ROBERT: But he always has the Twiddle and he's like, "What about this? It's like the programming equivalent of his Photoshops. [Laughter] JEFFREY: I'm wondering if there are particular, out of those kind of three different types of dumb projects that we've identified. If there are particular types that people gravitate toward like I know that I am higher on the, "Just go, do something creative with tools you already know side," versus, "I enjoy learning," but I'm more likely to want to accomplishment up things and be loosen in my creativity. I'm wondering what the breakdown is among different engineers of those different profiles. ROBERT: It's quite interesting and I wouldn't think of myself as an explorer but I feel like I'm driven by FOMO -- fear of missing out. That's where this comes from for me. All this technology that I hear so many good things about that I haven't even done anything with. I don't even have Hello, World or anything. That's usually where I start picking things up the shelf and I'm like, "What if I did redux, Vue.js and whatever else. Let's see if we can make all these things work together." CHARLES: Do you feel like you can, at least always be kind of touching? ROBERT: Yeah. CHARLES: Pinging different areas of the ecosystem? ROBERT: Yeah, I really like to see what they're doing because they all have different takes on things. I really like what Chris Freeman said, he's like, "I feel like programming is just gaining experience points." Like it's video games where you're just going through and you're getting experience points with different things. That's kind of the approach that I've been taken for the past five months. Since I discovered this, this is just like, "Oh, that look shiny." Maybe that's also driven because of our JavaScript-type cycle or whatever you want to call it, where something new is always coming out. Somebody is always reinventing the wheel. CHARLES: Whenever I see a cool demo or whenever I read a really provocative blog post that guides my exploration a lot, which I guess those things usually are extensions of some activity like what we're talking about that someone did. A lot of really good blog posts are just like, "I've been doing this stuff for five years and I have gained an absurd level of expertise on it. Let me take you to school." I definitely love those but a lot of it is like, "Look at this cool thing that I've done." Without talking about murdering names, what is it? Hakim...? Gosh, I can't remember his last name. The guy who does Slides. Some of his demos for CSS and JavaScript animations back in the day we're just like, "Woah, someone has just revealed a huge power source," and so I want to go do it. But most of that came from him just having to play. ROBERT: Jeffrey, you've actually got my brain ticking here. I'm thinking about where people fall in applying this like just go do something dumb and it doesn't have to mean anything. This makes me starting to think, "Maybe I need to go do something really creative in Ember." JEFFREY: It's making me think that I need to go do some learning -- [Laughter] JEFFREY: -- Just try some new stuff so I have new tools to play with. ROBERT: Because that's the whole purpose of this, right? I just recognized that I am not doing very creative things and the tool sets that I am comfortable with. CHARLES: Yeah, it is harmonious. The more learning projects you do, you acquire tools and then with familiarity with those tools, engenders creativity so you can see how the process feeds in to itself. ROBERT: Now, I'm going to build something creative. CHARLES: All right everybody. There you have it. Go out, build something useless, build something creative, build something that will help you learn and acquire new tools, new techniques and take you [inaudible] and do it quickly.

In this episode, Yehuda Katz, co-founder of Tilde, OSS enthusiast, and world traveler, talks about what's in store for Ember. Yehuda Katz: @wycats | blog | GitHub Transcript: ALEX: Hey, everybody. Welcome to the Frontside Podcast, Episode 46. My name is Alex Ford, subbing in for our usual hosts, Brandon and Charles, today. We have an awesome episode. We have a really special treat for you. Co-creator of Ember, Yehuda Katz is joining us today. Hello, Yehuda. YEHUDA: Heyo! ALEX: We also have a first time Frontside podcaster, Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hey, everybody. ALEX: We've also got a podcast Frontside favorite, Robert DeLuca. ROBERT: Favorite? I don't know if you say that. Hey, everyone. How are you doing? ALEX: I'm really excited about our guest today. Yehuda was just in Austin a couple of days ago. He gave a great meet up talk and a deep dive into Ember and it looks like you're going on-tour with that talk, Yehuda. Is that what I saw from your website schedule? YEHUDA: Yeah, I'm not sure exactly. I change it up every time, largely because things happen. So if I say this thing is 'active' or 'in progress', and then it actually shifts, I have to change it up. I've been talking a little bit about what's up on what we were working on. ALEX: Do you want to give us a brief outline as to what's going on in that talk for those podcast listeners who might not be able to attend? What's going on with Ember? What's new? What is it that you're trying to get across here? YEHUDA: Sure. Actually, the talk I gave in Austin was, you're right, it was basically a deep dive. It was really focusing on a few targeted things that we're working on. I would say that at a high level, we're basically working on a couple of things. One of them is generally more integration with the ecosystem, things like ES6 modules, classes, components that look more like HTML and more graphic components and things like that, also improving EmberCLI so it's more integrated with other tools that people are using. A lot of that stuff has to do with the fact that Ember started a long time ago now, like five years ago or so. And so, I think we've actually done a pretty good job of keeping up with things. For example, we adopted ES6 modules and promises a while ago now, and I think generally speaking, we tend to keep up with the ecosystem. But because we've been around for so long, there are certain things like classes, where it took a while for that feature to catch up with the functionality that we were using in Ember. Decorators landed a little while ago as a stage 2 feature in TC39, and that lets us really take a bigger chunk of the functionality that we have in our class model. I make it work for everybody with class syntax and that's something we're pretty excited about. So that's one area just generally taking things where Ember had its own stuff and try to integrate a better ecosystem. Another big area is this mobile readiness and also, a lot of that has to do with the fact that things like service worker have just recently landed. For example, AppCache was a nice feature in some ways. Some people at Google will kill me for using the word 'nice' in AppCache in the same sentence. [Laughter] YEHUDA: But AppCache was trying to accomplish something for a long time. I think it did some version of what it was trying to do. But really, using AppCache is a default behavior for all users having - there's too many caveats to make it work well where service worker, because it's more of level one and more directly controllable is a better fit for something that we could ship with all Ember users. We basically want to use Ember and EmberCLI, you build an application, you get a good mobile experience out of the box. Some of that has to do with trimming down parts of Ember that we don't need to be using in simple applications. Some of it has to do with service workers, some of it has to do with things like Glimmer 2, just making the performance better. But generally, that's the other [inaudible] so it's basically mobile readiness on the one hand and just integrating better with the one ecosystem are both big picture things we're work on. ALEX: Something that you brought up in your talk where private Ember methods and how a lot of people use private methods and you have to keep them around, what you we're just talking about that was unifying around the conventions of programming in Ember. Whatever JavaScript people bring in to Ember, you want to try to incorporate that as the language moves forward which is, I think, a really interesting problem. Also, something you could talk about a little bit further is what you look for in the way people use Ember going forward and how you have to kind of bend the framework to allow it to be backwards compatible. I'm curious what that decision making is like. YEHUDA: What you're talking about and what I talked about yesterday is what we call 'intimate APIs' and that basically means APIs that we never intended to be public. But for some reason or the other, people got their hands on them and started using them. I gave a somewhat elaborate example of funky case yesterday. But basically, the way we approach generally dealing with compatibility is pretty similar to how the web itself does it. First off, there's a thing that we mark as a public API. We just don't break it unless we make a major version which is very rare. We have basically one of those the entire Ember, and I don't think there's anyone coming in the near future. One option is if we don't like something, we just break it. That's very uncommon. Another option, and this is way more common, is that we try to build -- it's for public APIs -- we try to build a new API and we try to nudge people away from the old one. One approach for nudging that is probably the most common is deprecation. So, deprecations themselves don't violate semantic versioning because we're allowed to say, "Please don't use this anymore." The one area that's annoying about deprecations is that if backup code that powers the old feature has to still stick around. And so something that we've been working on around that aspect, around deprecations is something we called svelte build, which is basically the idea that we'll mark every deprecation with the version, that it will start to be deprecated in and people can ask for, "Please don't include any code that was deprecated out of 2.4, or 2.5, or 2.6, or whatever." Then, we'll automatically slip it away. You could think of it sort of like as a reverse feature flag. CHRIS: Wow, that's actually super interesting. I didn't know that. YEHUDA: We haven't finished it up yet but the RFC that talked about it and actually some old guy who actually wrote the RFC along with 1.13 when I noticed that 2.0 was going to end up being a pretty painful release for a lot of users. We did a lot of things around 2.0 to make things less painful, like we made sure that 1.13 contained all of the deprecations that you could possibly need, as well as all the new features. So if you went to 1.13, you could look at all the deprecation warnings, switch to the new functionality. As long as you have no deprecations left, 2.0 was just the exact same code without any of the deprecated features. But as we're working on that, I realized that there is no real reason to give people such a heartbreak, if we could instead just slip away the code. So that's one approach and I think, more or less deprecations, and then eventually, svelte builds are the normal path. With regard to intimate APIs, those are cases where people came to rely on very specific timing or very specific API, very specific details in some internal API and for those things, if we know that a lot of people use them -- usually they get used to like a couple of add-ons. Maybe Ember Wormhole, which is really popular, we'll use it. Then it's really hard for us to remove those things. Those APIs are harder to maintain compatibility for because the exact details of what they even did was never really well-defined in the first place because they were never documented. So usually what we'll do is we'll look at the usage of the API. We'll come up with a new API that is satisfying the exact same use case, and then we'll deprecate the old API. The policy these days is that you have to go through an LTS release so we'll make sure it's deprecated. Let's say, you want to deprecate something now, make sure it's deprecated in 2.8. And you'll know that if you were actually doing the whole song and dance that deprecate what is intrinsically a private API, so it would be within our rights to say like, "Sorry guys. You used the private API. We're not going to help you." But we really think it's important that for Ember, if something feels like a breaking change, that we're not doing it willy-nilly. If somebody upgrades to 2.9 and all of the sudden, Wormhole stops working, they're not going to understand that the reason that happened was because Wormhole did a bad thing. We basically need to do a clear pass. So we'll do a deprecation in LTS release, then we'll wait a couple of releases before removing it. Then usually what happens is, in the meantime, we'll go ahead and we'll submit pull request for the big add-ons that we're responsible for, and we'll also try to talk and write down why it happened. Historically, we've done that a few times and it's worked okay. There was an example of this, which is the lookup factory API in Ember which is really a boring API but it's used by a bunch of high profile add-ons. So the reasons why we needed to deprecate it were silly. They were just a bunch of bad behavior in the old thing that was making everything super slow. We can make things faster by giving people exactly the same functionality without exactly but identical guarantees. So there were some 'guarantees' which don't even make sense for private API. But there were some things that in theory, the API did that we didn't want to support because of performance reasons. And so, we gave people a new API that is, for all intents and purposes, identical. All users will be able to use it in identical way. But it doesn't have exactly the same weirdness and that weirdness was pretty expensive. ALEX: So you've trained Ember developers to be on the 6-week release cycle? They're looking at the blog posts. They're looking to upgrade but you've been involved in a lot of open source projects where I'm sure that wasn't really the case. Say, jQuery has a huge API and obviously, some things have to be deprecated on that and you were on the jQuery core team, I should mention. YEHUDA: Rails has the same story whereas API releases every year, more or less. ALEX: So, I'm just curious. The fact that you have Ember developers, I would like to think bingeing on your word and hinging on those updates, how would you go about, say, the Rails API? Or the jQuery API? Maybe, now you're involved with Rust, and maybe the plan is to have Rust on a 6-week release cycle. I'm curious, if you don't have your developer's attention, as you do the Ember developers, how do you deprecate an API like that? YEHUDA: That's a good question. How do you deal with deprecations if you're releasing quickly? I think there's a couple of important points to make here. First of all, Rust is on the 6-week release cycle. Sometimes, as the same kind of story with intimate APIs, it's much less common with a strong-type system like Rust. I guess, important things to point out, first of all, deprecations don't intrinsically break things. When we talk about intimate APIs and deprecations happening pretty quickly, those are APIs that are large, if someone is not paying super attention to Ember, they're probably not using those APIs, like they would not have known to use them in the first place. They might be using an add-on that use those APIs and the intimate API deprecation process causes the add-ons to update relatively quickly. In terms of regular deprecations, those deprecations stick around forever so you could come back a year later. For the most part, you could make an app that was 2.2 and upgrade it to 2.9 as long as you upgrade the add-ons that you are using at the same time and everything will work. We also realized that some people can't upgrade every six weeks and that LTS release process which is basically a six-month process, more or less. It basically gives us a communications channel to people who want to pay less attention. The way that that works is that, every four release cycles, so that six times four is 24 weeks -- about half a year. Every 24 weeks, there's another release. We assume people are on that release channel. Some people operate at 2.4, 2.5, 2.6, 2.7, 2.8. Some people go directly from 2.4 to 2.8. For those users, we [inaudible] ecosystem, please make sure you support the last LTS release, which means that if your user's on 2.4, and 2.8 comes around, you know that you could have stuck to 2.4 and generally got add-on support and when 2.8 comes around, you should probably upgrade. Also, with intimate APIs, we make sure we always deprecation them one LTS release before we move into an LTS release. Now, what that means is that if we want to remove something by the 2.8 LTS, we have to have already deprecated it in 2.4. If we want to remove something by 2.12, we have to remove it at 2.8. So six months is still not quite the one-year Rails release cycle but it's starting to get to a reasonable state. Also, I would point out that the LTS releases, the support policy for them is that they're four cycles long. We do bug fix support for six cycles and security releases for 10. What that means is that we're actually supporting LTS releases. We were supporting two at a time for security patches -- two and half basically -- and we're supporting one and half at a time for critical bug fixes. The one and a half basically means that when 2.8 comes out, you have two release cycles which is basically three months to upgrade. If you're on 2.4, and 2.8 comes out, it's not like, "Oh, my God. Panic! I got to upgrade right now." You can take a few months to upgrade. Basically, 2.4 came out, you got all the deprecations you need to care about. You had six months to deal with deprecations and then another three months after that. Even in terms of intimate APIs, where in principle, like Rails and jQuery don't even care about those things for the most part -- ah, jQuery cares about it even more. But most projects will get private APIs and say, "Sorry you used the private API. Why did you do that?" Ember is a rare project in that we actually deprecate things that we know where we actually use them. We have a process for dealing with them. Even that process, like I said, it's not a six-week process. We don't deprecate something and remove it. We deprecate something and then give it a pretty long horizon before removing it. ROBERT: I'm curious. You brought up that you are the common element between jQuery, Rails, and Rust. I know that there are, at least, between Rust and Ember and from Rails to Ember, there have been a lot of commonalities and lessons learned in how the projects themselves are managed. But I'm also curious with Rails, Ember is clearly pretty heavily influenced by Rails, which you were doing before. You've been working on Rust quite a bit and I'm curious, does your usage of Rust, even though it's a very low-level language, does that influence Ember at all? Does that change how you think about the framework or JavaScript in general? YEHUDA: The number one thing that I got out of all those projects that I think used to be a thing is something like a conventional reconfiguration idea which is really not - I think the mentioned of reconfiguration is probably not even the best description of what it is. I think the idea that communities that are all working together on the same thing to build that thing bigger and better and better and better and build ecosystems around that thing, those communities are able to build much higher than communities that ask every single developer to put together a bunch of pieces themselves for profit. That's the basic idea. If you look at Rust, which is conceptually very low-level, you'll find that there are things like Cargo, which is a tool that not only builds your thing and not always package manager but it has a convention -- not only a convention -- it has a built-in support for documentation. So you're on Cargo docs, you get all your documentation for all your dependencies. You run Cargo bench. That's a built-in thing that runs your benchmark. You run Cargo test that runs your test. To mark your documentation as being Rust code, it will automatically run your tests for you when you run Cargo test. We will build your examples for you and make sure your samples keep compiling. There's all this stuff in Cargo that you would not necessarily consider, like it's basic [inaudible] helping you get your workflow the same. Then there's things like Rust format which you've been working on and there's been a huge debate in the community about exactly how much configuration we want to allow in Rust format. But the irony of it is something that most people agree with is that we should try to come up with some kind of default style for Rust that everyone agrees to, that most people can pick up and use the Rust products where it's often used. Then there's things like Futures and [inaudible], where the goal of those libraries is really to make there be a single central way that everybody does [inaudible] in Rust. These are all things that if you look at like C or C++, which are languages that are sort of in the same low-level in this space, in the same kind of area, you'll find that those languages have billions of ways in doing all of those things and there's so many different styles and so many different workflow tools, so many different things that you can make in then a million things that [inaudible]. Even the Rust is conceptually low-level, it doesn't really affecting every single environment as some sort of things that everyone doesn't need to do themselves. I think, an important thing that people don't always get about convention configuration is that it's not just that everybody doesn't have to do all of those things and it saves you some time, it's that when everyone is doing the same thing, it's a lot easier to build another level on top of that. For example, a fast food is a great example of this in Ember. The fact that everyone initializes their application using an Ember initializer, the fact that services were these global things that are sort of global- there's no better word than 'services' but global services, the different components could share the fact that those are all going in the same place. The fact that the way we manipulate DOM is always in a constraint single area. Almost things mean that when it comes out and to build something like fast food, it's pretty easy to take almost any Ember application and make it run in the fast food environment because we know what we're looking at, and that's something that isn't necessarily true about other tools. For me, Chris, the number one thing that, I think, all of those sharing, including jQuery, actually, like jQuery said, "There's so many different ways that people do DOM manipulation, why don't we unify it into one thing that I everyone can use?" You know, the 'jQuery plugin', which is something that has falling out of favor over time. The reason it was so popular was largely because people knew, "Okay, I'm dealing with jQuery object. If I just put a plug into the jQuery object, it makes sense." People understand how to use it. I think that's something that a lot of projects that I used to share and it's also something that is not close to ubiquitous. It's very uncommon, actually. So that's one thing -- the conventional configuration story. I think, another major aspect of all this, and this is something that jQuery and Rails do not share, but Rust and Ember have the RFC process, which more or less, is just a wave as a community of saying, "The way that we agree to add new features to the project is not something coming down the [inaudible] with a tablet every year." At a conferencing, we have agreed to add these features but sometimes people are core team, but sometimes they're not. Sometimes, they're actual contributors, coming with an idea, write their view down in a format that we all know how to do with. Then there's a community discussion about it. Sometimes it takes a very long time. Sometimes it's not. But then we eventually come to a conclusion about what it is that we're doing. Eventually, the core team agrees to merge the RFC. I think one of the nicest things about RFC process is that it produces an artifact that you can come back to a year, two years, three years later. If you say, "Oh, I wonder why they've made that decision. I wonder why that's the thing that they did," and the reason why this is great is that the RFCs are not gospel. They're not something that we should hold onto forever. But at the same time, we don't want to reel it again, things that we already discussed that in-depth over and over and over again. If a person comes back and they say, "Oh, why do they do that? The modification of RFC, why are these instructions directors are like that?" If they go back and look at the RFC and the thread associated with it, and the thing that they want to bring up is something that was already discussed, it's really no reason to bring it up again. But maybe someone have thought of a different idea or a different reason to dislike or to disagree with the decision that was already made. That was already discussed. That's a much better rationale for bringing up for re-litigate. In other words, re-litigating is actually good but if you re-litigating five times a day, on every decision, that's not why you move. So RFCs, by their very nature, the fact that the core team is doing things in public like anybody else and everybody else is also participating in that same process, the fact that artifact tells you, more or less, exactly what was discussed, makes it really easy to decide when is a good time to revisit some of the questions. ALEX: Do you find that poll request has the same process as an RFC and it's an artifact you can go back to, it's a place to have communication that is visible to everybody, unlike say, this micro message service such as Slack where context is just lost for the public. I'm curious if you want to see that modeled in poll requests or if an RFC is where something like that belongs. YEHUDA: I think, poll requests are great. I remember that when I was somewhat like the first user on GitHub who's not a founder of GitHub. I remember one of the things that excited me about GitHub early, although, the very beginning, didn't have poll request yet. but one thing that excite me about poll request is that before poll request, every single time I would use an issue tracker so they were like a billion issue trackers like [inaudible] whatever, and at that time I called it 'patch management'. I want something that helps me manage patches because the actual discussions are not the higher of it. The higher of it is something that submitted a request for me to merge in this patch. How do I merge it? How do I discuss with them? Those things were always really hard so I might ask people to upload patch files or whatever. It's hard to remember how bad things were but the number one thing that was just so obvious but also so terrible about the ecosystem before GitHub was patches were like old mailbox approach. Like you'll make a patch, and hopefully, get it to the right place at the right time. So I think, poll request and comments of poll request and many of the improvements that have been made for poll request are great. The reason, I think, RFC are really important in addition to poll request is that, by the time someone actually took the time to write some code and submit it, it's very easy to look at it and say, "Well, I don't necessary agree on all the things here but I don't want to give a person a hard time that will do the work," whereas somebody submit some idea early on and they say, "I have this idea --" It's actually a lot easier to sort of get into details at that point and say, "Don't do this. If we should do this or it doesn't fit that well with this other RFC or this other poll request that's already open --" But once somebody actually does start and actively working on the feature, I think, poll request are great, like most open source project these days. Ember doesn't ever committed anything to master. Everything goes to poll request, and even core team stuff. I also find that when I submitted a poll request or anybody in the core team, there are almost always people who are not in the core team that saves or fix in the poll request, for various reasons. Of course, poll request also are the usual mechanism by which people run things like CI and linting tools and things like that, called quality tools. I think, the poll request workflow is really good. In terms of other messaging services, I think, there just sometimes the need to have conversations that are faster than poll request and I don't really have any problem with check conversations. But I definitely agree that it has a deep conversation. This is something that happened in the [inaudible] a lot where we having this conversation with the core team and somebody will say like, "We should really move this out into a public discussion, or move it into RFC. If you don't agree with this thing that somebody said public, can you say [inaudible]." So I totally agree that if there's a thing that people want to say in private about something but it's just in private for convenience, it's not private or transient for any good reason, actually getting out there onto the issue or the poll request and say your opinion and letting the conversation back and forth happen there is, for the exact same reason as you said, very useful. In fact, Aaron Turon from Rust brings this point out repeatedly. We just had a conversation this past week about the fact that we have sort of a normal Rust project that, let say in the core team room and it's a technical topic, and it doesn't have anything sensitive about it, people always say like, "Hey, can you move that into Rust Internals," which is a public room. Or like moving this course, we have internals at Rust-Lang.org and I keep thinking Ember could use it. Basically, this sort of a hierarchy of private to public or transient to sort of a free-form discussion forum like this course to something like a GitHub issue, something like an RFC to something like poll request. There's like a hierarchy of how much of those artifacts are easy to search and find. But I think, you're totally right that there's no reason why, things like the core team needs to exist because at some point, the buck has to stop somewhere. Somebody has to make decisions. Somebody has to actually responsible for laying out the cross-cutting vision for the entire project. But those things are actually pretty lightweight. The core team when it's doing its job, it's just sort of making an omnibus of everything that the community is thinking at a particular point and making it more concrete. While, I think that's important that there are spaces which are core team spaces, or spaces that are transient, I think, a lot of questions that people have in the Ember slots are important that people who can just jump in and ask them. I think, getting things out into both public and more of permanent artifacts spaces is good. ALEX: Rob, you are a co-runner of Ember ATX and I was hoping you could speak on the fact that we've gotten some core team members down to Texas to come talk. It's nice that they're able to share their message with what's going on in the core team. But also, they're doing work. They're seeing how real people use Ember and then taking that back to the core team. I was wondering if have just want to comment on that and your work on bringing some really excellent people who make decisions down to Austin. ROBERT: As a meet up runner, like a co-runner, I guess. It's me, Jeff, and Lydia that run Austin Ember ATX. We really like to try and bring people that are deep into Embers core into Austin to talk about the framework that these people work in daily. It's always awesome because whenever you get them there in the flesh, you can ask questions. I guess, we can go back to where Slack is, like you have the higher bandwidth communication but it's even higher bandwidth when you're in person. Getting those people to talk to people that are actually working on the framework daily is I think, hugely important and that's why we work really hard to try and bring out people that work on the core. YEHUDA: For what it's worth, I think that Rails and Ember shares a common core value, like other projects have, more or less. Ember core team people almost exclusively actually work on Ember apps as part of their jobs so I work on skylight. Having some responsibility in the real world for apps that you are working. It's a big difference in just [inaudible]. I definitely noticed a few. Sometimes, I'll be working on a project for a while, like when I was working on Rails for 18 months and never actually used Rails. I mean, I used it but not for anything significant during that time. I, sometimes, get into a rut where I'm working on Ember a lot and I haven't had a chance to work on an app at all. Then, you go back to work on that for a day and it's like, "Oh, my God. There are so many obvious things that I can make better here." Like the kind of things that you would think about when you're working on your framework stuff is not necessarily- as quick it gets, the quickest things that you can fix. The Ember welcome page is a good example of this. I think, when someone is training, it's very easy for them to notice that it would be great if there was some kind of welcome screen for people. But it's not something that a framework author would necessarily think of on your own. Similarly, getting down to places that are not my usual haunts and hearing people bringing stuff that I just hadn't heard before. Like things, "Oh, that's a good idea. But I haven't heard that." A lot of that just come from the fact that the core team has a lot of different kinds of users in it so the people doing training, there are people doing apps or people doing consulting, there are people doing rescue projects in that kind of combos is pretty good. There's a long tale of all kinds of stuff, like people using web sockets for network people using React. People are trying to do Redux in Ember, who knows? That long tale is impossible to represent all that long tale. In a core team, we try to get as much as possible. It's impossible to represent all of them so going out there and talking to people doing weird stuff and weird doesn't meant pejoratively, just unusual stuff. Like Ember, really wants to be pretty flexible under the hood. Even though, it's a pretty conventional tool, we want it to be flexible under the hood so I kind of no way of flexibility is but sometimes, I'll talk to somebody and I'll be like, "Oh, in retrospect, that particular thing, I thought that was flexible as missing as little knob that we can add." So I really enjoy it. CHRIS: Since you've been pretty heads down on Glimmer 2 and you are actually traveling out and talking to people, I'm curious, are you noticing any common themes from the feedback that you're getting recently in terms of what users are saying? Do you have an indication of what the next move might be? Or what people are asking for? YEHUDA: For Glimmer specifically? CHRIS: For Ember in general, or Glimmer specifically. But I imagine, you're probably getting general Ember feedback. YEHUDA: Yeah. I talk about this a little before like the two big areas of interest are mobile readiness and better integration with the ecosystem. Integration is the wrong word. There's nothing wrong with Ember to that extent but people want classes. I think, those are the biggest picture things. I actually noticed a couple, somewhat interesting things when working with Ember. We ship the Glimmer Beta six weeks ago and we're doing another beta just because there's a couple of bugs that we got that were trickling and we want to make sure we get it right. I've actually noticed the people have on the one hand, the story of Glimmer is that we're pretty similar to React in the sense that you should think of what we're doing as a top down, you render the whole time and that there are some nice [inaudible] that use Ember.set or the set API, then we are able to do what people should do with component update automatically for you. For [inaudible], then we know, "Oh, this whole area, doesn't need anything to be updated." If you think about it that way, if you think about it as how can we render [inaudible] around set, I think, you'll notice that Glimmer updates are always faster than React's updates. But people have come to really rely on the sort of quasi-guarantee that if you didn't update something, it doesn't change the DOM associated with it, or even execute code associate with it. I find it sort of interesting. This is like meta problem, which is React actually got some things right about how to make this story performance. Part of that has to do with not assuming that you need as much bookkeeping as Ember always assume that you need. In exchange, you get much faster initial render and you have to do more work around updates. We actually have a pretty good story here. Ember.set is pretty nice because it lets us use API that our users are used to, say, generate [inaudible] upon updates for you and that's nice. But people get very upset when things run that they didn't expect, which of course, is not how React people think about it. The way React people thinking about it is, of course, [inaudible]. That's the whole API. It runs until you told not to. In Ember, things run at people who don't expect to get very angry. I think, you have to be one that I'm thinking about and that's a lower [inaudible]. But in terms of low-level, like thinking about how to shift the mental model of an Ember user so that we can get away with less and less bookkeeping upfront. I still do too much bookkeeping as part of initial render but in order to keep reducing the amount of bookkeeping, we need people to get into mindset of things are fast initially and the tradeoff is that your updates are slower, unless you do whatever. There are mighty things like React does this wasted time debugging tool or they basically tell you, "Hey, you didn't tell us not to render this but it never render," so you should try and do that. To be honest, I think, having to write something once your component updates, that exactly, "Do I [inaudible] is not okay. I'm not willing to do that." But there are a lot of things that approximate that were more similar to Ember existing APIs that we can find. I guess, my medium-term goal here is to make it so that we have the sweet spot so that the initial render is always very efficient. I think, we're getting closer. There's still some back problems that we can deal with so. Initial render is very efficient, fast components are fast, and more or less, you get good updates performance until you reach a certain amount of scale and then the escape valves are much nicer [inaudible] before an update. They're basically little [inaudible] where you say, "You know this thing can't change." It would be hard for me to explain. It would feel like it's [inaudible] we talk about. We've had a bunch of discussion about different escape valves, and the thing I'm most interested in is finding once that feels semantic. Should there a component update doesn't feel like you're describing anything other than React's API. I'm more interested in things that feel like you're talking about your app or your data. ALEX: Yeah. ROBERT: Keeping with the Glimmer 2 topic. Glimmer 2 is written in TypeScript, right? YEHUDA: Yep. ROBERT: Do you see that creeping its way more into the Ember community? I guess, I kind of want to get your general thoughts on TypeScript and what your experience was writing in Glimmer 2. YEHUDA: I actually really like that. But the story with TypeScript was that I was writing the Glimmer 2 originally in regular JavaScript and I came back from a long trip. I want to show Godfrey what I've done and I was having trouble explaining some of the interfaces. I happen to know that TypeScript is a lot of it is just interface so I'll just use their syntax and I think, I open the playground and I type in some TypeScript interfaces. Then I was like, "Oh, it's annoying that if I reload, I'll lose it so let me copy the interface into the ReadMe, basically and to the app." Then over time, like not very much time, I was like, "Oh, it's very annoying that now that I have this, I really wish I could just use it inside of the code." So we started doing that. It took us maybe a week of actually being to be able to use TypeScript for real. But honestly, the code base is pretty big at that point, and the actual was not so bad. A lot of the reason why it was at the time, TypeScripts like VS Code, TypeScript was still younger and it wasn't a slam dunk. For example, in today's TypeScript, you can just have JavaScript files in your directory and just tell it to [inaudible] that works. At that time, you couldn't so you have to really change all the files and there are some things like TypeScript requires you to specify in classes. It requires you to specify all your fields and I think that's fine, that's good for TypeScript. But you're not going to have already done that in JavaScript so you can't just like rename all your JS files with TS and have a nice day. So it took as a little over a week, I think, and we also have to write the Broccoli TypeScript thing during that same period of time. That was another thing we have to do. ROBERT: Yeah, that's a [inaudible]. YEHUDA: Then, with TypeScript change the compiler API a few times so we have a bunch of [inaudible] to do. But other than that initial like [inaudible] to get it working, I would say that it was every single point in time, there was always a [inaudible] win, in terms of what we had to do to make TypeScript happy and what wounds that we got out of it. You get things like, obviously, people know about code completion. I personally like code completion. I think, it's helpful. But I think, jumps to definition is actually more important feature than code completion. Just like what is this method? I want to look at it. You can jump directly to it. Also, for me, the code completion of parameters is way important the code completion of method names so when someone teaches you about code completion, they will usually show you, "Oh, look [inaudible]." It gives you the list of all method names, and you're like, "Well, that's fine. But I probably know all of those method names." But you don't necessarily know all the parameters. Especially, once you start using types, the parameter or information is actually quite rich, like it's telling you this is a component definition, this is a string or this is whatever. All that stuff, I think, I basically come to realize from using TypeScript that Microsoft has done a really good job with [inaudible] code of distilling down to just what part of ID experience is really good and just bring you that to an editor, that feels a lot like Atom or Sublime, or other than that. So if you get like a pretty good ID experience, without all of [inaudible]. ALEX: I've seen some talk on GitHub about people who want to write their Ember add-ons on TypeScript and I did not know Glimmer 2 was written in TypeScript until just now. I'm glad that was brought up. But we as Ember developers have been trained to use convention over configuration. The convention is Ember is not written in TypeScript. We're starting to see convention now where logic has crept into the template, or it's not as much as convention as people are doing it right now. I'm curious what your thoughts on that and more is treating Handlebars as a programming language and something that we're seeing now in real production Ember code, so what is the path going forward there because it is happening? YEHUDA: Yeah, I agree. I just want to say, I didn't actually answer the previous question in full. I think my expectation is we have no interest in ever making TypeScript as rudimentary part of Ember. I think Ember should always work and work nicely with regular JavaScript. I don't want to do anything that would lean to heavily on people having TypeScript around. Certainly, I don't want to do with Angular did, which they use the types as semantic markers for dependency injection and something like that. But I do anticipate things like Ember-metal for sure, Ember runtime being written in TypeScript because anything that's pretty low-level and a lot of algorithms benefits a lot from clearly delineating interfaces. I think, another thing people don't realize is that there are all these [inaudible] interfaces floating around your code in JavaScript. But like you are in a class, it's pretty easy to document what the class does. But if you have an interface, it's not really any good mechanism for describing it and it can become very [inaudible] and it's Like, "Please give me an object as these methods on it and build these methods." It's funny because you don't realize until you start using TypeScript that it's a very recursive problem. It's like, it has these three methods on it have these six parameters and these parameters have these interfaces and those have these. So you can actually start describing a very complicated thing and it's like those complicated things didn't exist before, they were just very implicit. The explicitness of the interfaces is not you can write [inaudible]. You can write the three interfaces and have the methods with all types of networks [inaudible]. I think, I expect Ember-metal, Ember runtime, other low-level parts Ember, certainly the component library now it's like directly linking in with Glimmer and Glimmer were written in TypeScript so that stuff would really benefit with TypeScript. In terms of Ember itself, using TypeScript, I think we have sort of a medium term goal of letting Ember apps use TypeScript if they want. I would say that making that story really nice, pretty much leans on ES6 modules and ES6 classes so we have some of the ES6 modules but there's still a lot of Ember [inaudible] whenever module story. In terms of classes, were still using the old-style class system and that class system is actually just really hard to get the types working in TypeScript. It's hard, period. But like React has a similar problem and there's lot of advance features that only really exists in [inaudible] express ES5 class [inaudible] and TypeScript doesn't have all the features. My expectation is that sort of along the same path as getting ES6 classes. We will also get a lot of TypeScript support in Ember and I think a lot of people are interested. A lot of people have work on Glimmer now and they're like, "I would love to use it in my app so we'll probably have that happen." Coding your templates, was the other question. I sort of have a mixed feeling about this because on the one hand, I actually do want Glimmer to be the programming language in production way. So either templating engines are just using the programming language embedded like the ERP. Or they are like Mustache or like the general templating engine -- forget what that thing is called -- but there's a bunch of template engines that use like the curly syntax and those things aren't very rigorous in terms of how they think about scope. Like lexical scope, it turns out to be a pretty important thing about how programming language work. If you have a shitty scope story, people don't have a good sense of what's going on so like the Angular 1 templating story was you basically find your scope on wherever and you attach to a part of your template and that basically means that if you're looking at just temple, you have no idea what the actual variables mean, anyway, because any part of it could be choking up the scope to be whatever. I start with Handlebars but have refined a lot overtime and I'm pretty happy with it now. The Glimmer templating engine is basically defines a programming language. It has scoping story. If you want a variable, name it. Use the as-pipes syntax and you get some variables there. Your function, your output, your components, and your helpers are functions and sometimes it's written in JavaScript, just like in Ruby cellular functions that are written in C. But ultimately, just like a C extension, it can't magically change the scope of Ruby program, helper or component in Glimmer. It can't magically change the scope of your template. With all that needs, if you look at a Glimmer template, it's actually really clear what are the names mean. That sound boring but ultimately, that's one of the things that needs to you look up at a lot templating engine and not only really know what's going on. I don't understand what's going on, without thinking of what every single one of those custom helpers is doing. I think Jinja is the name of the templating engine in Django. If you look at some of the templating engine like that or even like Handlebars before Ember 2.0, you really have to go that like 'for x and y' is a magic syntax that needs a particular thing. Because a lot of these templating engines are very flexible in the sense that they let users have or whatever, any particular piece of syntax could actually be creating random names that mean whatever. I've just found, having worked through that in the Ember community, I'm very happy that we took the time to get that stuff solid. One of the nice side effects of that is that it makes some of the usual optimizations that people do on code work very nicely. Once we know all the names mean and know all the scopes mean, things like in lining specialization from invocation. This component is invoked here. It has these parameters, but those parameters are all strings and I can see the receiving end. The receiving end just fix those strings into attributes or something. At compilation time, like to combine all into one thing. This is an optimization that we haven't done yet because we been working on compatibility. But there's a lot of normal 'programming languages standard optimizations' that we can do because we design Glimmer to be a programming language. The fact that we've done that is actually mean the root cause of people doing more programming language stuff in their templates, in older versions of Ember before, we had done such a good job of rationalizing everything. You would start doing that stuff and you would start hitting clips where the behavior didn't work the way expected for some reason, then you just use a sub-expression as something and then depending on exactly which things you put into the slots, maybe it didn't update on the inside of the template. We always consider those things as bugs so we would fix the bugs that we encountered. There's an explosion of different kinds of things in a programming language and if you don't model variables as variables basically, then it's hard to know callbacks are callbacks, variables as variables. There's a lot of doubt so they would start using the APIs as part of them [inaudible] hit someone and they would pull back. But today, the implementation of Glimmer, especially with Glimmer 2 is extremely [inaudible] standard, and what that means is that you want to do very [inaudible], parenthesized expressions with as type something and then you want to go and take that and send to the component and you have that and you put that value and put it to a service and you do all that and it works. That doesn't necessarily mean that it's a good idea for your template to be in a large program. That's generally that. I think that's main question that you asked me and it is generally, for things to get really complicated. But I think there is a reason for it and I think it's something we're doing to make it better. I think, the reason for it is that, if you think about the Glimmer core language, the main escape of what you have to get complicated expressions out of Glimmer and back into a reasonable place is helpers. Let's say you have a big bunch of [inaudible], and/or whatever people are doing inside of their Glimmer templates and it's like a multi-line thing and you want to pull that out to a more reasonable place. The natural way to do that is to make a helper. But it's also pretty common that you have a complicated piece of expression that isn't reusable. It's not being reusable for multiple places and helpers in Ember right now are global so you may have this big block. Another [inaudible] of computer's property, but computer property's don't have a nice- like I have a few internal parameters and I just do something that they always require you do something against it, the components off of this, and that is usually what's you are doing. You're usually have what is effectively a function with a bunch of parameters in it and those parameters combine some way like with 'and', 'or', maybe there's some comparisons like 'greater' or 'less than' or whatever. One of the things that comes out of module modification RFC and makes everyone pretty excited is the ability to have helpers in your templates that are local so it's a helper that is just sitting right next to your template. I think, those kind of things -- helpers that are right next to your template -- will give people who like you do not want to see so much code in your template, a much nicer story to explain to people why we're doing it, and what we should do instead. A template has a three-line, fifteen is privacy expression and you want to convince the person not to do it. The re-factor is literally just to make a local helper, put the code in there and use the local helper. I think that's the better story to explain to people than, "Hey, I don't like that. It feels bad. What should I do?" CHRIS: This brings up an interesting point that we actually encountered recently at The Frontside, we use helpers a lot and are frequently trying to get them to do all sorts of weird things. But recently, it occurred to us that one kind of blocker was that you can't compose helpers. We had an existing helper and we kind of needed to make a helper on top of it and it suddenly dawned on all of us that, "Oh, we can't go up a level." We can't build a helper and its abstraction over another one because you kind of have to hit the dump. You have to have a component or a template or something to invoke that. Is that's true? YEHUDA: I would expect that you could call the function with the arguments that looked ugly but I would suspect and I would say that you can call it and just pass the parameters and hash these [inaudible] and -- ALEX: Like a helper that invoke or something? Because to write a new helper, you would have to go back to JavaScript. YEHUDA: That array an object. I expect that to work. Do you just need a helper calling another helper? ALEX: Well, a helper composing, like composing several helpers into a bigger helper and then just calling in the template, much like how you might write some functions and that write a function that closes over them or something. YEHUDA: Are we talking about a helper that takes the helper? ALEX: I guess it could be. I guess, higher order helpers could be a thing in this case. YEHUDA: Helpers that call helpers are helpers that close over helpers really should just- helpers are more or less functions. It would just be able to use them directly. I think, what you're saying is an interesting Ember phenomenon. I actually don't know which of two categories this discussion is in. Basically, either. Either there is some good reason why this turns out to be difficult and there's like a missing API that usually fix it. Like in general, my mental model here is you're talking about a function so if you can just [inaudible] the function, it really should work and in that, it is hard. There's something weird. Basically, what I'm saying is either there are some 'gotcha' that how it was structured right now, that's like an accident. That means they're not exactly as much like functions as we think or the mental model that you have using them doesn't make you think of them like functions. So you think that there are hard to compose but actually there are functions. Basically, those two things are equally likely Ember. I think that's unfortunate. ALEX: I think that with them, you can certainly combine them in a template and you could even pass one into the other. What we ran into an issue was, similar to functions, if you are writing like an npm library, you may write five functions and only export one of them. That one function will compose the other four and call them. In some cases, you may not realize, do you want to export that composed abstracted function until much later and it's okay, because you just import the function from somewhere else, then you say like, "All right. I'm just going to consume this function from another and now I have this combination put together." Well, with a helper, if you already have a helper that does something and then you realized, "Oh, actually, I need to build an abstraction on top of this helper in a new helper," we so far have not found a good way to combine them like that. YEHUDA: So probably, it will not succeed and having this conversation through to the completion year. I'll just say for listeners, what I find surprising about this, although, I can believe that there is something that makes it true is that helpers in Ember are really just functions and increasingly they really are like helpers in Glimmer are functions. They have a weird arguments signature. They take positional parenthesis in array and named arguments as dictionary and that's a convenience basically because otherwise, you have to scrape of the last parameter and try to figure stuff out. So that's a signature issue. But generally speaking, helpers are supposed to be functions and if there's something that you could do with regular functions you can't do them with helpers, that sounds to me like something is wrong. Like I said, I can definitely believe I should talk to Chris about this and he should write a blog post about it. I can definitely believe that there is something that makes it true but it's hard for me to imagine what it is. CHRIS: Well, I'm glad to talk to you about it offline. YEHUDA: Yes. We will figured it out. ALEX: Yehuda, thank you for this deep dive into open source process into Ember. I could drill deeper into your brain and just extract as much knowledge as I can. I hope to be able to do that someday soon. We're going to wrap up for today. Thank you very much for Yehuda Katz and your time. YEHUDA: Yeah. Thank you. I apologize for people who didn't understand half the things I said. ALEX: Yeah, it's a podcast for everybody. But we have a lot of Ember developer's listening and I'm sure that they loved it and hated it all up so thank you very much.

In this episode, Sarah Mei, founder of RailsBridge, Director of Ruby Central, and Chief Consultant of DevMynd Software, talks about the way we write software: What's right? What's wrong? How can we do better? The conversation examines changing code and reassessing needs. i.e.: "Does it bring me joy? Should I get rid of this thing? Do I understand this code?" She also talks about what these needs mean for others on a team. Sarah Mei: @sarahmei Links: Sarah Mei: How We Make Software: A New Theory of Teams @ Brighton Ruby 2016 The Life-Changing Magic of Tidying Up: The Japanese Art of Decluttering and Organizing by Marie Kondo Transcript: CHARLES: Welcome to the Frontside Podcast. I am Charles Lowell and with me is Robert DeLuca. We have a very special guest this week. One that I'm really excited about because the things she says and the ideas that she has - open eyes and minds all over the place, in all different types of areas that are so pertinent to the way we do our jobs. So, we'll get to it. Our guest today is Sarah Mei. SARAH: Hi. Thanks for having me. CHARLES: Like I said, we are super excited to have you here. Before we get started talking about some of the things that you've been thinking about recently, why don't you just give like a very brief introduction of how you got started with development, where you've been, and how has that brought you to where you're going right now? SARAH: You know, I actually was not one of these people that got started with it real early. I came to programming in college. I was an Engineering major. I wanted to build bridges. I wanted to be a Structural Engineer. I want to build things. I had a weird schedule the first couple of quarters of college, so I ended up taking an elective earlier than most people take it. It was a programming class in Fortran that was required for the structural engineering program. I took my class and I was like, "This is really cool." CHARLES: Wait, Fortran is what set the hook? SARAH: Yeah, and the professor of the class was like, "Well, if you think Fortran is cool. I've got some other stuff that you might like." I mean, the language and whatever doesn't really matter. What I liked about it was the fact that I could build something. I can get that same feeling of building something that you get if you build a bridge but you can do more than like one or two in your career, like you do if you're a structural engineer. I like the constant feeling of building. That's what I liked about it. So I ended up switching my major and graduating with the CS degree and coming out and doing a bunch of different things, mostly like starting in a large company and sort of doing smaller and smaller companies over time. CHARLES: Yeah, there's a lot of people in the industry who are career switchers, where they started out in something else and moved into Computer Science but I actually feel that a lot of people, like myself included, I have the degree in CS too, but that was not what I set out to do at all. It totally derailed, like the course of my life in a good way. But in that way, it's like a career switch within a career switch. ROBERT: I'm a little odd in that aspect. I came out of high school like ready to go in software. It worries me a little bit for the later half of my life. I'm like, "Oh, am I going to do software for the entire time?" CHARLES: Probably not. SARAH: That might be a good thing. You'll never know. ROBERT: Yeah. CHARLES: Yeah, seriously, what lies ahead? ROBERT: Who knows? SARAH: I feel like in a lot of places that are like, for example, in public policy and in other places where we need more people that understand tech so if we can send you out into other parts of the world knowing a whole lot about programming, that can only be good. CHARLES: Yeah. ROBERT: Yeah, this is actually kind of funny. I was telling CHARLES about this the other days, like I'm starting to view programming more as a tool to do the things that I really want to do and less as like the thing that I'm going to be doing forever. I wanted to augment and make things that I have a passion about easier. SARAH: Yeah, absolutely. CHARLES: Yeah, it's like software is eating the world so what you're doing now is just learning how to chew. ROBERT: That's a great way to put it. SARAH: You should tweet that. [Laughter] CHARLES: All right. Please continue. I'll ignore the typing sounds. SARAH: [Laughs] Switching careers is a really interesting thing because you end up with a bunch of experience that you wouldn't have had otherwise. I'm really excited actually about the next five years as we have all these folks that switched into programming from something else who are all becoming mid to senior level because they're bringing just such amazing experience from other parts of the world. CHARLES: Yeah, I know, right? It's like, "Where've you guys been my whole career?" SARAH: Right. CHARLES: It's like you understand these things, just almost like it's second nature of these things that are opaque and completely inaccessible to me. So anyhow... SARAH: That's how I got here. CHARLES: So then, after you kind of switched in college, you went out and did you just start working in programming immediately thereafter? SARAH: Yeah, I worked in a bunch of different product companies. I built products for a while. My first job actually out of college was at Microsoft up in Redmond and then I have worked at smaller and smaller and smaller companies. Then I spent about 10 years doing product stuff and then about 10 years ago, I switched into doing consulting mostly because I realized that I have a fairly short attention span for projects. And that working on a product, there wasn't anything wrong with me exactly but what would happen is when I was working with a product, I would get six months to a year into it and I'm starting to get antsy. I started to get bored and decided that I should just embrace that. And I switch to something where I am going to be on a new project every three to six months. I've been a lot happier since then. ROBERT: That's interesting. I wonder if that comes with seniority in software development and knowing your way around because consulting for me is I've gotten the experience of, "Oh, wow, I'm just finally getting a hang of this person's product or this client's product or app or whatever we're building," and it's, "All right. It's time to rotate off." It's like you just get in there and understanding everything. SARAH: There is that aspect of it for sure but even when I was much less experienced, even with my first couple of jobs, I noticed this tendency in myself to just get bored after six months on the same code base. For a long time, I thought it was because I'm not cut out for software or maybe I'm not very good at it or something. Eventually, I just realized now actually, it's just that I just need to switch projects. I'm just one of those people. That's how my brain works. I get a lot out of switching projects because the one that I switch on to, I see an entirely different way of doing things like code bases are so different. Even if you look at a hundred different Rails apps or a hundred different Ember apps, they're all so different. So switching on to somebody else's app, I learned a ton just out of that switching process. CHARLES: It sounds like the actual kind of studying the meta-level of the software is what really engages you and kind of understanding how the software came to be the way it is and not some other way. One of the factors that gave rise to that and kind of 'that's the problem' that really sunk its teeth in you, as opposed to individual business problem. Is that fair to say? SARAH: It has certainly been interesting to see different business problems and to understand different parts of industries and so on. That's definitely part of it for me but what really gets me interested is the different ways that people organize their code and by how they make the decisions that they make. ROBERT: Yeah, you get to see different problems that they've maybe put themselves into because of the way they structured something, which you wouldn't see if you wrote yourself but somebody else did and get to see, "Oh, I understand this pattern now." That's kind of been my experience out of it. I don't want to speak for you, but yeah, that's kind of how I've seen other client projects like, "Oh, this is really cool. I didn't think of a way to do this," and you get to experience many different things in many different ways. SARAH: You get to see a lot of the tradeoffs. Like a lot of times in a single code base, what would happen is I'd make a decision or we'd make a design decision of some kind. Then I'd see how it turned out. But there's no way for me to see how it would have turned out if I did it the other way. The nice thing about switching projects for me is just being able to see all of those tradeoffs, like the tradeoffs that you make tend to be pretty similar. You can see very similar situations where people do different things and how does it turn out for them. ROBERT: Right, and like one of my favorite things is where you go into a project that is totally against something, like for me it was object-oriented CSS and then you go in and you actually see it in practice, and you're like, "Oh, wow. This is turning a whole new light on it. I like this in this case." SARAH: Microservices are like that for me, where it's generally I am anti the microservice bandwagon. But then I went on one project where I was like, "Wow, they actually figured it out. This works really well. I can see why people like it," because I've seen so many work that was horribly executed. When you go on to the one where it's good and you're like, "Oh, this is why people do that. Okay." ROBERT: Yeah, it's like that light-bulb click, "Oh, yep. There's another side of this." CHARLES: Once you actually see it done right, it helps you avoid every other situation where it was done wrong and you can say, "Oh, this this was the one differentiator that made it all go right." I mean, sometimes it doesn't always boil down to that. But there's these one, two, three things that we could have done. But they were just completely and totally hidden from you because you didn't have that context. I would love to talk to you about microservices because I've certainly never seen it done right. I've heard it talked about and I've seen this beautiful world, picture-painted that looks so fantastic on the whiteboard. But I see -- SARAH: Oh, it's so beautiful, isn't it? It's like an object-oriented design diagram. I'm like, "Look at all the boxes and lines. They all line up." CHARLES: "They're beautiful." SARAH: "I can do this in Visio," and they're all like, the line, they are on the same shape. It was great. CHARLES: "And when I move this one over there, it just tells me that these two are exactly the same distance apart from that other one." Ah, so satisfying. SARAH: Yeah, and then you try and do it, is the problem. ROBERT: Then you build it and you cross your errors and everything. CHARLES: Which actually I think that brings us, recently -- we're talking on Twitter. I think that's actually very recently about kind of the difference between when we talk about software and the meta conversations we have around it. When we do talk about these abstract and perfect worlds of boxes and lines versus the actual code bases, which is the things that you've kind of been observing many, many, many since you've started consulting, and kind of the vibe between those and you know what that means. I think a lot of people aren't even aware like I certainly, before kind of reading that, wasn't really aware that that is a very, very distinct difference, like these are two very different modes for software. One that exists and one that is kind of perfect world. ROBERT: Kind of academia versus the real world, I guess. SARAH: In some ways, yeah. I remember when I was in college, we had a software design class as part of our degree program. We studied how you define objects and you write a little bit of [inaudible], like we did all this stuff. When I got out and I got into the real world and I had a job, I found it very difficult to actually apply that stuff successfully, to be able to draw a diagram and then turn it into code and have it work out the way that the diagram said it was supposed to work out. I initially thought that was because I was just not experienced enough to figure it out. But eventually, what I realized is that it doesn't work because it doesn't work. It really doesn't work to design things ahead of time and then just do them. I think there might be a certain type of person that can do that. I am not that type of person and most people aren't. I think that it takes a very unusual type of brain to be able to just draw a diagram that has already taken into account all of the things you're going to encounter once you start making it. CHARLES: Yeah, I would even go so far as to say there's probably a brain that solved that problem many, many times, that just could skip a bunch of steps. SARAH: Right, and they're not aware they're skipping them necessarily. Unless you have an entire team full of that type of brain, it's probably not a good idea in general, for the software that you're building as a group. I feel like I've been trying to talk about that concept between the difference of how we talked about software in books, in blogs, and in conference talks and then how we build the software we actually build. I feel like I've been trying to articulate that for 20 years, like since I have my [inaudible] and I was like, "This doesn't work. Why can't I make a diagram and then make it into code?" Like two days ago, I feel like I finally found a way to articulate it that captures everything that I've been trying to communicate and it was a really strange feeling. I'm like, "Wow, I finally kind of got it." One of the reasons that I came up with that, I think, is because I haven't really been thinking about it for a couple of months. I've been off and not really thinking about software stuff for a while. Oddly enough, I've been thinking about organizing my house for the last three months. All of my free time outside of my job has been thinking about like, "I've been learning how to cook, so how can I organize my kitchen so that the things I actually use every day, I don't have to dig through a drawer every single time to find them?" There's actually some interesting problems there like, "How do I make sure that all of the stuff that I need is at hand that I use all the time? All stuff that I need occasionally is still around and accessible, and then things that I don't use, I should probably just get rid of." I have this problem that I think probably a lot of people have which is that I have trouble getting rid of stuff once I have it. I live in a small apartment in San Francisco and that's not a good thing to be able to unable to get rid of things because in an apartment this size, I can let it go for a week or two maybe, but like I got to be very vigilant about it because otherwise, it just overwhelms the space. CHARLES: Yeah, there's a bunch of research that the people estimate vastly different the cost of acquisition versus the cost of loss, and they've [inaudible] way too much, like irrationally unbalanced like not wanting to lose something that they already have. SARAH: Even if I bought it for a need that I don't have any more or the need has changed or shifted. I don't buy things I don't need. There are some people that have that problem, that they buy a bunch of stuff that they don't have any particular plans for it. I don't have that problem, thankfully. I've had people in my family that have that problem which I think is why I have avoided that. But the problem I have is that once something is here, I find it very difficult to get rid of it. I look at it and I'm like, "I can think of all these reasons why I shouldn't get rid of it." Oh, that was expensive so the sunk cost fallacy of like, "Oh, I paid a lot of money for that even if it's not useful and I don't like it, I shouldn't get rid of it." Or, there'll be like a dress in my closet that I haven't worn for two years and I'm like, "Ah, maybe I should get rid of it," and I take it out and I'm like, "Oh, my God. But it looks really good on me. I like it. I should wear this. I should really wear this." So I'm going to keep it even though I haven't worn in for two years for some reason, but I should keep it anyway because it looks good. I have all these stories. I tell myself about why I can't get rid of things. A couple of weeks ago, I read a part of a book, to be totally honest with you, called The Life-Changing Magic of Tidying Up. It's written by this woman from Japan who's a professional organizer. Her name is Marie Kondo and her method is called KonMari. Basically, what it does is when you're trying to figure out whether you should get rid of something, you don't ask yourself, "Should I keep it?" What you ask yourself is, "Does this thing bring me joy? And if it brings me joy, then I keep it. If it doesn't, then I'm going to get rid of it." So that made it really easy, going back to the dress example. I'm like, "Does this dress give me joy?" And I thought about it, I was like, "No, the reason I don't wear it is because I went out to dinner and I had a bad experience at dinner so every time I look at that dress, it reminds me of that experience." And so it looks good and everything but I'm not going to wear it because it doesn't make me happy. So that was just like, "Okay, fine. I'm just going to give it away." And changing that question that I ask away from 'should I keep it' towards 'how does that make me feel' was a huge change for me because it's like, that's really easy to answer, where 'should I keep it' is a much harder question. There's these bunch of sort of ifs and maybes or what-ifs and what happens. I feel like that applying this KonMari question to stuff has changed the way that I calculate what stays and what goes in a very positive way. CHARLES: Yeah, boy, I need to get this book for several family members who will go [inaudible]. SARAH: Well, you know, I've got two kids and so there's a constant flow of stuff coming into the house. Because of the amount of space I have, there has to be a constant stuff going out. So this is something I just need to be very vigilant about and this has made it so that it takes up a lot less of my time and a lot less of my brain space, which is really awesome. It feels like it's moving my house in the right direction. I've been thinking about that sort of in various ways, on and off, for a couple of months and I haven't been thinking about software. I have this fear that like, maybe that means I'm never going to think about software again. I go through these phases where I've got like, "Oh, I'm going to come up with a bunch of new ideas," where I'm coming up with new ideas for some whatever reason. Maybe I'm making new conference talks, I'm doing stuff, and I'm thinking about software a lot. Then I go through these phases where I don't do that, like I sort of retrench and maybe... I don't know. I think about other stuff for a while. So it's been home organization for several months now. I was like this, "I'm never going to think about software again," because it's just that -- [Laughter] CHARLES: Career change. ROBERT: Oh, man. This sounds so much like my life since I moved down to Austin. SARAH: You know, I live in San Francisco and I'm not 25, I'm 40. A lot of it is like maybe I'm just too old for software now. I should just give up and live out the rest of my career doing quiet, maintenance work -- [Laughter] SARAH: Somewhere. I don't know. Then suddenly, this thing happened on Monday, where I was just like, "Oh, code, an organization." And boom! There it was. I realized, I was like, "I basically just had to give my brain some time off," like my conscious brain needs some time off from software and it wasn't that it had disappeared because what I came up with on Monday was really just how home organization applies to code because I realized that the feelings that I get when I'm trying to figure out what I should do with code are very similar to the feelings that I get what I'm trying to figure out whether I should get rid of a thing. I look at this piece of code and I'm like, "Should I change this? Should I get rid of this? Should I refactor it?" You know, why I can't get rid of that? We just spent two weeks refactoring it so I can't change it again. [Laughter] SARAH: We just put in a story for refactoring this and we spent three days and I can't go back to the [inaudible] people and tell them, "I need to change it more." Or, "I really like this code because I wrote it with someone that I really liked." CHARLES: So I don't want to get rid of it. SARAH: I don't want to get rid of it because then I would lose the memory of working with, you know. CHARLES: I actually can say that I have experienced that. SARAH: Yeah, there's a lot of reasons why you don't want to change code. What I was thinking about, like maybe I was asking the wrong question, in the same way that 'should I keep this' is the wrong question when you're talking about stuff. Maybe 'should I change this' is the wrong question when you're talking about code. Maybe it's sort of leading you in the same way with stuff that leads you down this conversation of reasons that don't really have anything to do with the essential quality of why the code is there or why the thing is there. We need something that helps us reassess our needs. So if our needs have changed, maybe you don't need that thing anymore because your needs have changed. Same way with code. If your needs have changed, maybe you don't need that code anymore, at least not in the form that it's at now. I think that question for code that, "Does it bring me joy," because joy is not something that I think is concrete enough when we're talking about code. I think the question for code is do I understand this? Do I understand what it's doing? Not just understand it like a very surface level of like, "Can I figure out what this syntax means?" But understand it more like the grok level of like, I understand this at a very deep level. I understand why it's here. I understand what problem it's solving. I understand why this abstraction is necessary. I understand how it got here. CHARLES: Yeah, how it fits into the bigger picture. SARAH: How it fits into the bigger picture, exactly, like the application. CHARLES: How it fits in with like our conventions that are just purely stylistic. SARAH: How does it fit in with the other stuff that we've been doing? How does it fit in with the product needs and the features we're trying to build and the business goals and all of that stuff, all of these different levels of understanding of why this code is here and what it does? CHARLES: Do other team members' understanding factor into that? Like, "Do I understand the way that other people understand it," so to speak? SARAH: I think that it can. But I think the important thing is whether you personally understand it. CHARLES: Okay, like it's a very personal decision. SARAH: I think it is. Hopefully, what you do is you want different people looking at the same code. You don't want just one person on a piece of code that no one else ever sees, whether it's pairing or code review or whether it's something else. It need to be really clear to someone is coming in and looking at that code what it does, what it means, and why it's there? CHARLES: Right. I guess the reason I asked the question is because a lot of times when I look at a piece of code, I try and really step outside of myself and say, "What will someone else think who has never been on this project before?" Or, "Who is on this project and they see this code, will they understand it?" SARAH: Absolutely. It's definitely a part of it when you're on a team. CHARLES: Yeah, so I'm just trying to figure out how that question factors into this framework. SARAH: I think that it depends a lot on how you distribute tasks. For example, if you work in a shop where you're pair programming most of the time, so there's always two people looking at a piece of code, 'do I understand this' is a reasonable question just for the two of you to consider, both from the fact that you can pool your knowledge but also from the fact that 'are there pieces of this that you understand that I don't understand' and vice versa. On the other hand, if you work in a shop where it's more like, "Here's the piece of code that you work on like you own this section of code." Then I think it's more important for you to be able to step outside and be like, "Okay, do I understand this? Would other people on my team understand this?" That can be a very difficult thing to assess and that's where I think it's very helpful to do things like code reviews, call people in and be like, "Hey, can I run some stuff by you. I'm trying to figure out if this is good or not," because what you want is you want a code base that is comfortable and understandable for you and for your team. Just like the thing that makes the KonMari Method powerful for stuff is that it doesn't tell you what you're going to end up with. It doesn't tell you what level of clutter versus cleanliness is good for you. It doesn't tell you. You either end up like something in one of these simple living magazines or end up something like Quarters, the TV show. There's a bunch of places in the middle, they're all fine. Everyone's going to fall somewhere differently along that line. So I've managed now that I've thought about this a lot to set up my kitchen in a way that is very comfortable for me, like I know where things are, I can find them really easily, things that I use are at hand. But other people come in, they're just like, "I have no idea where everything is," like it's very personal. The organizational system you end up with [inaudible] that you have is a very personal thing and that's why, if you look at something like staged houses, so you're selling your house, you hire someone to put in rugs and furniture and stuff and make it look like somebody lives there so that people can walk in and sort of imagine themselves in this space, they don't put any of that clutter into the stage. They don't put any books on the coffee table except the big picture books. They don't leave the remote controls on the couch. There's no plunger by the toilet. There's no like -- CHARLES: There's no Legos on the floor. ROBERT: Everything that looks good. SARAH: Everything that makes it more personal, they leave out because it looks like somebody else's mess. You go into something like that and you're like, "This is not my mess. This is somebody else's mess. It can't possibly be my house and I'm not going to buy it. ROBERT: Oh, do we do this for software in conference talks and posts? SARAH: Absolutely, we do. That's sounds very similar when you get someone new onto a project, especially if they're more senior and they'll walk in and be like this, I can't live like this. [Laughter] SARAH: This is somebody else's mess and clearly we need to make some changes. But that's the reason why they leave it out of the staged houses is because you want people to be able to imagine their own level of clutter and disorganization that superimposed on the skeleton. But real life is not that. Real life is somewhere between that and hoarders. There's a very interesting parallel there with code, which is like when we look at code, if we look at the object-oriented design textbooks, you look at conference talks, you look at blog post, sample code, it's all very staged house. It's very uncomplicated. It has no clutter in it and that's because you're supposed to be able to look at that. CHARLES: I mean, that clutter can distract the sales process so to speak. SARAH: Exactly, like they have an idea they're trying to get across and the clutter would distract people from the idea. But the problem there is the same with the staged house which it's very difficult to tell what it will be like once you move in. It's very difficult to take some of these ideas that you see demonstrated in these staged environments and take them and apply them to your code base which is probably closer to a hoarded house than to a staged house especially if it's a code base that existed for a while over time, that has been worked on by lots of different people. This is the problem that I've noticed with a lot like there's some really amazing books about software design that have come out in the last couple of years. Of course, Sandi Metz's book is at the top of my list. But the thing that people have trouble with, like they love the book. They love the book. I love the book. But then they find it very difficult to apply those principles when they sit down in front of a code base that has already been worked on for six or seven years, in some cases by maybe 50 different people, who knows, over time. How do you take those principles and start applying them in a way that moves you in the right direction? That's where people are just like, "I can't do this. I can't do this and I'm not going to do this." And it's very similar to a problem where you've got a very dirty house and you don't know where to start in order to move it towards something from the Simple Living magazines or are more like a staged house, you don't know how to start to get it in that direction and so you just kind of give up. The powerful thing about KonMari is that it doesn't give you like, "Here's what you're going to end up with it," but it gives you a way to get started on something that gives you a very easy question to answer. It moves you in the right direction. It moves your house in the right direction without being overly prescriptive about what you'll end up with. CHARLES: Yeah, what that direction even is. SARAH: What you'll end up with is personal for you, anyway. I think the question about 'do I understand this code' is similarly helpful and that it moves you and your code base in the right direction without necessarily giving you a lot of prescription about how you do it or where it goes or even where it's going to end up. It just gives you a question to ask that it tells you whether or not this code needs to change and a question is, "Do I understand it?" If I don't, it should probably change, and if I do, okay, we can just kind of leave it for now. CHARLES: So now, if you're working on a team where you have two different people, maybe different skill levels, maybe just a different temperament or different set of preferences, what do you do when the answer to that question is two different things for two different people? SARAH: Well, sort of like when you move in with someone. This is the hard part about living with somebody else, is that you have to mutually agree upon a method of keeping your house that is agreeable to both of you. Sometimes, when they say that working through a startup is like being married to someone, there's some elements of that because you basically have to figure out like, "Okay, we're going to live in this code together. If we're going to live in this code together, we better both be happy with it. How can we both be happy with it?" It involves usually, some compromise, like I really hate doing the dishes but I don't mind cooking and vice versa. You have to figure out. It really bothers me when there's socks on the floor but I don't care if you leave dirty dishes in the sink or whatever it is. You just have to have these conversations about, "What is going to make the code livable for you?" You basically want to end up with a code base that's understandable where all parts of it are understandable to everyone on the team. Now that's like an ideal. You're not going to get there. But that's kind of what you're going for. If you have two people in the code and you have disagreements about what is the right way to go, sometimes it can help to just be like, "Hey, I don't really understand this," versus, "I don't think this is the right decision and here's why I don't understand this." Sometimes, reframing the question in that way can prompt them to communicate reasons that they have for doing this that they maybe weren't able to articulate before, for example. Just like when you move in with someone, you need to have sort of this commitment to finding a level of housekeeping that you're both happy with. When you're working on the team, you do have to have sort of a mutual commitment to having a code base that everyone can live in. CHARLES: Right. I like that because having like, "I just don't understand this and here's the reason why," that being a completely totally valid answer because sometimes in a code base, where someone's brand new or maybe they're at a more junior level, they don't quite have the tools to understand it or there's a lot of steps that haven't yet taken. It's like understanding is not going to be accessible to them immediately. SARAH: And maybe that means that's the wrong decision for that code base, is that right? CHARLES: Right. SARAH: Because if something is abstracting to the point that a lot of people on the team don't get it, then it's probably not the right abstraction for that code base. That abstraction might be totally appropriate in a code base in which you've got folks that are more experienced who understand why it's there, who have the scars from previous times when they didn't do it, et cetera, et cetera, and they understand why it's there. There is sort of like intellectual understanding of like, "Yes, object-oriented design is a good thing," and then there's, I would call it almost emotional understanding of like, "Oh, yeah, there's this time that we didn't do that and that worked out badly for us." I think that folks that don't have the sort of experiential understanding, sometimes they just need to have that. They need to get that. Sometimes, what that means is you want to let them see what happens to a certain extent. Let them see what happens when you don't do that. CHARLES: Right. This reminds me actually, I've got three kids and the way our house is now versus the way it was seven years ago is wildly different -- the way that we live. You know, with our first child, I'm ashamed to admit it, like our strategy was just to kind of put safety locks all over everything: every cabinet, on the oven, not on the refrigerator, but just kind of 'childproof' the house so that we wouldn't have to change the way that we lived but it made the house really uncomfortable for our children. And kind of having observed that over the course of having the second and the third, there's not anything that we childproof really. We put the dangerous chemicals way up high, where only we can get them. It's a little bit more inconvenient if we need to access the bleach but that level of discomfort is something that we live with. We've always got cups that are set out on a cabinet that sits below the counter so we've got water cups set out so that the children can get water and stuff anytime that we want, and we try, for things that they're going to need, make sure that it's accessible if you happen to be four feet shorter. That's just a condition of who you are. So it means that the actual configuration of our house, even though it's the same house, is just radically different and it is more optimized or it's optimized as a compromise for the fact that there are people living in this house now that haven't learned how to operate everything but they just need to learn that the oven is hot and you don't go there rather than slapping a lock on it. SARAH: Your house is probably more comfortable for you as a group, right? CHARLES: Yes. SARAH: And what that means is that as the 'senior' in the house, it's slightly less comfortable for you in some ways but it's worth it. It's worth being less comfortable for you in order to increase comfort across the board for everyone in the household. CHARLES: Right, because it means that if the child needs water, I don't have to stop what I'm doing to get a cup out of the cabinet and fill it for them. SARAH: And they feel [inaudible] over the stuff in their house. They feel like they live there, like the house is for them. CHARLES: Yes. ROBERT: That builds comfort and confidence. SARAH: Yeah, I think that's a very good analogy. Anytime you have a group of people living together, everyone makes compromises in order for the house to be set up in the way that's optimized for the group. CHARLES: Yeah. "So man, how are we going to apply this to software? What's the next step? What are the concrete steps?" I guess it's just asking those questions, like asking, "Did I understand it?" SARAH: It is asking those questions and it's also, if you are one of the more experienced folks on the team, it's your job to elicit the answers to that from other people that are less experienced. They're not going to tell you. A lot of times, sometimes, they may or may not feel comfortable saying that they don't understand something. So it's your job to really try and figure out like, "Do they get this at a level that is acceptable? Do they understand why this abstraction is here at an intellectual level or at an experiential level, at an emotional level? Do they get it?" Which is not something you can really just ask. In many cases, it's your job to -- CHARLES: To just observe it. SARAH: To observe and to see how it works. If people are having a hard time understanding where things are in the code base, it could be because everything is so cluttered that you can't see anything or it could be that everything is so hidden that you can't see anything. It's sort of the staged house equivalent where everything is too abstracted, or is it the hoarded house equivalent where everything is just obscure and under piles of junk. Either way, no matter which direction you need to move towards the middle, the question is always, "Do I understand this?" ROBERT: I like this a lot. I keep on coming to the analogy of if you put a chef in a different kitchen where everything is just totally rearranged and they don't know where their knives are, where their measuring cups are and stuff, I think that plays perfectly in a software of like you put somebody into a code base that they don't know, "All right, I'll figure it out." It's not their home. It's not what they're comfortable with or used to. Yeah, I think this is making my brain work on how I can apply this. SARAH: Or if they're moving in like when you hire somebody and they 'move into your house', you need to be ready for things to change. And this is one of the reasons why I've been saying for many years in ways that I think maybe didn't quite connect as well as they could have, that really the team is the code and vice versa. Every time you add someone to the team or someone leaves the team, teams are not mutable. You get a completely new team. So, it's not like you can just sort of carry on like you did before. Every time you get someone new onto the team, everything gets reimagined, every breakdown of responsibility, every decision. You look at it in a new way when you have someone new come on to the team. If they're going to stay, like in your chef example, if this person is moving in and this is going to be their kitchen and they're sharing it with other people, then what you're going to end up with is probably something in between what it is when they get there and what they had before. They're going to bring in some ideas, you're going to keep some of your ideas and you're going to end up with something in the middle. The same thing has to happen with your code when you bring someone new onto the team. CHARLES: I really like the way that this just focuses the discussion and I know that you've talked about this a lot before, whether it's a kitchen or a house, this idea of the code not being so much the shrink-wrapped product. It's a structure, yes. It is definitely that but it's a structure that you, as people, inhabit. It protects you from certain things and it provides you certain things that you need to live. When people ask us why is a continuous delivery pipeline so important in automating all these things for deploying your software it's because the idea is this is going to be a living thing that your team will actually be living in. And every member of that team will be living in from the time they start with the company or start with the project until the time that they exit and the time that they leave. It's the actual living process that you want to make comfortable and pleasant. SARAH: And what comfortable and pleasant means will be different depending on who's on that team? It's not something that you can have like a -- CHARLES: It's not. SARAH: Right. This is why all of these things are like, "Here's how you design things." It always seemed to fall flat. I think it would be better titled like, "Here's how I did one thing once." [Laughter] SARAH: Or, "Here's what works for me." I feel like every conference talk that is about design could be, "Here's what works for me. I did this one thing once." CHARLES: You might want to try it. SARAH: You could try it. It might work for you, it might not, right? CHARLES: Right. SARAH: A lot of times where conference talks fall flat and blog post and everything else was why they're more like, "This is how you do it. This is the right way to do it." You're like, "Well, it certainly works for you." [Laughter] ROBERT: The one time I gave a conference talk, the night before I went through every slide and scrutinized it as much as I thought somebody out in the public would do it. And I think that might be where we go through in a 'stage our code'. It's like we're trying to make it perfect for somebody that might come through and scrutinize it or criticize. Because I know when I was going up to put those slides up, I wanted to make sure it was the best foot I could possibly put forward. CHARLES: Right, we don't want to be wrong but I think that's where it actually, thinking of it as 'this is what worked for me' and this is an example from my house that worked. This is a way that I organize my code and my space. That'll not take a lot of pressure off of not having like, "I am right and I'm an authority at saying that this is the right way." That's a lot of pressure. SARAH: I don't even like that. I try and frame a lot of the things that I talk about as like, "Here's the thing that works for me really well. Maybe it'll work for you too. Let me know." CHARLES: Yeah. ROBERT: Yeah, that's how I give it. CHARLES: Up until really about two years ago, I felt like that was the expectation that was put on people is to say the right thing. SARAH: That's true. And I think that there's a lot of teams where that is an unspoken requirement and that's something that we should examine. Because even within a team like 'here's a thing that works for me or here's a thing that worked on my last project' isn't very different from saying something like, "Well, industry best practice --" [Laughter] SARAH: And I think that like you get to a certain level of experience and people expect you to say things like that. In my experience, the best way to do it is 'blah'. I mean, it's not actually a super useful statement because your past experience may or may not be directly applicable to the thing you're looking at right now, no matter how experienced you are. I think that it's much more friendly to have a range of experience levels to say things like, "Well, this worked for me on this project. Let's talk about whether it could work here." CHARLES: Right, yeah. ROBERT: I really like that. CHARLES: I do. It's so hard because your human nature is to try and boil things down into a simple binary. SARAH: People would love to have a list of rules, I'll tell you that. This is a problem. This is one of the reasons why I think it's important for us to come up with these questions that you can ask that will move you in the right direction without giving you rules, that will move you in the direction of finding the rules that work for you. Because rules themselves, people really, really, really want them. But they're always misused. They're always misunderstood and what you really need are the questions that led you to those rules in the first place. That's what people really want, although maybe that's not what they are asked. ROBERT: Ah, the Steve Jobs approach. SARAH: [Inaudible] to start wearing black turtlenecks. I hate turtlenecks. ROBERT: And New Balance shoes and the jeans. [Laughter] SARAH: But yeah. I think it's one of those things where people are very hungry for guidance. But we've been giving them the wrong kind of guidance. We've been trying to give them rules. When what we really need to do is give them questions to help them develop their own judgment. ROBERT: Right. Like when I was coming up, I thought, in everything, there was a right way to do it and a wrong way to do it. I've been slowly, sadly figuring out that it's not all black and white and it's not all just logic. I've always treated programming as like, "Well, they wrote this and it's just logic so I should be able to understand this." It's been a long road to come to this conclusion that kind of like what you're talking about and this has been enlightening for me. Like you are going to solve your problems your own way, your own person, and you'll think about things differently. I really like the analogy of 'this is your house and this is how you work and live in your house'. SARAH: Right, and no one would tell you in order to be a proper human being, you have to set up your house this way. ROBERT: Exactly. SARAH: We feel comfortable telling people, in order to be a professional developer, you need to set up your code this way. I think that those are very similar statements and we should really examine a lot of these 'should' statements that are all over the place when you're talking about software. Think about whether or not they're actually serving us in our mission of doing more things with tech. Like overall, my mission here is for people to be more effective with code so that we can do more interesting things with it. I live in the TV show, Silicon Valley, essentially so I'm surrounded by these companies that are solving these little tiny problems and I'm tired of it. I want us to solve bigger ones. In order to do that, we need to get better at coding. We need to get better at managing code over time and that's what I'm trying to do. CHARLES: Because it's not going to scale, otherwise. We're out of time. We're going to have to have you on the podcast again because I don't think we've got to... what? About 15% of the things that we want to talk about? SARAH: Oh, we are overtime, aren't we? CHARLES: Yeah. But thank you so much, Sarah, for coming on and talking with everybody. You drop real quick your Twitter handle so that if people want to have follow on discussion, they can reach out to you that way, or your other preferred means of contact. SARAH: Yeah, Twitter is probably the best. My Twitter is @sarahmei, and that's mostly where I am. CHARLES: All right. Well, fantastic. As always, feel free to reach out to us too. I'm @cowboyd on Twitter. And what are you, Rob? ROBERT: @robdel12. CHARLES: All right. It's a wrap. Thank you so much, Sarah, and we'll see you in Ether and hopefully we'll have you on the podcast again sometime.

In this podcast episode, we speak to a strong and dedicated set of the ember.js community focused on making accessibility better for the web.  Making the web accessible is one of the biggest challenges for developers. Luckily, standards bodies have quickly moved to adapt and make necessary changes to improve the experience for us. We speak to Nathan Hammond @nathanhammond, Suz Hinton @noopkat, Jamie White @jgwhite, Ben Holmes @binhums, George Chapman @gnchampman, and Robert DeLuca @robdel12 on their passion and the driving force behind this effort. Topics covered: - What does accessibility look like in ember and single page applications in general? - Why open source community members are passionate about accessibility on the web.  - How the ember community has come together through making the web more accessible through creating useful ember add ons within the community  - What are the easy and difficult things about accessibility. - How html5 has enabled accessibility by default. - How many companies should start thinking about the power of being accessible by default.   - How large teams like Kickstarter start incorporating accessibility into their process, even during the design phase. - Building accessibility into your continuous integration flow  - What you should be investing in as a developer. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_. 

This week I spend some time talking with an old coworker of mine, Robert Deluca. Robert is a Ember/JavaScript enthusiast as well as an all around awesome guy. We chat about his relocation to Austin, TX and general work/life balance.

Chase and Jonathan are joined by Robert Deluca and talk about accessiblity, i18n, jsconf, and a whole lot more!