Noel: Hello, and welcome to PodRocket. I'm Noel, and joining us today is Charlie Gerard. Charlie has got quite the title here, but she's a senior developer advocate at Stripe, a Google developer expert in web technologies, and author of a book about TensorFlow. Am I missing anything? Charlie Gerard: No, that's pretty good. Yeah. Hi. Noel: Awesome. Cool. So yeah, I guess just, let's jump in. Tell us a little bit about yourself, your background, and what you're working on right now. Charlie Gerard: Sure. So, as you said, I'm a senior developer advocate at Stripe, and what I work on right now... The way that people describe developer advocates change between different companies, but to me, it's a part of maintaining our open source samples. So there's a lot of code in that part. Being able to work with different languages, because I'm more proficient with JavaScript, but our samples are available in Go and Python and Ruby, so I have to be able to contribute to that as well. And on the more educational side, I'm in charge of writing blog posts to either tell people how they can use Stripe products, or even, in general, I like to dive into a lot of random technologies, and Stripe is happy for me to do that as well. So anything that I can teach people about, I like to do that. Noel: Nice. So you said a big part of your role is maintaining the open source examples and snippets and stuff. Is that accurate? Charlie Gerard: Mm-hmm. Noel: Yeah. Is that for all of Stripe? Because Stripe has a very large product set at this point. Is there any particular area where you're focused? Charlie Gerard: So in the way in the work that Stripe does open source, you have the SDKs and the samples, and these are two different things, but the samples are more on the advocacy side where I basically show you how to use the SDKs. So I don't maintain the SDKs themselves. There's another team that does that, but the samples, I think at the moment we have about 50 of them, so it's a lot of work maintaining that, and it's just growing. We never really archive any, so my list of things to do keeps growing. But it is around showing examples of how you can use Stripe Checkout or how you can use Stripe Identity. And each sample, I mean, usually we would want to have them in all the seven languages that we support, so it is quite a lot of work. Noel: Yeah. That's a lot of code. It's a lot of code to be sure. How do you guys go about that? How do you maintain stuff? Like if versions are updated and stuff, like you said, stuff just keeps getting added, how does that all get tracked and managed? Charlie Gerard: Yeah. Well I actually, I think for a while we were maybe not updating it as often as we should have. So I only joined about six months ago, and I saw a lot of opportunities in maintaining our samples in more of a better way, or at least making it easier in the long run, so that's what I'm mainly focusing on is about how to deal with the long term and updating things. So as our samples consume our SDKs, for that I automatically update the versions because there's no security issue, and in general, we would have some tests that would check if our samples break. Before the third party tools that we use in our samples, I do check for certain security issues if some people are trying to add some weird stuff in our samples. So there's some manual work, some automated work, but I think that over time I want to use a tool to check for security vulnerabilities in dependency updates that would allow me to automate more and more of the work so that I wouldn't have to do all of it. Noel: Yeah. No, for sure. Can you give us an example of a third party that would be used in a sample? Charlie Gerard: So, for example, Express.js. So in the Node.js versions of our samples, when we spin up a server to show how to use Stripe Checkout, for example, we use Express. And there's regularly updates to the version of that tool. So I need to check what has been merged, is it a minor update or a major update, because depending on if it's minor or major, I will also have to check if that dependency has broken our sample or not. Not only in terms of security issues, but also is it even still working? Noel: Yeah. Of course. Yeah. So you talked about using some tooling for that, especially around vulnerabilities, but also there's process work. I guess outside of the vulnerability checking, because I feel like we've talked about that a lot, but what other tooling helps with, like you said, there's all these different versions everywhere on tons of different stuff, what kind of tooling or technology are you using to keep track of that, help manage, figure out what can just be updated with a button click versus having to go in and tweak stuff? Charlie Gerard: Yeah. So I've actually started kind of building my own automation system at Stripe to do that because so we could have some tests that we're working on that at the moment where it would... Or like GitHub action, we could spin up our sample and check that at least the pages is visible, and if that check passes, then we could automatically merge the PR, because the samples are usually quite simple in terms of interface. You might have one first page where you fill credit card details, and then you should have success page after. So it's not the same type of test that you would write for a real production application. But then, as I noticed that a lot of our samples use the same third party packages, for example, if I've checked it on one samples, I can automate the merge of that same version on all of the other samples that have the same PR open by dependable. So I haven't done that a little bit and I'm testing out what would work, what doesn't, but yeah, at the moment that mix of having the test that would check that the page still loads. And at the same time I do one manual check to check if it's working on one repo and then I wrote my own little CLI tool that just fetches all of the PRs open on all of the other repos and checks if there's one that matches the one that I'm currently manually checking, and if it does then automatically merge, merge, merge. So I don't know if it's the best way to do it, but at the moment it really reduces the amount of manual work that we have to do and the samples are still working. So it's an in progress work at the moment. Noel: Yeah. Yeah. It's a somewhat unique problem, I think. Especially in that there's lots of you're maintaining dependencies that are, or examples, I guess that are in a bunch of different languages. Yeah. We're, we've been talking to a lot of people that are contributing to frameworks and they kind of have a similar flavor of this problem, but at least they're typically always targeting JavaScript or something. It's not like, oh, we've got to make sure this works in seven different languages. So yeah, I'm sure that problem is a little bit unique. What existed, I guess, what was this environment when you stepped into it at Stripe, was there a team at all maintaining it? Are you part of a larger org now or are you kind of a solo person? Charlie Gerard: So when I joined, there was mainly one person in my team that was already doing that work, but that person is also doing a lot of other work. So that's why when I joined and I noticed that there was some improvements that we could make in terms of automation. Now I've taken over that work and the person that was doing it before, I can go to him if I have questions, but he's kind of freed up to do the rest of the work that he wanted to do. So I guess I'm may probably the person that focuses most of the time on it at the moment. But the goal in the end with the automation would be that we would all, I mean my entire team would have some freed up time as well, because I think that when I joined, I think we were kind of merging just like, yeah, whatever, just merge. I think it's like, we knew that it wasn't probably the best workflow, but there's a moment when you have 50 repos in one person, seven different languages. Yeah. Can't always do the things that's got either way that you would want to do them, but hopefully with what I'm working on, we can have more confidence that we know what we're merging and it works and it's safe. So yeah, that's trying to leave things better than I found them. Noel: Yeah. No. Awesome. Yeah. It sounds like, I guess maybe I should just frame it this way when you stepped into it, you kind of said there wasn't a ton of automation or there was, but it was a little bit, were you given quite a bit of autonomy on figuring out what tools to use and what made the most sense to set up in terms of automation? Charlie Gerard: So at the moment, yes, definitely. I go to my team and I say, Hey, I want to do this. And I'm like, cool. And then I go and I do it. It's like, I'm not really, I mean, I want to say yes and no, just because also with the fact that Stripe is a big company and financial company, there's some tools that I can't install on my computer. So there are some times some packages that I won't be able to install. So I think so far I haven't really ran into that problem because the automation that I'm doing is with the GitHub API and then I'm using a tool that's not forbidden to use, but yeah, if I was installing a package for example, because the CLI that I'm building, I'm not using any other repos to spin it up or something. But if I was using a tool from GitHub that was forbidden that I can't install, then I would have to find another solution. There's always a work around, but in terms of my team there, if it works and it helps everybody, we don't have a preferred tool Noel: Enjoying the podcast? Consider hitting that follow button for even more great episodes. Is there anything on the horizon in that automated tool, chain, workspace, any tech that you're excited about? Charlie Gerard: I haven't really looked into what might be coming up. I, well, what I want to do is to be able to rely a lot on GitHub actions, but they don't always work as expected. So I mean, I guess if GitHub was working, if GitHub is listening to me right now and would like to make sure that they're working better, I would love for that to happen. But I don't, there's nothing right now that I'm looking at that that is not yet available. Noel: Gotcha. Gotcha. I mean, that's probably a good thing. If you feel like most of the stuff you need is there and available and working. It's probably an okay place to be, I guess. How about same kind of question, but from a Stripe standpoint, is there anything on coming from Stripe that you're excited about that you've been writing up examples for or anything recently? Charlie Gerard: Well, nothing that I would be able to talk about if it's not released, I can't talk about it. Yeah. I don't. Noel: No that's okay. That's okay. No worries. I guess. Yeah. Moving away from Stripe a little bit. How about TensorFlow? So has your work there been more recent or was this kind of stuff you were working on before Stripe or what was that timeline like? Charlie Gerard: So I started looking into machine learning in general. Maybe what year is it now? 2022, maybe four years ago. And at first I started in Python because I don't think that Tensor projects was really a well known thing at the time. So I wanted to use to learn about machine learning so I could make my side projects a bit more interesting. And then I started learning about that and I realized that Tensor Pro GS was like, it would be a way for me to learn about my learning, but in JavaScript. So I wouldn't have to switch languages. And I studied from there, I built a few things and then I spoke at conferences and then I write a book. That's it. How things usually happen? Noel: I mean, yeah. Getting to authoring a book is pretty impressive though. Yeah. What is the book cover? What's the main focus? Charlie Gerard: So it's more for beginners. So if people already know a lot about TensorFlow JS, I don't think that they would learn anything new in there, but it's to show a lot of the things that TensorFlow JS can do. And especially, I want people to understand that it maybe sounds scary, but it's not at all. When you actually try to look at the features that are available and start to build a few things, a few projects, you realize that you can understand things about machine learning without using the language that would be in academia or in all of that stuff. So the goal would be to make it more accessible and to show people because the book goes over a few projects. So it would be to show people how to get started with machine learning, build a few projects and then people can come up with their own ideas and go from there. Noel: Nice. Was there, I don't know, any particular challenges you ran into when authoring or anything that was hard to quantify well in that format to help encourage people to ramp up and check stuff out? Charlie Gerard: Well, writing a book was really hard in it in itself because. Noel: I'm sure, I'm sure, yeah. Charlie Gerard: I think it's hard when I knew I wanted it to be for beginners, but always I think it's the same thing as when you're at a blog post just at another level because it's like, where do I stop diving deeper? Or where do I stop in terms of even where do I start? What is my base? I want to assume that people know a little bit of this, but not too much because I don't want to lose them or make them scared with a weird term. But then how far do I go as well? Because when you sign a contract for a book, they ask you for a certain number of pages. So can't, you're not going to go right forever and neither. And also in a book format, you can't really update the code. So I wrote it for, I think one of the first versions of TensorFlow JS and I think maybe a few months later they're released like V2. And I don't think there was that many changes, but it's hard to make sure that your code is up to date. If open source software keeps moving and a book kind of stays the same. So that was one of the challenges, but yeah, it's finding ways to make it interesting for people not knowing at all what people want. So that's definitely one of the challenges. Yeah. Emily: It's Emily again, producer for PodRocket. And I want to talk to you, the person who's listening, but won't stop talking about your new favorite front end framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it because you are really important to us as a listener. So what do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing? Weird little component libraries? How to become a productive developer when your WiFi's out? I don't know. And that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet, right? So reach out to us. Links are in the description, $25 gift card. Noel: Yeah, I think that's probably an acute observation in that a lot of people in the dev space have such diverse backgrounds and things. Even within software development. There's so many different places people could be coming from that it's hard. It's hard to figure out what the beginner is as far as personas. Charlie Gerard: Yeah. All you can do is try. And I definitely tried. I mean, I've gotten good feedback from people, so it's nice. All I want is for people to get an introduction and maybe get excited and then they can go and do whatever they want with that knowledge. But yeah, because in the process of writing the book, I read a lot of other resources and the language that is used is really not accessible. It's almost like machine learning specialists talking to each other with all their jargon and it's not really nice for people coming from outside. So I was like, oh, I don't want to be that kind of resource. I want to be the other side where I kind of introduce you into that space. And I do talk about the jargon, but I define it instead of assuming that people know. And then hopefully if people go from there and they go and read a research paper, they'll understand more what's happening and they won't hesitate to go and build their own projects because hopefully they'll have a foundation that was a nice entry into that space. And then you can go and do your own research. Noel: Nice. Do you think, I guess, more philosophically here, do you think we're kind of at an inflection point of machine learning and that it's become begin going to become more accessible at least for the pseudo technical people to take it and run with it. Even if they're not machine learning, people were hitting the point where it can be implemented and used. Do you think recent developments have made that the case or there still quite a bit of ground to cover? Charlie Gerard: I think I've seen more and more tools built for non-specialists to be able to use it's like dev tools for machine learning a bit, even just the fact that TensorFlow JS exists. It is to open it up to the JavaScript community. Whereas before TensorFlow, the classic TensorFlow is in Python. So already you have companies and people building tools and frameworks that bring more people in by making it available in different languages or showing you the different use cases for it. Because if you're learning about machine learning, maybe you might think, oh, all I can do is use, I don't know, financial data to make predictions, but I don't have financial data. But when you look at all of the different applications, now you can use images that with data sets that are open source or you have models that are open source, a lot of open source machine learning models are on GitHub to do object detection super fast and you end up using it only just like an API. Like you ping an in point and you send it an image and it spits back a prediction of what's in the picture. So I've seen a lot of people building tools to democratize the use of machine learning. So I personally like that, but in terms of teaching people how to make their own model going a level deeper, I don't think we're there yet, but maybe that's also not the point. Maybe we just want to provide the tools for people to do it easily. And maybe we don't want to focus on people actually building their own, because that there's a lot that goes into making your own machine learning model because you also need a lot of data. And most of the time it's only companies or research centers that can have that amount of data. Me as a person, if I wanted to make my own object detection model, I don't have any pictures or I'm not going to spend my weekend taking, I don't know, a million pictures of my fridge just so that it learns what a fridge is. So maybe it makes sense that we are Democrat democratizing the tools and making a lot of models available and maybe the layer underneath we're not quite focusing on right now. I don't think so. But Noel: Yeah, I think that that kind of led into the next question that I planned on asking was, is like I think a couple of different ways that machine learning is kind of permeating, not the developer ethos a little bit it's APIs that I just call and don't have to really know what's going on. It's just another magic endpoint that does a thing versus really getting in the weeds and building a product around it. Do you think long term, there'll be kind of a few providers that have, well, I guess we end up with a few providers that end up with well established models and good APIs designed around them to make it easier to invoke and then get a response back. I don't know, say fridges, for example, be like, I'm just building a home furniture identification app, whatever. And I want people to take a picture and I'll tell them the model, their fridge. Then the dev that's doing that just calls an endpoint and gets the data back versus are we going to be in a point where they have to pull some book about TensorFlow and figure out how to do it themselves? Charlie Gerard: Well, I think we're already at the point where providers have well established APIs. If you look at well there's Google has a lot of services and Microsoft and Amazon, I think they all provide services for different types of machine learning. They all have image detection or some text thing, or sometimes you have more specialized AIs. The one for the text one, I forgot the name, but now you have people using DW E like the new thing to generate art, but these ones are more I guess, experimental, but at least the fact that Google, Microsoft, and Amazon are already providing APIs that shows you that well, you can set up pretty easily services like this, but I actually don't think I've never used any of their APIs myself. So I don't think I've worked yet in, on a project where I needed to. So I haven't really used them, but I guess maybe what is sad is that if we then rely on these three, it means that we only think about applications that are provided by these three vendors or it's like, whereas if you pick up the book or a book or a course or whatever, and you make your own, then you have more freedom around what you create. But I guess it always depends. We kind of do that in general in the tech industry we use what's popular and then you have some people who go and build up indie projects around it. And you have people who just never do that. So I guess it will depend on what people want. I want people to be able to branch out from the big companies and go and try and do things themselves. But then it's like, not everybody has the time or even the motivation to do it. So at least it's good that there's providers, so people can play around with machine learning. But to me, the more resources there are around being more creative and doing things to yourself, I would love to see more of that. But Noel: Yeah, for sure. Yeah. I mean think of course we're going to end up with a whole range of things available. Charlie Gerard: Hopefully. Noel: Yeah. I think it'll be yeah, hopefully. Right. Yeah. How about, what were your initial projects that got you interested? What was scratching at you initially? Charlie Gerard: So when I got into machine learning, the reason why I wanted to learn about that is because I was doing a lot of experiments with brain sensors and I ended up being stuck with what the vendor was allowing me to do basically. So when you buy a brain sensor, there's a few different ones, but you can subscribe to states like focus or calm, or sometimes you have certain events. So you train the device. So you wear the device and it tracks your brain activity. And then you can train certain thoughts. So thought of movements in particular. So there, you could be training the device to recognize when you're thinking about pinching your finger or moving your foot. I did this one a lot, but it's like, you're kind of stuck in what they allow you to do. So it's great to get started, but I wanted to go further and use my brain data with a machine learning algorithm that I would write and try to predict other things than what was defining the interface. And I realized that I couldn't go there if I wasn't learning about machine learning. So it's kind of everything that I'm learning is from something that I've done before. So I kind of increment over time and go in different places. I mean, did use that knowledge in the end, I ended up using my brain sensor and detecting what blink looks like in terms of brain activity. So I could detect when I'm blinking right and blinking left to use that, to control an interface. And it was really interesting to wear the brain sensor and then you blink your eyes and you can see the spike in the data coming from your brain and you can be, oh, I can see it. And that if in the individual representation of data, if you can see something like different patterns that a machine learning algorithm is going to be able to figure it out pretty quickly. If the difference between maybe a flight line and all of a sudden you have a spike is something that's quite noticeable in data. And that you can build a machine learning algorithm around that to find that spike. So every time that you do the blink, then machine learning algorithm is going to be, oh, there's a difference in state between before and after. And you can use that to control an interface. Yeah. I want to go further, but at least that at least this one worked. So I could validate that my hypothesis worked and then I wanted to go a bit further. I haven't had the time in a while. Noel: Nice. Yeah. Is this data that the brain sensor was spitting out? Is it multidimensional? Is there a lot to parse? Was that why it's kind of nontrivial? Charlie Gerard: Yeah, there is a lot to, it depends on the amount of sensors that the brain sensor has. Mine, I think the one that I'm using currently had eight or nine and it's a lot of data for a second and it's time. So then you can use timestamps to time events as well. But yeah, it's a lot, it's kind of almost the fun part of machine learning. It's not really building the model itself. It's very figuring out what data you need in what format. And if it's time, then you have to really track it at the time you're doing something. But yeah. Noel: That sounds like a super Charlie Gerard: Nerding nerding out on data now. Noel: I mean, you're here to talk about machine learning. So I think that's an okay thing to be doing. How about other side projects? Anything else cool you have worked on or are working on right now? Charlie Gerard: The latest thing that I built was to get data from airplanes that are passing above my apartment, using an antenna. And that was super interesting because it was only in the browser. So all front end, JavaScript using a device with an antenna and looking, learning about what is called ADS-B data, which is the data kind of the protocol that planes used to communicate with each other. And it was really cool to just be on my rooftop with my laptop and my antenna. And then I knew that when a plane was flying, I was receiving data that was displaying in the browser. And I'm not really doing anything more with that, but it was really interesting to learn about the format of the message that planes send to each other. And with that antenna, I read online that I could also, you can get data from the international space station. Noel: Oh, wow. Yeah. Charlie Gerard: So that's my next step. But yeah, you can get, sometimes they send, I think it's called SSTV images or something like that, but I don't think they do it all the time. So you can sometimes receive images from space. Super cool. Noel: Yeah. That sounds crazy. I don't remember the acronym you use, but the data that the planes were spitting out is that in a, are they always just broadcasting this and anyone can just go pick it up? Charlie Gerard: So from what I understand, yes, it is not secure in any way, anybody can receive it. Your internet has to be a certain length just to filter out data at a certain frequency. And in that data, when you decode it, you get the latitude, longitude, speed. Sometimes, I didn't get it all the time, but you can, should be able to get the flight code, like a flight Alaska, like AS139 or something like that. I didn't get it all the time, but sometime, so then you can kind of check it with one of these website, that track airplanes, just to make sure that it's valid. Oh yeah, no, I did get the right plane. But yeah, it's just random project, but I did earn about how to use the web USB API and how to decode certain messages and all that stuff. So to me, I find that super interesting, but yeah. Noel: Yeah, no. Yeah. The I've gone down that web USB API for side products and stuff in the past, that stuff is always kind of, it's weird. It's kind of niche once you've figured out, it's like, oh, this is cool. I'm glad I know this I'm I may never use it again, but it's fun to, Charlie Gerard: But you might one day. Noel: Yeah, exactly. Yeah. You got it as a tool on the tool belt. Awesome. Well, I guess, yeah. Anything else you'd kind of point listeners at or encourage them and encourage them to check out? Charlie Gerard: Or in general or? Noel: Yeah. Yeah. At large. Charlie Gerard: Large, I mean, I just wish people were doing more weird stuff. I feel like there was a time, I don't know if it was because of the pandemic, but there was a time where I was so more people just building weird stuff and showing them on Twitter. And I don't know if people are just tired or doing other things, but I've seen people doing less weird stuff or maybe sharing it less. Because Twitter is not the most nicest place ever. But if you're building weird stuff, let me know. I always love to, I get inspired by other people's projects. I don't wake up in the morning with random ideas. Usually I start from something that I see somewhere else. So if you want to help me build project, you should build projects too. So then I get inspired, but not in terms of, I don't have a specific tool or language or technology. I'm interested in just exploring how things work. So Noel: Nice. Yeah. Awesome. Is like Twitter, your main outlet, your website, or should people, what should people check out? Charlie Gerard: I mean, if people want to tell me something, Twitter is probably the best place, but yeah, on my website, I usually share my projects or blog post about stuff that I'm looking at, but I'm not super active on Twitter. I'm more like, I'm less active than I used to be. Just because people are not always nice and it's exhausting, but Noel: You don't want your brain to continue rotting as who I understand. Yeah. Charlie Gerard: Yeah. There's like what you read, I need to, it brings me down. I don't need that, but maybe that's fine. Maybe people are actually active and I just don't see it. But yeah, if you know, want to share something, Twitter is usually the easiest place to find me. Noel: Awesome. Yeah. We'll get links for those in the show notes and yeah, what's the book called for listeners if they want to find it? Charlie Gerard: Oh, it's sorry. I had to remember for a second. Yeah, it's called Practical Machine Learning in JavaScript. Noel: Awesome. Awesome. Cool. Well, we can try to get a link to that as well. Awesome. Cool. Well thank you so much for coming online and chatting with me. It's been a pleasure. Charlie Gerard: Thank you. Thanks for having me. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on apple podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome pod rocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.