Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I have the pleasure of interviewing Rebecca Murphey. Rebecca has been doing JavaScript for many, many years now. I heard about her on the Yequery 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 Yequery. 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. Go check out Yequery 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. Basically, it's about JavaScript that you write to be embedded on another person's page in 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 to talk to you. I've followed what you've done in the past for years and years. Of course, with YeqWere back in the day, that was how I first was introduced to the work that you do. You were the first person actually on YeqWere 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. Yeah. Yeah. Those were the days. I actually just found a picture and tweeted a picture of the YeqWere days. That 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. In that wild. It's amazing how long it seems like all of the day. The knowledge that we gained five years ago was just a few weeks ago because a lot of it is still so relevant. 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. And what a different world it was and companies that existed and don't even exist anymore. A lot changes. It turns out. Sure. Speaking of companies, you work for Bizarre Voice which I'm sure I have mentioned in the intro which I haven't recorded yet. 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 reviews software. So if you go on the website of pretty much any major retailer in the US 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, which is pretty cool. It's a, 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. Like. Yeah. And 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, every time I go shopping. Like I bought a pair of jeans the other day and I read the reviews and those reviews were put there by Bizarre Voice. And it is, it has really not to put like to find a point on it, but reviews have really transformed how we buy things. 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'd 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 the 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, the field because we have marketing people to do that for us. Right. Yeah, I mean, the amount of insight that you can get from reviews positive or negative is just, it's, it's really pretty incredible what reviews do for, for companies. So it's a fun, it's a fun product to work on and it's fun to work on something that I do actually use in reality. And not only me, but like, all of your friends and not only, and not only my tech friends, but like literally, every friend I know, right. Yeah. 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, on an average day load the JavaScript that you have written at, or have touched at least have, have been in charge of doing some rough math like millions. Yeah. Up there, right? Yeah. 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 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 often would you say that you are delivering new versions of script, of JavaScript files? So on bad days more than once a day. On, on good days, you know, a couple of 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 some change. We've definitely in the time that I've been up as our base, we've moved to, I've been here two years, a little over two years. We've moved to doing much more frequent releases with much more, like we've really improved our QA game and improved our automation game a lot so that we can release stuff with confidence and not have an owneress like, you know, get a cut a release branch and then spend two weeks testing it kind of thing. Like we're able to cut a branch and get it out in the world pretty quickly. Yeah, so that means this comes as a, it's 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 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, you know, rich experience and all of that happens in the browser. And of course, we're all familiar with this concept rate of single page applications, executing in the browser. We're most of the co-excuse in the browser and the HTML is generated in the browser and blah, blah. What's different about a third party app is you do not own the execution environment. 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. 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 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 is never wrong. So hello as it does in third party land because we can create test pages and 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. Oh, man. And maybe they also have a version of prototype from 2009 and they also have a version of jQuery or maybe two. And so that makes the automated testing a really interesting problem, let's say. So we've invested a lot in unit tests 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 manual and it involves simulating loading the application into a real customer's page. We have a set of real customers that we'll use for a given release and we use Charles Proxy to pretend we're loading this new code into the page and see what happens. 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 they're humans doing it, there's so much less room for error and they're able to execute it really quickly. And 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 that kind of thing. Yeah, wow. So man, there's so much to talk about there because when you think about third party JavaScript, for those of you who are listening and don't know exactly what that looks like, think maybe you have a site that has, I don't know how to pronounce it, but I always say discuss some people call it discus. Site where you have 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 their domain like not in an iframe, correct? Yeah, we do not render it in iframe, which is one of those decisions that you look back on every now and then and say like, I'm not sure that was the right choice, but the iframe is really limiting as far as some of the layout constraints that you have. So yeah, we know load and iframe, we load in the customers page. And so yeah, just like following up with what you were just saying, when you load in the customers page, their CSS can affect you. And so now you have to clean slate is what we call it. And so the customers like make it so the customer CSS cannot possibly affect your container, which turns out takes a lot of CSS rules in order to state that. And so yeah, you really have to be, you know, 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 that can have a bad effect on us. We had a customer who was redefining the index of method of array. And they redefined it in a way that they forgot to return negative one when the item wasn't found. This broke jQuery, 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 ourselves 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. Because there's infinite possibilities, right? Like they could be listening for you changing and I don't know, inserting something at the bottom of the of the page and again redefining things that you redefined again, like trying to it's always just a fight between the two at that point. So yeah, it'd be impossible to test every possible scenario. I would imagine. But we do test some scenarios like we look at window dot json and see if it behaves as we expect it to. And we actually had a bug where we tested window dot json. It behaved as we expected to. So we were like, cool. We'll just use window dot json later. Yeah. 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 json. So now we have to not only check that window dot json is good, but actually capture it. 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 a whole other just whole their world of JavaScript development. 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 control nothing. Yeah. 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. So that's that's a fun treat to get and 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. It turns out that getting customers to do server side integrations, sometimes it's possible. But often they have to, you know, pull in a contractor and they don't like they have shut down their web dev team because these are retailers like primary business isn't making websites. Their primary business is like selling shoes. And be waste for them to keep them on all the time. Right. And so often getting a server side integration implemented or changed. It's really hard. Smart. Get it. Client side integration. Often they can do that through their CMS or it's just otherwise less scary to them. And so third party job of script will continue to be how bizarre ways 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 that put content on customer pages. And I can't talk about all of them because not all of them exist right now. But you know, so 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 grant task and we should make that grant task shareable by everyone, by all the different front end products that there's our voice. Absolutely. And so I'm working on a team now that's, I'm leading a team now that's more focused on that, on figuring out what we need to change and what we can standardize across consumer facing web apps, bizarre voice versus just focusing on one of those applications. At a time, yeah, yeah. That makes sense. So you mentioned grant. I'm assuming that you guys are also at least moving towards putting as much of your process into an automated thing like grant. Well, I guess you are using grant, but are you testing through grant as well? Yeah, excuse me, terrible allergies. 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 grant for all of our task automation and for development new development workflow, that kind of stuff. And so therefore, yeah, for executing tests, just really is like the wrapper around whatever the test runner is. Usually at Mocha. 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. None of them are like, you should totally use this too. Oh, yeah. Yeah, we have some projects where we just do planal, planal assertion, no, yeah, no unit. That's what I was trying to remember, like planal, no unit tests. And then we have projects that use Mocha and then we have projects that like use Mocha, but which they didn't. And so mostly Mocha, not entirely Mocha, some node unit, some like it's kind of all around that. 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 because I can't get too micro-energy. Right. And it doesn't matter, right? As long as your tests are testing what they need to test, and as long as you're able to run them in a relatively quick amount of time, then who cares? Exactly. Can you run them in Jenkins or in Travis or whatever? Yes, cool. That's really what I care about. Do they return a good exit code? Right. But an interesting thing that we've run into, so we ask about using current. Every time that one of our customers changes some configuration option about their ratings and reviews display, we actually generate a whole new build for them. Every customer gets their own CSS, JavaScript, templates, strings, all of it. They are those are unique to a customer so that a customer only gets the resources they need. We don't want to shift resources that they don't need because they don't have a particular feature turned on. 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. Okay. And we can support up to 130 locals, I think, like some crazy number of. 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. And we have a lot of customers. And each of those customers had not each of them, but a lot of them have more than one site. And so they might actually need 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 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 because like stuff breaks when you do 1300 of these. Absolutely. Especially with node, right? Yeah. And what we found is that, well, I don't want to blame this on grunt. Really clear. I don't blame this on grunt. A lot of this is how we used grunt. But what we found is that dealing with those error cases and handling them gracefully and in an automated fashion is really hard in grunt. So having grunt do those 1300 builds times in customers. And like some days we have to redeploy all of our customers because we found a critical bug. And now we have to redeploy everyone. We do use grunt to do that right now, but it's pretty painful and it's pretty error prone. And there isn't a good retry strategy at all or a good just a good error handling in general. So we don't want to like if an API request fails, we don't necessarily want to fail the whole thing. We might want to try again, like 10 seconds. And that's with your traditional grunt workflow of like run these eight tasks in series. Coming up with a way to say, oh, task three failed. Well, just wait a minute and come back and read it again. Yeah. Yeah. Scheduling it back or whatever. Yeah. So that's a really interesting problem that we deal with at the scale that we operate and we're transitioning toward a system that is based on Amazon simple workflow that yes, cues and activity workers and deciders and all this stuff. You know, we're making slow progress on that, but I'm pretty excited that we will make that happen and have just a much more robust system for handling that sort of stuff. You kind of 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 a 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, we solved some problems with caching like we did have some services that we were hitting 10 times for exactly the same information. Right. So we solved some of that, but fundamentally we really realized that 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 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 in a graceful way. Yeah, so it's, and there are aspects of caching all that, but really this comes down to like smart queuing of these tasks in the past like we were queuing the build. And now we need to queue like step one of the build and then one 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 steps one through eight are complete for this task. Like I can call this task complete now. Mm hmm. Yeah. And Amazon simple workflow is super amazing for this. It turns out I actually have no experience with it. So I'm completely in the dark me neither until I went to lunch with someone way smarter than I am and was telling him what I was planning on building and he was like, 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 extremely nice about it. Just nicely telling you to do something better. To do something better. And I love that. I love having, I love people stopping me from doing stupid things. So yeah, Amazon simple workflows 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 you need some automation or turns out. Yeah. Well, that's awesome. So bizarre voice. If you guys are getting into, if you are running some, what am I trying to say? This will be one of those times I cut out and post. Let me try that again. That was a great time for me to go off to. There you go. Yeah. Clearly, clearly we do. All right. By the way, I typically cut these episodes in half. you. Yeah, which I think I told you. So that that would be probably about where I'm going to cut. OK. So I'm going to give this little pitch for bizarre voice. Is it going to be something that anybody is listening to the show is going to be able to actually invest in or is it like larger, much larger companies who are able to do that? Can you say in that? So when I say in that, I mean, your customer base, do you have small smaller companies as part of your customer base or no? No, no. No, we deal with pretty big companies, like marketing budgets. Cool. Yeah. So companies that probably already know about you anyway. Yeah. And I'm much more interested in getting other Developer To come work here and then getting us more customers. Don't tell anyone I said that. Don't put that on them. I'll keep that one quiet. I'll keep that on tape. That's just blackmail. Yeah. Just okay. 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. Like if you're really interested in these kinds of things and bizarre voice is looking for people who are interested to work with Rebecca. Yeah. Where is the new recruiting here? Hold on. Man, they could have come up with a short URL for this. They didn't just bizarre voice.com slash jobs and then. Search for research and development. Those are good jobs. Awesome. We can make a bit of something to put in the show notes too. Yeah. Yeah. I can't else then do this. Just so you. Yeah. Have it. 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 at Developer Tea. If you'd like to get in touch, you can email me at developertea@gmail.com. If you'd like to support the show, make sure you check out developertea.com front slash donate. 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. Until next time, enjoy your tea.