Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I have the pleasure of interviewing Rebecca Murphy. Rebecca has been doing JavaScript for many, many years now. I heard about her on the YayQuery podcast a few years ago. I'm sure you might have heard about that as well. If not, you should go back and listen to every episode of YayQuery. It was a lot of fun to listen to and it was very insightful. Of course, some of the news things are no longer news, but you can still learn quite a bit from that podcast. Rebecca is part of that learning process, so go check out YayQuery if you have not yet before. Rebecca shares a lot of her insights on doing third-party JavaScript in this interview. Now, if you don't know what third-party JavaScript is, stay tuned. Rebecca will help you understand it. But basically... It's about JavaScript that you write to be embedded on another person's page. And that JavaScript can manipulate the stuff on that person's page. There are a lot of complicated things that go along with doing something like this. So Rebecca has definitely seen quite a few weird, strange things happening in JavaScript. So I'm really excited to talk to her. Thank you so much for listening to the show, by the way. You are the reason why this show is created. If you have not subscribed yet, while you're listening to this episode, why not take just a few minutes and in whatever application you are listening to this episode in, go and click the subscribe button, whether that's on your iPhone or on your computer, or even the RSS feed, which is actually available on developertea.com. Go check it out. Thanks so much for listening, and here we go with the interview. Welcome to the show, Rebecca. Hey, thank you. I'm really excited. I'm really excited to talk to you. I've followed what you've done in the past for years and years, of course, with Yequery back in the day. That was how I first was introduced to the work that you do. You were the first person actually on Yequery to suggest not using jQuery, I think, which was the moment where I was like, okay, I probably should listen to this person because she's kind of breaking out of the norm or whatever. I think you talked about Dojo quite a bit back then, right? Yeah. Yeah. Yeah. Those were the days. I actually just found a picture and tweeted a picture of the Yequery days. Yeah. Thankfully, I was not in the picture, but it was a pretty entertaining picture of Alex and Paul and Adam five years ago. Oh, wow. It's been a while. Yeah. Isn't that wild? It's amazing how long. It seems like all of the knowledge that we gained five years ago was just a few weeks ago. I know. A lot of it is still so relevant, you know? Yeah. Oh, my gosh. Yes. I can't believe that it's been that long. And just also people who I'm realizing, you're my friend now and I met you five years ago. Yeah. And what a different world it was. And companies that existed then don't even exist anymore. Yeah. A lot changes, it turns out. Sure. And speaking of companies, you work for Bizarre Voice, which I'm sure I have mentioned in the intro, which I haven't recorded yet. But tell me about what Bizarre Voice does as a company. And then we'll talk about what you do at Bizarre Voice. Yeah, sure. So Bizarre Voice is, gosh, I think almost 10 years old now. And we do social commerce content. That's kind of the air quotes term for it. But if you know us at all, you know us best for doing ratings and review software. Mm-hmm. So you go on. You go on the website of pretty much any major retailer in the U.S. other than Amazon. And you see reviews. Then there's a really good chance that those reviews were put there by Bizarre Voice. And so we create white label software for collecting and displaying ratings and reviews for brands and retailers, including some really big, big, big companies that you have definitely heard of, which is pretty cool. It's this very large. Like, we're dealing with really big data and big problems. And no one has ever heard of us because so much of our stuff is white label. Yeah. Yeah. And what's interesting about it is the importance of those reviews can't be understated. Yeah. I mean, this is the first, not to knock any of the products that I've worked on before, but this is the first product that I've worked on where it's like, I use this every time I go shopping. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Like whether we buy them on the internet or whether we buy them in a store, like you probably read some reviews before you did. And so it's kind of a big deal. It's pretty cool. Yeah. And reviews in general. I mean, I ask people to review the show all the time. This isn't a plug for that, but it's so important because social proof is so important. Like what people think about something, what one of the listeners thinks about this show is going to be infinitely more valuable than what I tell you about this show. Yeah. Yeah. And I mean, gosh, I can, I'm not even trying to like do the marketing spiel here because we have marketing people to do that for us. But yeah, I mean, the amount of insight that you can get from reviews, positive or negative, is just, it's really pretty incredible what reviews do for companies. So it's a fun product to work on. And it's fun to work on something. And it's something that I do actually use in reality. And not only me, but like. All of your friends. And not only my tech friends, but like literally. Every friend. Everyone I know. Right. Yeah. Uses reviews when they shop. So that's a, you know, in some ways, like it's even cooler than Twitter because like, you know, Twitter has some in crowd, but this is like literally everyone just uses this. So how many people would you say on an average? Day load the JavaScript that you have written at or have touched at least have been in charge of. I'm doing some rough math, like millions. Yeah. Up there. Right. It doesn't really matter at that point. It's a lot. It's like seven figures, but maybe eight, maybe like, I don't know. It's it's millions of people. So that's that's pretty cool. How often are you delivering new versions? Of stuff. And we'll get, we'll get more into the details on that with scout file. The new open source thing that you guys have done, but I don't want to get there yet. How, how often would you say that you are delivering new versions of script of JavaScript files and stuff? On bad days, more than once a day. On, on good days, you know, a couple times a week. We're putting new code out in the world, either to fix a bug or to get a feature out or just to make things work. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. we've definitely in the time that I've been at Bizarre Voice, we've moved to, I've been here two years, um, a little over two years. We've moved to doing much more frequent releases, um, with much more, um, like we, we really improved our QA game and improved our automation game a lot so that we can release stuff with confidence and not have an onerous, like, you know, get a cut, a release branch, and then spend two weeks testing it kind of thing. Like we're, we're able to cut a branch and get it out in the world pretty quickly. Yeah. So, so that means I, this comes as a, as a given as a default, I guess, but you guys are using some sort of testing on your front end JavaScript then? Yeah, we've really, it's an interesting problem. So the app that I worked on recently, I've actually transitioned a little bit and we can talk about that in a minute, but the app that I worked on until recently is a third party JavaScript application. And so that means that Bizarre Voice customers put a script tag and a tiny bit of additional, um, implementation JavaScript into their product page. And from that script tag and this implementation code that says, please show the reviews for product one, two, three, we in the browser generate a complete, um, you know, rich experience. And all of that happens in the browser. And of course we're all familiar with this, this concept right of single page applications executing in the browser where most of the code executes in the browser and the HTML is generated in the browser and blah, blah, blah. Um, what's different about a third party app is you do not own the execution environment. Um, you know, the nature of JavaScript is that very little is private. And in order to communicate, you often have to have some real estate on window. Um, but you have to make sure you don't have too much real estate on window and that you don't expose anything so that, um, your customers can't inadvertently mess with you. And so the QA problem is a really interesting one in third party JavaScript land, because I like to say like it works on my machine. It has never rung quite so hollow as it does in, in third party land because like we can create test pages and, um, you know, demonstrate that the application works fine on those test pages. But then in the real world, when we end up on a page where a client has a version of prototype from 2007, um, Oh man. And maybe they also have a version of prototype from 2009 and they also have a version of J query or maybe two. And, and so, you know, that makes the, that makes the, um, automated testing a really interesting problem, let's say. So we've, we've invested a lot in unit tests of, of our code to make sure that it's doing what we expect it to do at the unit test level. And then actually a lot of our functional testing is still, um, manual and it involves simulating, loading the application into a real customer's page. Sure. And we, we have like, you know, a set of real customers that, that we'll use for a given release. And, and we use Charles proxy to pretend like we're loading this new code into the page and see what happens. Um, and so a lot of that kind of functional testing, like, will it work in the world? Testing is still done manually, but we have a great QA team that has really formalized so much of that process that even though there are humans doing it, there's so much less room for error and they're able to execute it really quickly. And we're, we know, like these are the 20 things that we need to test for a patch release. And these are the 50 things that we need to test for a minor release and, you know, that, that kind of thing. Yeah. Wow. So man, there's so much to talk about there because I just, when you, when you think about third party JavaScript, for those of you who are listening and don't know exactly what that looks like, think like maybe you have a site that has, uh, I don't know how to pronounce it, but I always say discuss, uh, some people call it discus, um, a site where you have a, uh, a script that loads in and then changes the HTML on that page. Sometimes it'll load in an iframe. Sometimes it won't. Sometimes it'll actually build that HTML. I'm guessing yours actually changes the HTML on, on their domain, like not in an iframe, correct? Yeah, we do not, uh, rendered an iframe, which is a, it's one of those decisions that you look back on every now and then and say like, Hmm, I'm not sure that was the right, the choice, but, um, the iframe is really limiting as far as some of the layout constraints that you have. So yeah, we don't load an iframe. We load in the customer's page. And so, you know, just like following up with what you were just saying, when you load in the customer's page, their CSS can affect you. And so now you have to clean slate is what we call it. Um, clean slate, uh, the customers like make it so that the customer's CSS cannot possibly affect your container, which it turns out, it takes a lot, it's a lot of CSS rules in order to state that. And so, yeah, you really have to be, you know, you don't, you don't generally have customers willfully messing with you, but they don't have to be trying in order to mess with you. Like it's so easy for them to do something that has, uh, that can have a bad effect on us. We had a customer who was redefining, um, the index of method, uh, and they redefined it in a way that they, they forgot to return negative one when the item wasn't found. Uh, this broke J query, which broke us. Sure. And I'm surprised it didn't break them honestly. Right. And it's a fine line to figure out like how much of that do you test for and protect yourself against actively? Because if we protected ourself against everything that a customer could possibly do to us, it'd be impossible. Our file size would be massive and it would be impossible. Right. Um, cause there's infinite possibilities, right? Like they could be listening for you changing and, and I don't know, inserting something at the bottom of the, of the page and again, redefining things that you redefined to get like trying to, it's always just a fight between the two at that point. And so, yeah, it'd be impossible to test every possible scenario. Uh, I would imagine, but we do test some scenarios. Like we look at window dot Jason and see if it behaves well. And we actually had a bug where we tested window dot Jason. It behaved as we expected to. So we were like, cool, we'll just use window dot Jason later. Yeah. Um, when we need it. Well later when we went to use it in the time, since we had checked to see if it was good, they had broken it. The customer had broken it. Like some, some script they loaded after our check broke window dot Jason. So now we have to not only check that window dot Jason is good, but actually capture it. Um, so that even if they mess with it, our captured version is still good. Right. So, yeah, there's a lot of, it's, it's, it's a whole other, just whole new world of JavaScript development. Like it's, it's, it's really a leveling up after you've kind of mastered single page apps and client side web dev thinking in this really defensive way where you do not, you know, it's not just that you don't control the browser, but you like, you control nothing. Um, it's, it's a really neat and different challenge from traditional JavaScript development. I would imagine going back with, it probably makes you feel like a, like even more of a rock star when you're like, I can do anything. Oh yeah. I mean, when I work on a side project or when I work on some internal tool, that kind of thing, I, yeah, it's such a delight because it's like, I don't need to worry about anything. Yeah. Nobody's going to mess me up. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Nobody. Yeah. That's, that's a fun treat to get every now and then. Yeah. So you said you moved into something different though. You're not specifically working on the third party stuff as much anymore. Actually, I'm still working on third party stuff because that's continues to be how bizarre ways, like that's how we get our content into our customers pages. Um, it turns out that getting customers to do server side integration, sometimes it's possible. Um, but often they have to, you know, pull in a contractor and they don't like they have shut down their web dev team. Cause these are retailers. Like primary business isn't making websites. Their primary business is like selling shoes. Yeah. It'd be waste for them to keep them on all the time. Yeah. Right. And so often getting a server side integration, um, implemented or changed, it's really hard. It's more costly. Client side integration. Often they can do that through their CMS or it's, it's just otherwise less scary to them. Sure. And so third party JavaScript will continue to be how bizarre waste gets on the page in most cases. But what I've moved on to doing now is actually looking at our application development efforts across products. So we actually have several different products, um, that, that put content on customer pages. Um, and I can't talk about all of them cause not all of them exist right now, but, um, you know, so we have, we have several different products and we've kind of realized like we don't need to figure certain things out over and over and over again. That clean slate thing, for example, we should figure that out one time. We should make a grunt task and we should make that grunt task shareable by everyone, by all the different front end products that bizarre voice. And so I'm working on a team now that's, uh, I'm leading a team, um, now that's more focused on that, on figuring out what we need to change. And, and what we can standardize across consumer facing web apps, uh, bizarre voice versus just focusing on one of those applications at a time. Yeah. Yeah. That makes sense. Uh, so you mentioned grunt. I'm assuming that you guys are, are also at least moving towards putting as much of your process into an automated thing like grant. Well, I guess you are using grunt, but, uh, are you testing through grunt as well? Um, yeah, excuse me, terrible allergies. Um, yeah. So we're using grant for all of our task automation, although this is a whole other topic that we could get into reason for all of our task automation and for development, you know, development workflow, that kind of stuff. Um, and so therefore, yeah, for, for executing tests just really is like the wrapper around whatever the test runner is usually at Mocha. Um, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, but that was my next question is what framework are you guys using? And none of these, like, I'm going to name all sorts of things. Um, none of them are like, you should totally use this too. Oh yeah. Um, you know, we have some projects where we just do plain old, um, plain old, uh, assertion. No, yeah. No, do you know? That's what I was trying to remember. I'm like plain old node unit tests. Um, and then we have, we have projects that use Mocha and then we have projects that like use Mocha, but wish they didn't. and so mostly Mocha, not entirely Mocha, some node units, like it's kind of all over the mountain. We kind of leave that as a detail to the, for now we're leaving that as a detail to the project when they set up. Cause I, I can't get to micromanaging. Right. And it doesn't matter, right? As long as you're, as long as your tests are testing what they need to test. And as long as, as you know, you're able to run them in a relatively quick amount of time, then who cares? Exactly. And so can you run them in Jenkins or in, uh, Travis or whatever? Like, yes, cool. That's really all I care about. Do they like return a good exit code? Right. Uh, but, um, you know, an interesting thing that we've run into. So we, we, um, when you ask about using grant, um, we, every time that one of our customers, changes some configuration option about their readings and reviews display, we actually generate a whole new build for them. Um, every customer gets their own CSS, JavaScript templates, um, strings, all of it. They, they're, those are unique to a customer so that a customer only gets the resources they need. Sure. We don't want to ship resources that, you know, they don't need because they don't have a particular feature turned on. Um, so every time that a customer makes a change and asks for a new deployment, we generate those new files and we generate one set of files for each locale. Um, and we can support up to 130 locales, I think like some crazy number. That's a lot. Yeah. And so you can imagine the customer makes a change, asks for a new deployment. We have to generate 130 versions of CSS and JavaScript. Wow. And, um, we have a lot of customers and each of those customers had not, not each of them, but a lot of them have more than one site. And so they might actually need, um, you know, 130 times 10 because they have 10 sites. And so now we're doing 1300 builds for one customer. And Grant does not like when you're doing that many of a thing of, of, of a thing like that. And it's a thing that depends on like talking to different servers. I need images. I need configuration information. I need to make an API call. Like stuff breaks when you do 1300 of these. Absolutely. Especially, especially with node, right? Yeah. And, and you know, what we've found is that, um, well, like I don't want to blame this on grunt. Let me be really clear. I don't want to blame this on grant. A lot of this is our, how we used grant. Um, but what we found is that dealing with those error cases and handling them gracefully and in an automated fashion is really hard in grant. Um, you know, so having grant do those 1300 builds times and customers, um, and like, sometimes we have to redeploy all of our customers because we found a critical bug and now we have to redeploy everyone. We do use grant to do that right now, but it's pretty painful. And it's pretty error prone. Um, and there isn't a good retry strategy at all. Um, or a good, just a good error, um, handling in general. Uh, cause we don't want to like, if, if an API request fails, we don't necessarily want to fail the whole thing. We might want to try again, right? Like 10 seconds. Um, and that's, that's, um, with your traditional grant workflow of like run these eight tasks in series. Um, it's coming up. It's coming up with a way to say, Oh, task three failed. Well, just, just wait a minute and come back and run it again. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Scheduling it back or whatever. Yeah. Yeah. So, so that's a really interesting problem that we deal with at the scale that we operate and we're, we're transitioning toward a system that is based on Amazon simple workflow that he has cues and activity workers and deciders and all this stuff. Um, you know, we're, we're making slow progress on that, but, um, I'm pretty excited that we will make that happen and have just a much more robust system for, for handling that sort of stuff. I'd imagine that it'd be kind of difficult because my brain first goes to, well, cash things, right? Like you have, you have the ability to hash everything and then point it towards the cash. But the problem is with something like that, each customer, their stuff is going to be different. And so caching for them is probably like, it's not going to help because you're going to be pointing towards that cash maybe one other time. And ultimately the cost of the cash is going to be higher than the game you get out of it. Yeah. I mean, we, we solve some problems with caching. Like we did have some services that we were hitting 10 times for exactly the same information. Right. So we've solved some of that, but fundamentally we, we really realized that we needed, we needed a system where the steps could operate somewhat independently. And it wasn't, it was a series of steps, but they could have independent retry strategies. Um, and independent kind of failure modes and the ability to have a step fail without the workflow failing and the workflow would, would recover from that, or at least attempt to recover from that, uh, in a graceful way. Um, yeah. So, so it's, um, and there are aspects of caching all that, but really this comes down to like smart queuing of these tasks in, in the past, like we were queuing the build. Right. And now we need to queue like step one of the build. And then once step one finishes successfully, eventually we queue step two and then a worker picks up, like there's a worker for step for the step one queue. And there's a worker for the step two queue and a worker for the step three queue. And so you have workers operating on each of these queues for the individual steps. And then some larger orchestrator that's watching to see like, Oh, steps one through eight are complete for this task. Like I can call this task complete now. So, um, I think that's a really cool thing to do. Yeah. And Amazon simple workflow is super amazing for this. It turns out, um, I actually have no experience with it. So I'm, I'm completely in the dark. Me neither. And so until I went to lunch with someone way smarter than I am, um, and was telling him what I was planning on building. And he was like, um, let me tell you about this thing that already does all of that stuff for you and way better than you're going to. He was very nice about it. He was, he was extremely nice about it. Um, just nicely telling you to do something better, do something better. And I love that. I love having, I love people stopping me from doing stupid things. So, um, yeah, Amazon simple workflow is pretty, pretty nifty. It costs some money, but not actually like ridiculously little relative to what you get. Well, especially if you're sitting, if your server is sitting there turning out 1300 files, when one person changes one thing in their configuration, then yeah, you need some, you need some automation. All right. Turns out. Yeah. Well, that's awesome. So bizarre voice. If you guys are getting into, uh, if you are running some, um, what am I trying to say? This'll be one of those times I cut out and post. Let me try that again. That was a great time for me to cough too. So there you go. Yeah. Clear the void. Clear the clear throat. Do all that. All right. So by the way, I typically cut these episodes in, in the middle of the week. So, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, so, Do you have smaller companies as part of your customer base? No. Okay. No. No. We deal with pretty big companies with marketing budgets. Cool. Yeah. Companies that probably already know about you anyway. Yeah. And I'm much more interested in getting other developers to come work here than getting us more customers. Don't tell anyone I said that. Don't put that on the... I'll keep that one quiet. Put it on tape. That's just blackmail. Yeah. I'm just kidding. Okay. So I'll jump back in and I'll say... Well, I guess... Do you guys have a call for developers anywhere right now? You know, I don't know if we do or not. Hold on. Okay. Because I was going to promote that specifically. If you're really interested in these kinds of things, then Bizarre Voice is looking for people who are interested to work with. Rebecca and... Yeah. Where is the new recruiting here? Hold on. Man, they could have come up with a short URL for this, but they didn't. Just bizarrevoice.com slash jobs and then... Cool. Search for research and development. Those are good jobs. Awesome. Well, we can make a bit.ly or something to put in the show notes too. Yeah. To make it easier. Yeah, I can. I'll send you this. Just so you have it. Cool. Let me look at that. All right. All right. So now I'm going to officially go back into show mode. So if you're interested in doing this kind of work that Rebecca and I have been talking about, Bizarre Voice is looking for people who know how to do this kind of stuff. They're looking for people who are interested in working on enterprise level, type applications at the research and development level. And we'll include a link in the show notes for anybody who might be interested in that. Who knows? You could be working with Rebecca possibly in the future. So awesome. That concludes the first part of my interview with Rebecca. Make sure you subscribe if you'd like to be notified whenever the next part of the interview comes out. Or just keep an eye on developertea.com. And of course, you can follow me on Twitter at... If you'd like to get in touch, you can email me at... If you'd like to support the show, make sure you check out... Any amount is a huge help. In fact, we just had some audio equipment fail on us. And so we're having to replace it. And that's the kind of stuff that your donations go towards. Thank you so much for listening to the show. And until next time, enjoy your tea.