Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I am interviewing Rebecca Murphy. This is the second part of my interview with Rebecca. And if you missed the first part, make sure you go back and check it out. We talk about third party JavaScript in that part of the interview. In this part of the interview, we're going to talk about Scout File, which is a open source project that Rebecca has been working on with some of her colleagues at Bizarre Voice. We also talk about some hardware hacking stuff that Rebecca has been doing and we discuss Johnny Five and the joy of making something in the physical space. Make sure you check out both parts of the interview and also subscribe if you don't want to miss any future episodes of Developer Tea. Thanks so much for listening and here we go with the interview. Alright, so we've talked about evolution. Bizarre Voice and all of the awesome stuff that's going on there and all the challenges of third-party JavaScript, etc. But you guys are also doing work in open source. And you specifically have been leading the charge on Scout, right? Yeah, me and my colleague Lon Ingram worked on this repo, this project together. And really, Bizarre Voice has a pretty good history of supporting open source on the JavaScript and web dev side of things. The person who recruited me to Bizarre Voice was Alex Sexton. And a lot of the things that he has put out, he put out while he was working at Bizarre Voice. And so it's something that we try to do. We've gotten a little bit bad about releasing anything JavaScript-y, though. So I talked in the last bit about how I'm working on this team now that is working across applications and trying to solve things once. Rather than once. One time for every single application. And so one of the first things that we targeted was what we call the Scout file. That was something that we wanted to solve once and for all and make in a way that we could share across applications. And the whole point of a Scout file, Alex actually has a really great post about this, deploying JavaScript applications. And you should read it if this is interesting to you. The whole point... The whole point of a Scout file, and this gets a little bit in the weeds here, so bear with me. The point is that it is a file whose URL never changes that a customer or you can put on a page in order to load the resources to support an application. So its URL never changes. It has a very short TTL. So it's cached for a very short period of time. And it is necessary. It is necessarily very small. It should always be less than 14 and a half K minified and GZipped in order to fit in the first TCP window. So what this means, like once you have... You create this Scout file with a very short TTL. And in this Scout file, you put information about how to actually load the versioned resources of the application. So your Scout file is not versioned. It's always at the same URL. Like, you know... Customer name, locale, site name, and then Scout.js, let's say. So it never changes. Customers, when they make a change to their site, they don't have to change the URL of the Scout file. Scout file never changes. The Scout file has a short TTL. You can put configuration information in it. When there's new configuration information, you push a new Scout file. And because the TTL is short, the old one goes away. The new one takes effect. And then the Scout file loads the real application resources. So the real JavaScript, which might be tens of K rather than 14 K. The real CSS, which is also probably tens of K. It can't fit in 14 and a half K. And this is a strategy that is imperative for third-party JavaScript. Where we need to give customers a straightforward one-time integration that they can do. No matter what we change. You know, if we decide to start shipping our application in two JavaScript files instead of one. Or if we decide to embed our CSS in our JavaScript and we no longer need to download CSS. All of that has to be transparent to the customer. And so the Scout file is the thing that lets us bootstrap ourselves onto the page. What we've done, and why we're talking about this, is we open sourced an NPM module. That you can use to... To generate a Scout file for your application. It's pretty stupid simple right now. There's not a whole lot to it. Because there's not a whole lot to a Scout file. A Scout file needs to be able to have configuration in it. It needs to be able to load CSS. It needs to be able to load JavaScript. And that's like a minimal... A minimalist Scout file might just do those three things. Host configuration. Load CSS based on that configuration. Load JavaScript based on that configuration. It might not even do all three of those things. Maybe it just loads JavaScript and the JavaScript has the CSS embedded. Like, who knows? It's got great tests around it. So we can prove that it works. And that's a nice thing. To have all of that kind of boilerplate loading code tested. So you don't have to write it yourself and test it yourself. That's a cool thing. And like I said, this is something that even... It's imperative for third party apps. But even if you're just building a single page app. Remember that time that you had to tell your customer, like, oh, just clear your cache. That's not actually a legitimate answer to any question. That's bad. That's not good. Right? And so fundamentally, the Scout file means you don't have to clear your cache. Yeah. And so the net effect of this is that stuff, first of all, it loads asynchronously. So it's super fast. Right? So you're rendering the page really quickly without blocking by going into the cache. Right. And you're blocking by going and grabbing some huge script file because it loads in in the first TCP window. Right? Which I think I've talked about this on the show before. But if you're listening and you haven't heard the episode where we talked about that, I can't remember which one it was. But 14K is like the budget for that first load in. And so if you're... I think that's the budget. Is that still true? I think it's 14 and a half. Okay. Yeah. So which is not very big, by the way. For those of you who are putting images in that first load, it's probably... That one image is probably going over that 14K. So it's not an easy task necessarily. But with things like a Scout file or specifically with a Scout file, then you have this option of loading in things fast, which is the point of a script loader anyway. But this isn't just like a regular script loader. Because it allows you, as Rebecca was saying, the caching problem is the big problem that a lot of people face with asset loading in the first place. And if you have this first 14K, that basically isn't cached, essentially. Right? Right. It's cached for the second load, but it's not cached in terms of realistically the next time somebody comes to the site, like maybe the next day or whatever, because that TTL is so low, basically that means the browser doesn't hold onto that file. The browser isn't going to go to its local version. It's going to go and fetch that file again. So any updates that you've added to it, those are going to be live pretty quickly. And 10 minutes is what you're saying is the best setting, right? That's kind of the setting that we have settled in on. You could probably do... It depends on how fast you're going to load. It depends on how fast you want to be able to see changes. And I think effectively, because there's a CDN layer in here, what we actually see is that if we don't actively purge the CDN, purge the URL from the CDN, then the time ends up being two times the TTL because the browser will hold onto it plus the CDN will hold onto it. Ah, yeah. So even if the... And so I think it comes out to be like two times the TTL minus the... TTL minus one unit of time, whatever that... I think that minus one second-ish or so is probably about how that would work out. But anyway, we put our TTL at 10 minutes by just setting a max age cache control header on that resource. And we could play with that, but that number seems to work pretty well for us. And then we put our real resources, like the big payload at a URL... That has a version number in it. And so every time there's a new deployment, we bump that version number. And so that... And that busts the cache, essentially. Yeah, essentially. It doesn't even bust the cache. It's just like you're looking for a whole new resource now. It's not even a bust so much as it's like, this is a whole new resource compared to what you were asking for before. Before you were asking for version one, two, three slash main.js, and now you're asking for version one, two, four slash main.js. It's just a totally different path, totally different file. Yeah. And we put a TTL in those files of like a year because the browser can hold onto them effectively and definitely because we know that when we want to change them, we will do so by just putting a new version out in the world. Right. And then any old version of that is going to be stuck in the browser, but who cares? Because it's not being loaded. Yeah. Right. The browser has it in its cache until the browser decides to clean out its cache, but it's not going to use it. Right. It's not going to use it. It's not going to use it. It's like old versions of jQuery are probably somewhere in my browser. They're probably gone by now, but you never know. But yeah, so the scout file is just a thing that I'm glad is open source because I'm glad that it exists because I don't want to solve this problem again at Bizarre Voice. I'm glad it's open source because there's no secret sauce in this at all. Mm-hmm. Although the VP of our team is a little bit more experienced than I am. Yeah. I mean, I remember the VP of R&D was reviewing the blog post about open sourcing this right before it was about to be open sourced. And I had not done a sufficient job of explaining to him ahead of time that there was no secret sauce here. And so he freaked out a little bit, but I explained to him that this is a function for loading JavaScript. This has been written a million times before. Right. All we've done is packaged it up for this particular use case. That's funny. And you could say, I guess, like no JavaScript that we ever write can be secret sauce. That is also very, very true. JavaScript, client-side JavaScript is not, that's not where you want any secret sauce for sure. But this is definitely not secret sauce. So it's pretty exciting to be able to put it out in the world and be able to talk about it. And mostly to be able to have something that I can point to and say, this is what I mean. Yeah. You know, that's cool too, because in the past when I talk about it, like I could show them our actual scout file, but now I can show like this distilled version of like, this is what I mean. Right. Yeah. And it's, I mean, I'm sure a lot of people are going to get good use, especially out of just the concept, right? Like the magic here is in the concept that you're portraying. Not necessarily in the code. And so, although there's some good stuff here, right? Like you're doing a script loader without relying on jQuery, for example. Right. Right. I think a lot of people currently are relying on jQuery for loading scripts in asynchronously. Yeah. And you couldn't use jQuery if you want to meet that 14 and a half K budget. Right. Yeah. Because jQuery is what, 40 still? I think even if you just strip down to like just AJAX, minified and gzipped is still, in the 20s. Yeah. Even if you dispose of all the other functionality, you're still in the 20s. Is that true for 2.0 as well? You know, I think I was doing that on the one dot branch. And so I, I don't know. Well, you guys have to, for your scale, I'm sure that you are still having to go back to IE8. Yeah, we go back to IE8. I think we have some, I hope we aren't sporting IE7 anymore. But for a while, like for way too long. We were. Now we support IE8. I'm hoping that will stop soon, but not yet. So, but like we're working on a product right now where we aren't using jQuery, although that's rapidly becoming silly. Like we just wrote this whole complicated method for adding and removing styles from elements. And like once you deal with all the edge cases of that, Yeah. You just load jQuery at that point. Just like at least have a, have a conversation with yourself about whether you should. So, yeah, I think like that's a fine line where, where you say like, all right, we're just going to pull in jQuery. I don't think we're there yet. I think it's a really neat experiment to see how far can we get without jQuery. Especially if you allow yourself to have a degraded IE8 experience. Like, you know, you're not going to get those cool transitions. Right. So, they would have sucked anyway, honestly. Right. And so, yeah, it's interesting to see how far we get without jQuery on this project and when, when or whether we just bite the bullet and say, all right, we'll, we'll pay the jQuery tax. Yeah. I'm going to take a quick sponsor break and then we're going to talk about what is possibly the most different thing that we've ever talked about on the show. It's going to be a lot of fun. Yeah. It's going to be a lot of fun. It's going to be a lot of fun. Yeah. Yeah. OneMonth.com forward slash developer T. When I asked you to come on the show, you responded and said yes. And then we started talking about what we were going to talk about on the show. And you let me know that you're doing a fun project with JavaScript tracking of a chicken coop. Can you tell me more about what you're doing there? Yes. So I've always wanted chickens. And so we got some chickens a few weeks ago. And when you get chickens, you have to get a coop. So we also got a coop. And while the chickens were like growing up from baby chicks into grown-up chicks in our garage, I built the coop. And then just this weekend, actually, it was finally, thank God, time to move the chickens from the garage to the coop in the yard. What's wrong with chickens in your garage? Is there something wrong? They're like just smelly. And it's... It's just not fun. They're like... It's not fun to have them in an enclosed space like that. For them or for you. Right. Like no one's happy. And they were jumping up on the edge of the bog. Like I would come out in the garage and they would be like, hey, getting bored of this box. So I thought I'd jump up here instead. So, yeah. So we moved them outside this weekend. And one of the cool things about moving them outside is that rather than feeding and watering them out of these, like, tiny containers, containers, you can feed and water them out of these really big containers that, like, can feed them for days and water them for days. And, like, isn't this exciting? One of the bummers of moving them outside is that it's still, like, a little bit cool here. And so I'm a little bit worried that they might be cold, especially after being in the garage for so long and especially because they're young. And so I have a heat lamp. I have a heat lamp going on in there. And then once they start laying eggs, you're really supposed to, like, have light on longer than the sun is out. But, like, you don't want to run the light or the heat lamp when you don't need to because, like, you could end up cooking your chickens in your yard. And that would suck. Right. And also just the energy of that. Like, it's just dumb to have a light on in the middle of the day in the middle of the summer. And so. I have had for, like, coming up on two years now, a box of goodies for playing with Arduinos. And I actually have, I think, four or five Arduino boards plus a Raspberry Pi board. And so I have sensors for temperature and sensors for light. And I have distance sensors. I have a relay that can turn things on and off. Yeah. I have all these things. I've never had, like, a real project that I wanted to build. And now I did. And so there's this awesome library called Johnny Five. I don't know if you've heard of it. I actually was going to ask you. I thought I remembered you talking about this a while back. Yeah. Yeah. So, like, two years ago, I was messing around with Johnny Five a bunch and actually contributed some code to it. I contributed code for working with LCD displays. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm. It's a very jQuery-like syntax for getting a machine to do a thing. And so you can say, like, LED, turn on. LED, turn off. LCD, please display this word. And it just does it. Wow. And there's very little, like, there's comically little programming involved. It's really easy. But what's cool about it, because it's JavaScript, is you can really easily now hook this board up to a web server that you wrote in, I don't know, Express, let's say. And then you hook up Socket.io, and next thing you know, you have a real-time interface for seeing the data that's being collected by this board. You connect this board to a Raspberry Pi. So now you have, like, 50 whole dollars invested in the computer. You connect this Arduino to a Raspberry Pi, put it in a container, throw it in the chicken coop, and now it can connect wirelessly with your home network system. And so you can have, like, a home network way for monitoring and controlling the chicken coop. That's fantastic. Yeah. And my partner is like, you're just really lazy. Like, you just don't want to walk out there. It's like it's not even far. You just don't want to walk. And I'm like, yep, totally don't want to walk. That's exactly what it is. That is exactly what it is. That's funny. That reminds me of the quote that hackers are fundamentally, we rely on being lazy to do our job well. Yes. Yeah. That is intrinsic in our character. No, it's fun. I really just started on it. I started thinking about it Saturday and bought some stuff and just build out, like, the desk prototype. Turns out it's really easy to build this stuff on your desk. And the much harder part is figuring out, like, how am I going to build this in the physical world? Like, on my desk, I can have these six sensors all sitting right next to each other. But in the real world, there's going to be, like, six feet between these sensors. And so now I have to run wire and now I have to protect this stuff outside. That's the thing that I really like about. The intersection of JavaScript and hardware is that because I can write it in JavaScript, the, like, making it work is really easy. But the making it is actually hard. So it's not about the code anymore. It's about whatever it is that you're accomplishing with the code and all the, like, real life constraints around it. Yeah. Like, the real world physical constraints. Yeah. Because, like, I can whip up an Express server right now that has a button that will get a message to the Arduino on my desk to turn an LED on. Like, that's not, that is not even remotely difficult with Johnny Five. Which is awesome. Which is amazing, right? Yeah. And they're, like, people are building robots with this stuff and, like, you know, controlling them from their iPhones because it's just JavaScript. It's so easy. So, yeah. Like, making the interface. That lets me turn a light on and off from my computer in the comfort of my home. That's easy. Mm-hmm. Wiring that light to, like, work in the physical world. When it's raining. When it's raining and, like. Chickens might chew on it. Do they chew? I don't know. I don't know. I mean, like I said, not a chicken expert. Right. So I'm not really sure what I'm in for here. But anyway, yeah, that's my current project. And I'm developing. I'm doing this on GitHub. So one of the big backers of Johnny Five is Boku. It's a pretty awesome open web consulting company up in Boston that I worked with for a while, a couple years ago. And their mascot is a chicken. And so I emailed the founder of Boku yesterday. Natural fit. Yeah. And I said, like. I'm going to make this thing. And I'd really like to call it Boku. Would that be okay with you? And he was like, that's amazing. So it's on GitHub. Under my GitHub. Boku. There's not much to see yet. But if you want to follow along. That's awesome. That's happening. Yeah. Yeah. I actually recently put together not nearly as cool. Nothing to do with chickens. But. But a Raspberry Pi project at my house. It just. All it does is pull Spotify music down and play it. But what I was. What was so fun for me was that I actually like. I made things work that normally don't work together. You know, like I got Pythonista on my phone. And wrote like enough Python to send a get request or post request. Which, by the way, there's like no app that just does post requests. From your phone. It's really frustrating. But anyway. And I put this thing together and it was so like satisfying. Even though I could already stream Spotify through my Apple TV. I've actually talked about this on the show a few times. So sorry if you're hearing this and you're like, we get it. We know that you have. I have heard it. Yeah. But it was just so satisfying, you know, because you're making something that previously just didn't. It didn't exist. Yeah. In your like physical space. And it actually is useful, you know? Yeah. And that's, you know, when I was first starting to work with with Arduino stuff and the Johnny Five stuff like that, that was what Rick Waldron is when he created Johnny Five. And that's what he kept saying. And like what I kept saying after I experienced it, like when you do something as simple as like making a light turn on in the real world, like that's with code. It's crazy. And the things that you start to understand the way that you like. Suddenly start to look at that, like the light switch or the keypad on the printer or like all of the or the LCD on the printer that says like out of paper, like all of these things suddenly you just magical. Well, they become less like they become more and less magical. Right. Right. Right. Yeah. They're less magical because like now you've kind of seen behind the curtain. Yeah. Oh, that's how those buttons actually. Do what they do. Right. Do what they do. And then you also come to appreciate that someone had to write the code to actually process the input from those buttons. And they weren't doing it on a MacBook Retina with 16 gigs of RAM. They're doing it on some tiny chip that fits on the tip of your finger. And then deploying it in production. Yeah. And it's just like, oh, it's it's crazy. It's really it's a neat thing to to experience. You know, what's really interesting. By the time this episode airs, I will have released an episode about the importance of play and how play actually helps us learn. And we talk about, you know, how children they they learn by playing and and children learn so much more efficiently than adults do. And so often we forget the importance of it as adults. We forget like you can still learn by just having fun with something, you know. And I think this is a great way, especially. For developers who already are like familiar with JavaScript, but you've lost some of like, I don't know, some of the love for it. Right. Because, I mean, I've been there. Right. And I think all of us probably have where you're writing code. It's like, man, honestly, I used to love writing code. But today I don't because I'm writing something that honestly, I just don't feel like writing. Yeah. Yeah. No, this is the doing hardware stuff is is really it's fun. It's a lot of fun. It is. It is. Just. Discovery through play. And you will learn things. You will learn things that at the time when you learn them, you'll be like, this will never be relevant. Pretty cool. But it'll never actually be relevant to my job. And then it will be relevant to your job or to your next job. Like that's the other neat thing is you learn you learn stuff. You don't see how it's applicable. It will be applicable later. Just. I can prove that right now. Actually, you wrote a post about bit shifting. I believe that was that was when you first started. I was when I first started working with Johnny Five stuff. And you wrote about bit shifting to turn on LEDs in a sequence or something like that. And I was like, this is interesting. And also, I've never seen it. And it's like frustrating that I have no idea what's going on. And so I consumed it as much as I could. And I learned about, you know, the way that we the way our number system is built and all these things. I wrote a post about it for Tuts Plus Network. And then I came across bit shifting enrollment. And I was like, wait, what are you guys doing here? And it was a Ryan Bates, like, Ruby method that used bit shifting. And I was like, there it is. There it is. I never knew this existed in my world. You know, I thought it was just for Johnny Five stuff. And it wasn't. It was right there. Yeah, it's neat. That was a fun post, too. That is a post where I genuinely, wow, like, I didn't know any of the content in that post, probably a month before I wrote that. post. Wow. Like I just didn't know any of it. And once I did know it, I wanted to write it down. So I would always have it to go back to. Yeah. Well, and, and, uh, I can say that it was valuable for at least one other person who read it. So, all right, Rebecca, thank you so much. Is there any, so I like to do this with guests as well. Um, if you had just 30 seconds, uh, to talk to a beginner, beginner developer or an experienced developer and tell them, uh, just give them some advice about becoming a better developer, both in just as a person, but also in their career, what would that 30 seconds look like? Uh, I mean, I always try and think about what do I wish I knew a year ago or when I started my career doing this thing that I do. And I mean, there's two things. One, it takes time. And sometimes there's just no substitute for time and experience. And you have to make mistakes and things have to be hard. And you just like, that's, that's just part of this thing that we do. And that never goes away. Um, it, certain things get easier, but new problems that you never even conceived of become your new problem. That's now hard and that's, what's fun. And that's, what's terrifying. Um, but it's definitely what is constant about working in this industry. Um, I think the, the other thing that I would say, and this is advice that I would really like to give to myself five years ago, six years ago is if you think, you know, most of what there is to know, you don't begin to know anything like measure yourself by how much you think you don't know. Um, like the more I learn, the longer I do this, the more I have to kind of make peace with the fact that there's this universe of stuff that I don't know. And the more that like, the more I realized that what I do know is just this tiny, tiny slice of the universe, but I know it well, it turns out I can make a good living knowing it. Like what I don't know is vast. And if I stop thinking of, I think like, yeah, I pretty much got this whole software thing. Figured out like I am a bad person and be far, far away from me. Oh yeah. That's great. And no shortcuts basically is what you're saying. Basically. Yeah. And that's good. It's good. It's good that there's no shortcuts. You know why? Because I think that it makes, it makes what we do very valuable. It makes what we do, uh, as developers, when you struggle with something, uh, that means for somebody else to replicate it, for somebody else to create whatever it is that you created, they have to, also struggle. And there's something good and human about that, I think. Yeah. And I think that like the flip side of that or the, the compliment to that maybe is that, um, as experienced developers, you have to have great respect and great patience and great understanding of people who have not, like people can't just be at your level tomorrow. They can't be there because they want to be, um, like tomorrow they can be there eventually because they want to be. But they can't be there tomorrow. Like some stuff really does just take experience and you made those same mistakes that you're watching them make and, and thinking like, oh my God, like how could he screw that up? Well, he screwed that up because he's new at this and he hasn't screwed it up before. And you have, and the only reason that you know not to is because you did. Yeah. Wow. Yeah. That's, that's great advice for me and for anybody else who is, who's in charge of a team of developers. But really it's great advice for anybody who's in charge of anybody. Anybody in charge of anybody. Pretty much. Yeah. Well, that's awesome. Thank you so much for being on the show, Rebecca. Jonathan, it's been great. Thank you. Thank you so much for listening to Developer Tea today. I really enjoyed interviewing Rebecca. If you have any suggestions for the show, perhaps you have an idea of someone you would like to hear interviewed, for example, you can get at me on Twitter at at Developer Tea, or you can email me at developertea at gmail.com. If you'd like to support the show, check out developertea.com front slash donate. I recently added one-time donations and any kind of donation is a big help to the show. Of course, if you haven't left a review in iTunes, that is also a big way that you can help other developers just like you find Developer Tea. Don't forget that show notes for this episode and past episodes can be found on developertea.com. Thanks so much for listening. And until next time, enjoy your tea.