The more interactions I have with people in Python, about Python, the more it feels to me like jazz improvisation. There are these exquisitely beautiful formalisms that are very sort of intricate and abstract, and at the same time, there's a kind of a vernacular, dynamic interaction happening on a daily basis. It's very concrete. Hello, and welcome to the Py Bytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Valdebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Hey, everyone. Welcome back to the Piebytes podcast. This is Julian. I'm here with Bob. Bob, how are you? Hi, YouTube. I'm fine, thank you. And we're back with Py Bytes podcast, and we have a very special guest today, Blaise Pavon. Hope I pronounce that well. Welcome, Blaise, to the Pybytes podcast. How are you doing? Great. Excellent. It's good to be home again. Nice. I love that. So, Blaze, everyone, is a PDM student client, ex PDmer of ours, and he's just one of the most inspirational people that we've come across. He's got a wealth of experience across all sorts of enterprise companies. He's a massive player in the python community space. Completely believes in python communities and open source. And so we just thought it'd be wonderful to have you on here, Blaze. So, before we jump into everything, do you just want to do a quick introduction for everyone? Hi. Yeah, so, my name is Blaise Pabon, and I'm living in Massachusetts recently spent the previous 30 years in the Bay area. I was kind of a refugee from graduate school in the early nineties and was just looking for a quiet, you know, anonymous little industrial town where nothing would ever change and I could, you know, live a simple life. And that's how I ended up in Mountain View. And then. I know, right? And then things got complicated. Everything changed, and, well, anyway, the rest is history, as they say. So I started working in the computer industry, like I said, you know, because I knew how to play with computers, and it was my passion. And got swept up in network operations and spent a few years at Sun Microsystems, and then I left sun and worked at a startup with my old housemate. And a few years later, we were bought by Google. Spent a few years at Google. And, yeah, so, you know, now I'm just sort of trying to make it all make sense. That's awesome. Good luck with that. Well, that's awesome. I really appreciate you sharing that. And, yeah, it's one of the reasons that we loved having you in PDM is just you had this wealth of experience, and it's not only because you worked at sun like Bob and I as well. Close to our hearts. Yeah, very close to our hearts. So we'll kick it off like we do almost every podcast episode. Let's do some wins. So, Blaze, as our special guest today, do you want to share a quick win with the group, the audience? Yeah. Yeah, I have. Just last week I discovered, or rediscovered, I should say, the Boston Python user group. And during a conversation with one of the members, they invited me to prepare a talk on how to strategies for learning git. A number of years ago, I decided to learn git for real instead of just muddling my way around. And it changed my life. It was really extraordinary experience, and one of my personal missions is to encourage people to be comfortable with git. Cool. Yep, that's critical. And congratulations. That's a huge win. That is very cool. Very impressive. I'm pretty excited about it. Thank you. Nice. All right, Bob, what about you? Any wins? Yeah, we got my PI running on AWs Lambda. I had a little procedure to bundle up packages, but that was not working. But thankfully, there was an article by Michael Allendambas, better known as P mayday on the slack, and it helped me out by building a layer, and I needed that because we started to have type hinting bytes by the same author, p Mede, on the platform, and he uses my PI in the test. We have that running, and the first three type hinting bytes are now live. And it's super exciting. There's a bit of a divide in the python space about type hints, but we think they're super useful. And now providing those exercises, it's really cool. It's really useful for people to get up to speed with them. So I think that's a big win for pivot. That's cool. Nice. That's our code challenge platform for anyone who's curious. Yeah, nice pitch. Awesome, awesome. All right, I'll go, I'll go. My win. Well, I survived a trip, a two week trip, and went to. Came back safely from Tokyo and Seoul. So that was amazing. Bucket list. I've never been to Tokyo before. It was right up there on. On the list, so that that was a win. And then also catching up with one of our ex PDM ers, Daniel, over in Seoul in South Korea. That was amazing. So quite a. Quite a few little personal wins there. And if I was to make it today's win, it was that it took me 2 hours to get the baby to sleep tonight, and I did it just in time for this podcast recording. So, massive wings. Nice. All right, enough of that. Let's dive in, Blaze. This is all about you. So let's get you talking. Tell us, when did you start with Python? Tell us the story. Yeah, so. Well, to be perfectly honest, I started with Python, I should say. My first contact was in 97 when I was a network operator at, in Palo Alto. And it was kind of like, it almost felt like the mythical dream, like, like finally a rational response to Pearl. Because of course, we were just surrounded. Pearl was, oh, wow, I. My head isn't really wired for that. But to be honest, I didn't do really very much with it at all until, gosh, years later, I suddenly found myself at a startup that was, shall we say, overcapitalized and under organized, and I had to dive back into software development after decades supporting salespeople, doing technical support. And that's when I discovered Python sinks the documentation project. And we were in a situation where we had no docs, the engineers weren't going to write them, and I, out of desperation, I realized that the only way to survive was to keep the source of the docs in the same repository as the rest of the source code, so that everything would get built using the same toolchain, and we could then have a description of the document, of the artifact that would be in sync, whatever version was actually running. And then a few years later, I found out about you guys. Nice. Yeah, maybe flashing forward because we all dive into the Python language features later on. Why, you think it's one of the best languages. But yeah, maybe you can sidestep and talk about finding us and ultimately joining PDM. So maybe you can tell us a bit about the journey, why you joined, and your experience, and also what you built with us in the program. Yeah, yeah, sure. So the. So here it is. It's about, I would say, 2016 or so, 2014, 2015. I'm struggling to become a software developer again, and I'm at this company and the release manager quits, and I happen to be the only other person who knows how to increment the version numbers and push out a new ISO. So I get sort of pressed into service as a release manager for about a year and a half, and being somewhat a gregarious person, I kind of am looking around for resources. And I heard you. I think it was Bob on a podcast episode talking about code challenges. And it made so much sense to me that one will use tests as. As the way to set up a scenario and then interact with the language until the test is passed. And when I found out about the PDM project, I had a conversation with Julian and said, hey, this is kind of what I've been thinking. This is my perspective on testing. This is where I want to go eventually with my career. And we really clicked. I mean, it was a conversation that was so energizing, it took me a while, honestly. It was a big investment of time and money. So it probably was a year or so before I was really ready where everything fell in place and it felt like the right time to push forward. But that's. So I think, I guess I could take PDM in with 2019, 2018, something like that. I don't remember. I think we started 2020, so there goes 2020 or 2021 even. Yeah. Yeah, time flies. Yeah, I know. Pandemic time. It's very elastic. Yeah, time perspective changed. Time warp. But yeah, you did some really cool stuff with us in PDM program, and I think it's also exemplary of the kind of idea she can bring into the program. Right. So do you want to tell us a bit more about your project, your main project? You did several. I had a. That's right, the main one. I mean, the, the main one was really the scratching of my biggest itch at the time, which was, this happens a lot in open source, in, excuse me, in web development companies, where people will throw together some infrastructure and they'll keep all of their, their day to day business notes and business logic in, like, Google sites, for example, or Google Docs. And the thing about Google Docs is they're not really files per se. They're the sort of dynamic, they're really, they're really the results of a web search in the backend. And they had their own kind of dom, they had their own structure. So I was interested in crawling. The proposition that I had was, well, wouldn't it be wonderful if I could tell at any given time how current these docs were, how current these sites were, whether they had any broken links? For example, I wrote a script that would essentially interact with the native Google APIs, the Google Docs and Google sheets APIs, and go through whatever docs I had access to as my user id, and then look for URL's and then check those URL's. And if the URL was readable, then it would go ahead and it would crawl through that Doc and make a list of URL's and essentially recursively go through URL, making note of which ones were dead and then producing a symbol of report at the end. And that way you could have confidence, so to speak, as to whether your docs were getting stale or not. Awesome. That's awesome. That is cool. Now that sounds to the, I would say naked eye, but to the listener that sounds simplistic. Right. But given the hidden complexity behind Google Docs, how did you challenge yourself with that? How did you tackle that challenge, I should say. Cause that wasn't easy. I remember it was a mountain to climb. Right. Well, so, yeah, so it turns out that not that many people seem to, at least in the open source world, there aren't really all that many examples of folks interacting directly with the Google content APIs. And having spent a few years at Google, I can understand why the docs are the way they are, but that doesn't make it any easier. Essentially, the information that Google provides tends to make assumptions about how familiar you already are with whatever SDK it happens to be. And so the two biggest hurdles there are the dealing with the authentication, dealing with the login. And so you have to have like a piece of code that gets, you know, gets your process logged in and there's a bunch of homework that needs to happen before that can even take place. And then while you're working, you have to like manage this big kind of blob of pizza dough as you're going along. Right. And, you know, that's like your sort of golden ticket to go around and do things. And you're sending these requests to different endpoints and you're asking for stuff. And the stuff that you have to ask for, you know, it's named differently depending on whether you're using a sheet or whether you're using a dock or whether using the older, you know, oh, are you using this, the older style? Oh, that's so last year. We're doing it differently now, you know. Wow. And so, yeah. And it's just an awful lot of detail. It's the kind of thing it's really nice to. I think, actually this speaks to the value of PDM. You start building a personal repertoire of solutions that are familiar to you and that are like, known, good working. And it's really the difference between walking into a situation and having something that you know will work versus having to consume information on the fly and build something is night and day. Because whenever you're doing, whenever you're doing something that you haven't done before, there's a possibility that it'll break. And if you're doing something that you have done before and it breaks, it's probably broken in a way that's familiar. Yeah. Now this brings back a whole host of memories because I was coaching you at the time. Super interesting project, but definitely also like, yeah, on paper it seems simple, but we ran into so many complexities. And kudos on you as well to fighting through those and making it to an MVP. It was really fun. And also like a valid business idea. That was the interesting part, that it was something really tangible, right? Yeah, I mean, it's the sort of thing that, you know, with a bit more of you, with a bit more wrapping and connections to payment systems and stuff like that could conceivably be the sort of thing that people would buy or certainly the sort of thing that could be delivered in some kind of like an app marketplace. Somebody would have, like if you had a look in badge, for example, that said, oh, this is my percent passing or my percent dead links. That's pretty cool. I like this as an example for everyone that's listening and watching, because a lot of people as they approach PDM or think about I should wait to have the biggest and most grand idea before I tackle coaching. But this idea, very simple in theory. And then as you peel back the layers, you're like, oh crap, what have I done? And I think most people are like that with the apps, the ideas that they have. Even if it's something as simple as building a web app, suddenly you have these layers of authentication and API calls and databases and so on that really give you that experience for what was originally. And I use rabbit ears again, simplistic idea. So yeah, this is awesome. Thank you for sharing that. I do appreciate it. That's really cool. Nice. Okay, maybe a follow up question is, which might lead nicely into the python stuff, is what you used for the project in terms of scraping and libraries. And then maybe also you can also highlight certain core features of the Python language you got to use. Or maybe that's a separate question. Up to you. The. So the, I was actually encouraged to try to depend as little as possible on external dependencies and try to work as much as possible within the standard library. And because, and I appreciate that because in some respects just dealing with the Google SDKs was a challenge in and of itself because they have these various generations. Right. So I guess my biggest learning there was to spend time understanding how Google, because that's ultimately, that was the main piece of content to parse how they package. Basically. What's their recommended way of dealing with, with, in my case, the sheets and the docs. So they've got like this great big bundle of what they call network clients. So it's the Python network client that is the, that's really the Keystone module there. What else? Some pie tests because, you know, never leave home without PI tests. Definitely. Nice. And pycharm, I was really. I took the time to learn how to use Pycharm. To begin to learn how to use Pycharm. It's such a huge package, but I really highly recommend if you're going to be doing. If you're. And in fact, that was, I think the one piece of advice that I would give anyone considering PDM is don't, as Julian said, don't wait until you have this great big project that you want to do. Best time to do it is when you think you can set aside the time, because the ideas and the projects and all of those initiatives, they will come. But if you set us, if you're able to set aside the time to work with the coach and to dive deep into a project, whatever it is, that will build up the muscle and it will help you. It will give you the experience of like going to the mountaintop and then coming back and that will be, that muscle will come in handy. And the time is the one thing, you know, the time and the attention is the one thing that you can't necessarily manufacture. So if you do have a chance, you know, if you, if you have the opportunity to create that space, that mental space, that's the time to do it. Love it. That's all. Yeah, that's great advice. I appreciate that because that is one of the greatest challenges for anyone that joins PDM is we don't sugarcoat that at all. We're like, you do a couple of hours of coding a day, you've got to be able to make the. And I like that you just mentioned. It's not just the actual time and physical space, it's the mental space. Right. It takes a toll to code like that every day and do coaching. But if you can get into that zone and have that set aside, then that's the perfect time to do it. So thanks. I appreciate that. Actually. I have to do the work. Yeah. But I also like what you said before in the sense that your idea has a lot of validity and you can still build it out. But we did also some smaller projects that you might not continue, but you still have that in your repos, in your notes, in your learning, in your experience, and I think you alluded to earlier, you build up that repository even if it's snippets or learnings or things you can just draw from. Right. So sometimes people obsess over to have the perfect ideas. Well, first of all, you said, like, no, that will come, but also like build anything because it's really about the journey, right. And the artifacts that you start to pick up. So, yeah, that's, I think it's a great important point. So, yeah, maybe back to the python, if you don't mind. I think you mentioned best language, second best language, or I think you said it was the best language. Right. So we need to, we need to distill that. We need to, I want to hear what you really like about it. And yeah, maybe also some of the more modern stuff in the latest versions. What is it, what you love about Tyson, basically? Well, I can sometimes be a little bit over the top in my enthusiasm, but please understand that I spent years, like, many, many years in the company of, for example, some of the very best JavaScript programmers in the world, right? And so I, you know, I have, you know, ringside seating at the dumpster fire that is NPM and, you know, Java. Right? You know, James Gosling, all those guys, you know, I worked with, with people who knew a lot about that and I'm familiar with other ecosystems. So it's not like Python is the only thing I know. So my passion for Python, I think, comes from the fact that it's versatile. You can write, you can express anything related to computer science, you can express in Python. And I can't think of any other tool, any other framework language that can, that is that flexible. And within whatever niche you can possibly find, there is someone who has optimized the hell out of whatever that is in Python. People talk about typescript has a typing system. It's like, well, yeah, then you go look at Python and you go to the Adders library and it's like, okay, you know, these guys have taken typing like way, way beyond. So, and then all of stuff with like scientific computing, even numerical analysis, it just goes, it's infinite. So for me, and having been an students of intellectual history years and years ago, you know, for me, I think Python, I think of Python almost as like, like musical notation or calculus notation. It's a way of describing abstractions that is universal and elastic evolving. The more interactions I have with people in Python about Python, the more it feels to me like jazz improvisation. There are these exquisitely beautiful formalisms that are very sort of intricate and abstract, and at the same time there's a kind of a vernacular, dynamic interaction happening on a daily basis. It's very concrete. Yeah, I can, I can. I'm ready to go up against anybody and have a conversation about why Python is better. That's cool. I love listening to you talk about this stuff sometimes. I think I said that to you back in PDM. Just listen to you on the mindset course. I just listen to you talk all day. This is poetry. Yeah. And this is highly relevant. So to some of the people who I hope are listening that we've talked to recently and been like, oh, but we, you know, we code in Java and we code in this and that. Just listen to what Blaze is saying. Yeah. All right, Blaze, I'm going to move on to the next question because I'm just looking at the time, but with one of the things that I have just. That consistently blows me away about you and just, I completely respect about you, both before and after PDM is just your dedication to open source, your belief in it, that you're always presenting the PDM group and even just our normal pie bytes community, you're constantly presenting different open source technologies and stuff. So one, I actually would love to hear from you what drives that desire for open source. And then two, you have told us that there's one specific open source project you'd love to mention, so why don't you go for that? Yeah. So when I was a child, my parents did a lot of traveling, and I remember this would have been like the early seventies, walking around markets in Mexico and seeing typically men with typewriters. And I asked my parents, well, what do these guys do? And they would say, oh, they're scribes. Because a lot of people in this area don't know how to read and write. And so if you need to send a letter, for example, to the government, they will type up a letter for you. And I took literacy for granted because I was going to school in the US and my father was a professor. So it was amazing to me that there would be an occupation in the 20th century of somebody like, basically writing for you. And so nowadays I think of open source and git in particular as like the new literacy. You know, if you're going to express yourself and you're going to understand and you're going to interact with knowledge, there's going to be some component of that that is digital. And if you're going to be anything beyond the passive consumer of content, then you need to understand how, you know, how this information is encoded, how you know, how to update things, you know, what, what those steps are. So that, that's the really the emotional impetus behind that. You know, what you see as me constantly coming up with like, oh, these projects, these guys are moving this forward, or these guys are making this easier, or, you know, these people are looking at this problem. And that was my motivation for starting Vitrina, which is really a very, it's an initiative to create a set of templates to help infrastructure developers show off their work. Because I'm basically an infrastructure guy, I'm a network guy, information security as well. And it's really hard to show your specialty if your specialty is underneath a user interface. So the web guys have things like that general purpose demo app, the real world app, we can include some links later on, but the real world app, it's kind of like a demo app. It's like a clone of medium, and you can implement it in any number of languages. There are dozens and dozens of implementations. Well, that's all well and good because it's got a GUI, but if your specialty is certificate management or failover or something like that, how are you going to do that? So Vitrina is essentially a set of tests, and the illustration is the test results. You can then run this very simple app, the tests run against the app, and then you can make your changes, you add your tests, and then you can show the results of like, okay, these are the results before, and these are the results after. And that comparison of test result effectively becomes the illustration of what your work is. And because it's all thanks to virtualization, you don't have to have all of AWS up and running. You can just emulate the app, have it run in a container, generate your tests, and there you go. That's awesome. That is really cool. I like that because it's, for one, that's just such a great idea and sounds so technically brilliant, but from our value at PI bytes, as you know about, is that it's about lifting people up. You know, there are so many people out there. What I like about it as well is that this will also benefit people who can't really demonstrate their work from a security perspective. Because when you work in infrastructure network, it's all hyper confidential. You can't have any of that code outside, you can't even talk about the stacks that you use. Um, so this would definitely help, right? I, I actually think this is very cool. Um, that's a great idea. And yeah, you have links for us for to put in the show notes for that, right? Yeah, we'd love to get people looking at that. I think it's awesome. Nice, great. Thank you for sharing that, Blaze. That's awesome. I really, really like that. And we'll link it below that. People can check it out. Yeah. So another probably the final question is around communities and pretty similar to the open source, you're very active in many developer communities, so yeah. The question then becomes how you manage that all. And yeah, what do you feel is the value of communities in software? And yeah, maybe some tips for people to effectively start communities or manage them. Yeah, I think the. So most recently I've been doing as much ensemble or pair programming as possible. There's a weekly group that actually, thanks to all the digital layoffs that are happening, the last couple of weeks have been a little bit tricky. Some of the members are kind of in flux, but on Wednesdays we get together and do cucumber. I think it's called Cucumber BDD. It's basically initiative out of the cucumber community. So we're essentially going through a test driven development exercise and writing a GitHub action to curate users, inactive users, and retire people who haven't contributed to the project. So it's basically a little script that interacts with the GitHub APIs, figures out whether or not somebody's contributed in the last year, and then moves them from one team to another. So the emphasis is really on the collaboration. So group of people, in ensemble programming, someone is the driver and another person is the navigator, and then another person is like the scribe who will go look up solutions in the documentation, et cetera. And we rotate so that I feel kind of passionately about that because it helps people overcome the self consciousness of coding in public. And it also reminds me of the experience, for example, that I had in PDM, interacting with the coach, that I think that sort of helps overcome that emotional barrier of interacting with people. And I've noticed people come into the group with very little experience and their confidence just increases so dramatically, even after just a few sessions. And they can become very valuable contributors to any project, not just whatever we happen to be doing. So I encourage anyone who is interested or potentially afraid of doing ensemble programming to find a group or get in touch with me. I'm always happy to have people I hate working alone. So if anyone is interested in learning more about that, I think that's really the backbone of community is going beyond simply asking a question in some anonymous forum. Stack overflow is like the opposite. It's like the anti community. So if that's your current understanding of what open source is about and what community is about, then know that you're, like, at the opposite end of the spectrum, and you need to turn around and walk in the other direction. That's cool. No, like, what I really appreciate about what you said is, you know, again, there's that aspect of lifting people up. You know, the value of a community is in helping you build your confidence, ultimately, and so that you can actually contribute better and learn from other people. And just, there's this growth, mentality and mindset that I really respect and love about. Well, generally about the python community. So I think it's really cool that you do that as well, you know, so I don't know. Do you have, like, 27 hours in a day as opposed to 24? Don't know how you do it. No, I don't. Well, so, ironically, I don't. I would love to have 27 hours in a day, and I'm. And perhaps because I'm involved in so many different projects, it feels to me like I'm not making very much progress in anyone in particular. So I appreciate the encouragement, and at the same time, I really only have, like, one regular event that I attend. So even if you can only do. It's a little bit like when I was. I studied Sanskrit for many years, long time ago, and I did Saturdays for 1 hour. I went to my tutor's house, and she was this old retired academic who happened to live in my neighborhood. And about a year into it, I was standing in my room, sort of just looking at something, and I realized, oh, my gosh, this is easy. Like, what I just did is easy. And all I ever. She was always berating me for not doing my homework. And I thought, even though I can only do an hour a week, simply doing an hour a week for the last year has added up to something. Compound effect. Yeah. Yeah. And the other thing I want to mention about community that I think it's really important for people to consider is the network effect. A network effect is when you have a group of nodes and the value of that collection, of that set is greater than the sum of its parts. Yep. And so that's when you start to see the magic happen, and you go beyond the stack overflow and you get into, like, a group of people doing something. The output of that will be greater than any individual could have done on their own. That's why we love the human aspect at bytes, right. It's all about relationships. Yeah. That is cool. Blaze, mate, clearly. We could talk all night. I really, really get so much out of every conversation with you. Very inspired. Although it may ruin my productivity, because now I'm sitting here going, maybe I should join this. Maybe I should do that. So, no, I got to stick with my current compounding stuff. But. All right, look, before we break, as we always do, we want to know what you're reading. So why don't you. Are you reading anything? What are you reading? Yeah. Antifragile by Nassim Taleb. It's. It's a dense book, and to be honest, I listened to it first. I had the paper copy, but I listened to it first and I would sort of make notes along the way. It's filled in some gaps that I really needed filled in. It helps me make sense about, particularly working in large organizations that are dysfunctional. He really makes very explicit what's behind that and what to look for. How to become anti fragile is like, beyond resilience. Where you're to be antifragile is to be in a situation where you actually benefit from uncertainty and chaos. And I think that really goes to the root of open source. You don't know where it's going to end and you don't have any way of predicting its path. But what you do know is that it will adapt and enrich and expand. Awesome. Seems also really a relevant book these days with a lot of uncertainty happening. But, yeah, tell Naseem's work is quite dense. So it is a book. You have to kind of slow down your reading speed and really absorb it. Right? Yeah, yeah, maybe I'm going to. I'm looking up audible right now. Maybe it's better as an audiobook for me. I think so. I think so. Because then you can speed through the parts and you can back up, rewind. And, you know, I was fortunate enough to have the paper copy. And so I've got little tabs which I will be converting into Zettelkasten notes. Oh, nice. That's another thing I got out of PDM, was learning how to take smart notes, which is a book I read a few weeks ago. Anyway. Yeah. Having the paper copy is a good companion for the audio. Being a multitasker, it helps me out. Cool. All right, Bob, what about you? How to write? Richard Rhodes. Yeah, yeah. Just always working on the writing skills. Fascinating techniques, stories. And I brought a dutch translation of montaneous essays. But that will take me a year to read. That's just nice to consume snippets of. Yeah, I actually found that funny because Blaze just mentioned that story about the people who were paid to write. Yeah, and you're reading a book on how to write, so that's kind of cool. I'm kidding. I know your book's not about how to write. All right, I'll go next. Yeah, the. So I burnt myself out reading on the plane. On the plane rides. I was. I did not want to pick up another book I was reading on my Kindle, and I was reading the Harvard Business Review magazines that I had in my backpack, and it was all. I realized that what burnt me out was it was all nonfiction, it was all business, it was all mindset, that sort of stuff. And so I came back, and the last thing I want to do was pick up anything. Mindset, motivational, you name it, career related. And so I actually found this week just going back to basics of reading for pure joy. And so I picked up and finished in just four days, the second of the wizard of Earthsea books, the Tombs of Attuan. And I just started today, the third one, which is called the farthest shore. And I'm enjoying that. So good. No, none of this nonfiction stuff for me for a little bit. I need to get back into that zone before I can pick it back up. I didn't think that could happen, but it did. So there you go. Anyway, cool. Done. Well, look, thank you, Bob. And Blaze especially. Look, seriously, mate, it's such a pleasure to chat with you. You just give so much motivation and energy and passion for the things that you work on, and we just love working with you. We obviously loved working with you on PDM, but the fact that you're still here and motivating people, it's just inspirational for us. So we really appreciate you and your time today. So thank you for being here. Yeah, thanks for sharing, and a big, yeah, shout out. And thanks for all you do as well, because that energy and that sharing and discovering new groups, new initiatives, and then bringing that back to the Py Bytes community and PDM, that's been amazing. So thanks for that. Nice. And Blaze, before we go, any. Any parting words, where can people find you anything like that? Yeah, you can find me online. I'm in the pivot slack. I'm actually setting up. I've been really interested in alternatives to the commercial social networks. So another sort of side project of mine is setting up a matrix server for people, primarily people speaking Spanish, but it's open to everyone. So, yeah, I'm I'm on the matrix. Blazepavone@matrix.org. Dot nice. Sweet. Or blaze at gmail. Blaze at gmail. You got that? Gmail. That's amazing. Early in there. That's cool. Damn. When I was younger and I got the Gmail invite to join gmail way back when, I didn't think about that. I didn't think, oh, you should just get your name at Gmail and then julian at Gmail. Could have been me. Oh, well, we were sun microsystem batches, which were in the thousands, right? Those are all respects. Oh, yeah, yeah, yeah. My boss's son was employee. His employee number was 306. And I thought, the first time I heard that, I thought, where were the extra digits? It didn't occur to me that that could even be possible. Wow. That is cool. Laser gmail. Nice. Easy to remember. Yeah. We'll have links to all of this in the show notes. So again, blaze, thank you so much for being here. Bob, pleasure is not, as always. It was a pleasure today, though, and everyone out there listening and watching. Thank you so much. We appreciate you. We love your feedback, and please keep it coming. We'd love to hear more from you about what you want to hear from us and what you like and what you don't like. So we'll be back next week. Thanks, everybody. He finally fired up. You were a bit dry, bro. Man, baby, 2 hours to go to sleep. That's enough to shatter anyone's will. Fair enough. Fair enough. There you go. Thanks, blaze. Amazing chat. Everybody happy? See you guys later. Bye. Thanks. Bye. We hope you enjoyed this episode. To hear more from us, go to pibyte friends. That is pibit es friends, and receive a free gift just for being a friend of the show and to join our thriving slack community of python programmers, go to Pibytes community. That's pibit es forward slash community. We hope to see you there and catch you in the next episode. I got a buddy. I seriously forgot it. Yeah. Okay, here we go.