Django 20 Years Later - Adrian Holovaty

Speaker 1: Hello, welcome to another episode of Django Chat, a podcast on the Django Web Framework. I'm Will Vincent with Carlton Gibson. Hey Carlton.

Speaker 2: Hello, Will.

Speaker 1: And we're very pleased to have Adrian Holivati, who is the creator of Django, appear. Welcome, Adrian.

Speaker 3: Hi, thanks for having me.

Speaker 2: No, thanks for knowing. We've been trying to get you for years. Really excited that you've enjoyed it.

Speaker 3: I finally made the room in my agenda.

Speaker 1: That's right. Well maybe I'll just quickly jump to, so it's been over twenty years since you first created it. What What have you been up to since then, right? I think mainly this SoundSlice project, or what would you like to say about, you know, you what you 're doing?

Speaker 3: Yeah, these days. Well, SoundSlice is my day job. I've been working on it full-time since 2012. It's no longer safe to call it a startup. It's just a business and it's a way for people to practice music. It's used by all sorts of musicians to practice, to teach, to uh transcribe stuff. It's uh basically a web-based interactive sheet music platform with all sorts of stuff attached to it. So that's how I make a living and uh yeah there's there's no end in sight. It's the project that keeps keeps uh sprouting new features and new challenges and super interesting. It's a great combination of my two part two parts of my life, music and computer programming.

Speaker 1: Right. I mean you did call it Django after Django Reinhardt, so it's not a new A new thing. I guess that would be a question which came first, jazz guitar or programming for you?

Speaker 3: Oh interesting. Well it depends on Uh your definition of programming coming into my life, because I did some as a kid just copying uh code from a magazine and putting it into my Commodore 64. I don't know if that really counts. My first big thing was a calculator program for the TI-85 in high school math class. It was called A Math, and it did basically all the formulas and Uh basically by the time I graduated everyone in the advanced math classes had that and I was I became obsessed with making making it more Optimized, adding features, removing bytes.

Speaker 3: Like at some point I find out that the size of the variables influence the size of the ultimate compiled code. So I have renamed every variable to just a single character. And this is I don't know, fifteen or something. So that that was probably my first programming thing and I was a guitar player but not a jazz guitar player, so I guess programming came first.

Speaker 2: Fifteen years old, you've got the memory to like recall what variable A and variable B and variable C what they sort of refer to, right?

Speaker 3: Yeah, I mean couldn't do that anymore. I d I forget if I had it written down or something, but I still have it actually. It's right here in my desk.

Speaker 2: Good. Nothing goes to waste.

Speaker 3: So for those of you watching, boom. Well

Speaker 1: has

Speaker 3: DMath on it. I don't know why why it's so at the ready, but I just have it me on my desk which has all my my accoutrement.

Speaker 2: You can see Python on the latest version of those, right?

Speaker 3: Yeah, I heard that a few years ago. That's awesome. Because this thing was some bastardized version of it was some proprietary Texas instruments. language and I still have the actually the manual on my bookshelf over there. Speaking of weird things that I've kept around for decades.

Speaker 1: Wow. And and yet I think you didn't formally study computer science in college, is that right?

Speaker 3: I did almost.

Speaker 1: Okay.

Speaker 3: So I studied um What did I study? Uh C and uh assembly language. And then there was a web development class that I took that focused on Perl. And so I my original web development programming is with was with CGI and Pearl.

Speaker 1: Yep.

Speaker 3: That must have been 2000 2000, maybe 1999.

Speaker 1: Wow. And then was it 2000 was it 2003 or 2004 when you started on on Django um internally? 'Cause it came out I know it came out or it was released in two thousand five, so it must have been at least two thousand four, but maybe two thousand three when you started working on it.

Speaker 3: I would have to look that up. I don't want to just say one of the days exactly for sure. But yeah, that that's the right ballpark. One of those two years.

Speaker 1: That is kind of wild though, three years after your first web class you switched to Python, which at the time wasn't what it is today. And you're like, yeah, let's let's just let's just do a web framework. Because I guess PHP was the frustration, right? Like that was the kind of the default and you had experience with PHP?

Speaker 3: Yeah, I was using PHP. I I switched from Pearl to PHP at some point. Because that was kind of the the trendy thing at the time.

Speaker 2: It was the new hotness, right?

Speaker 3: It was the new hotness. And yeah, then uh Simon Wilson and I were big fans of this blogger called Mark Pilgrim. And he wrote a lot about Python around that time and actually released a free online book called Dive in the Python. So That influenced us to just try playing around with Python and we really loved it and just started building stuff in it to the credit of our boss who really didn't didn't mind as long as stuff got done. So uh that that's uh something I'm eternally grateful for is that sort of hands-off approach by management. They his his his name was Rob Curley and his famous quote was, I don't care how the sausage gets made, as long as the sausage gets made.

Speaker 1: I mean that's the dream for any programmer, I think.

Speaker 3: Definitely. Yeah.

Speaker 1: Well, Carlton, I have a long list of questions. You jump in here.

Speaker 2: Yeah, well no, I want to ask a a little bit more about um SoundSlice and about the underlying. So it's all all built in Rust, right? No, I mean it's you built with Django on the back end.

Speaker 3: Not Rust. So uh all the backend is in Python and the web stuff is in Django. The most interest well, I I take that back. The front, I was gonna say the most interesting, but I actually don't think that anymore. The the front end is all in JavaScript, of course, because that's the only game in town. And it's the interesting thing about the front end is that it's an entire sheet music rendering engine in JavaScript. So what that means is we take the semantic data like the the pitch C followed by the sit pitch B flat. And we actually turned that into graphics, like you know, the dots and the lines and all that stuff. So that's and it's responsive, so it'll fit. It's dynamically generated for whatever your screen size is because a lot of musicians are using smartphones and tablets these days.

Speaker 3: So that's that's one that was the original interesting bit of the project. Unfortunately not Python because you can't do Python, or at least I guess now these days you technically can with some really weird hacks, but yeah, it's it's all JavaScript. And then on the back end, we do have a new interesting thing, which is sheet music scanning. It's it's the uh basically OCR but for sheet music it's called OMR optical music recognition where you can upload a photo or PDF of sheet music and we'll figure out the semantics of it and reconstruct it so you can hear it, you can edit it. And yeah, you get the, you know, the fungable data. And that's all using our custom machine learning stuff in Python. Uh no Django stuff really.

Speaker 3: Oh I guess there's Django stuff because it's there's like a web interface to it.

Speaker 2: But Django would be just the web layer, right? That the sort of interface layer, the view layer. And then

Speaker 3: exactly. Well, I mean we store data in Postgre and access that with Django models. So I mean it it's it's not just the web stuff that's Django, but Yeah, it's it's our Python behind the scenes.

Speaker 2: Okay, so I've got two questions. The first one um would be like because now 2012 you said you started it, so that's like 13 coming up 14-year-old. project and I guess I wanted to ask you about stability and maintenance 'cause one of you know one of big Django's big selling points, you know, at least in the last eight um five to ten years of its life has been about, you know, the e the stability and the ease of upgrade and, you know, as a as a as someone running a business using it. I mean I wonder what your thoughts there are. Well

Speaker 3: Yeah. Obviously it's been a very happy. I'm happy that it's the Django is stable. I mean I at some point it started doing everything I needed. And that's sort of around the time where I decided, you know, I I don't really want to spend hours of every day on this anymore. Because for me, Django was always about a tool that helps you build cool stuff as opposed to, oh, I'm gonna work on this quote unquote academic project of making the best possible framework. I've always It was always just a a means to an end for me. And it continues to be so. Uh so yeah, I I'm glad it's stable. I uh it's but yeah, again, at some point it started doing everything that I need

Speaker 3: and We you know, we upgrade to new Django versions and occasionally there's something that that we'll we'll find interesting. We being like my colleagues Joseph. an Edward that something that we'll find interesting. But uh yeah, I mean I I was cool with it a long time ago back in twenty twelve.

Speaker 1: That's a good selling point, right? Because I uh you could understand maybe you're like tired of it in a way, right? When having worked on it from the beginning, but

Speaker 3: No, it it's it's great because it just gets out of the way. You don't have to worry about it. You don't have to learn something new every six months like it is if you're on the JavaScript JavaScript uh front-end framework train. Which is another sort of uh passion of mine is not deliberately not using all JavaScript frameworks, no React, no Angular, or whatever the heck the new thing is. Just vanilla JavaScript does the job and is fantastic, frankly. There I have a whole theory on that, which may you may have to say for another podcast episode.

Speaker 2: Oh, I don't know about that. Well we'll have it out of you yet. But can I ask you then, because th in the last couple of years there's been this big um HTMX has jumped onto the scene and there's been this big sort of swing back to the the server render um s uh multiple pages instead of single page applications. I was wondering if you've you know you've you've obviously seen that going through and if you've had thoughts and does that fit your way of thinking or

Speaker 3: I've totally sidestepped all I I sidestepped that entire pendulum swing from Client-side rendered to server-side rendered. I've just always done server-side rendered. It's always been really good, really fast. It's what browsers are optimized to work with. I don't I do not understand why you need a virtual DOM. That is ridiculous. So uh yeah, so I haven't used that the the new thing. Uh but I I feel like I don't need to because the way that we d write JavaScript at SoundSlice is just so dumb and simple, and I mean dumb and as a good thing. There's there's no abstract see the the a big difference between

Speaker 3: front end and back end frameworks is that on the front end you get penalized for abstractions because you get penalized because the user has to download more and you get penalized because the user has to run more logic. On the back end you don't have to worry about that as much. So in the in terms of Django stuff, it's totally fine for there to be abstractions and uh various layers and stuff, but on the front end that To me that does not make sense. And it it's just so much better if you are cl as close to the metal as possible to the extent that we can call JavaScript metal, which Really shouldn't, but you know, remove as much abstraction as possible, basically, is the idea for i for a JavaScript.

Speaker 2: So the last couple of years you've just been like, oh welcome back in, you know, as you s as the boat's come back into the room, you've been you've been the firewall.

Speaker 3: Honestly, I oh I go back and forth. About whether I even care.

Speaker 2: Yeah.

Speaker 3: The nice the uh a huge luxury of having our own business with just three developers is we don't have to worry about the stupid trends. Because I mean one one there's one legitimate reason you would need to worry, which is hiring, because Often it it's easier to hire if if you can target a specific framework and you can, you know, make sure that it it's sort of a way of pre-qualifying potential coworkers. But for us, uh We just don't care. And and I wish more people would do that. And and the philosophical question I have that I've been battling with for years is to what extent should I care about that uh publicly?

Speaker 3: For a while I just sort of was in my own little cocoon and was happy to watch the world burn in terms of using su such stupid JavaScript stuff. But at some point I realize it's actually detrimental to me indirectly because the more these frameworks get used, the s the crappier the web gets. Things get bogged down. pages take forever to load. It's just a crappy experience. And it's because uh to some extent of these JavaScript frameworks, at some point I decided maybe it is worthwhile to Be a little bit more public about why using these JavaScript frameworks is not good. Even if you don't use them yourself, you're affected by them negatively

Speaker 3: because they sort of impact the reputation of the web at large. And if you're building a website, you're indirectly impacted by that.

Speaker 1: So you never felt the need to have iOS or Android apps then, I think goes without saying. Because Carlton, I mean I'll say Carl Carlton has ex I think made his career doing the back end of that. And then you've dabbled a little bit in the front end, right, with various projects recently too.

Speaker 2: Well, mm me, I've been using um HTMX and Alpine and it was when I discovered them because I I you know I used to do some jQuery and a teeny you know a teeny bit of backbone when that first came around. I was like, yeah, this is nice. This is okay. And then for me, the whole world just went mad and I was like, ah, I was busy doing iOS stuff. So I couldn't keep up with you know all the all the JavaScript frameworks. And then um I've been using Elm, which I really enjoyed for the sort of functional nature, and that was that was quite good fun. Um, but then when I found HTMX, I was like, oh yes, because it goes back to doing it in the web. And yeah, you haven't used HTMX per se, but you've been doing the same, you know, the same kind of thing with your yourself by the sounds of it. And it it really go went back to me to like kind of how the web wants to work.

Speaker 2: And it was it fitted Django's pattern so very well because it was, you know, just make a post request, just make a get request, just make a delete request, whatever. It was It was with the grain of the web, which is something I I've always said about Django. Like Django's got a grain, and if you just go with it, it makes life very um simple. It's when you try and fight the grain that it's becomes more difficult.

Speaker 3: Definitely. Yeah. Yeah, I totally agree. Well, so you you wanted to talk about native apps versus the web?

Speaker 1: I was just teasing Carlton because he he spent some time um even on some individual projects. I mean Button, we can say its name, right? You were doing some stuff with with apps. But no, yeah. Now now that you have full full choice with what you're doing, it's like Like you don't need to mess around with that.

Speaker 2: I liked what you were saying, Adrian, about um, you know, just being a small shop with the three of you, you can not care. You can you know, you almost I I make the joke about being hiding up the mountain herding my goats, you know, I'm just I mean But there there's this tension between um, wanting to try the new things, wanting to keep up, wanting to, you know, this go with the state of the art and and develop versus the stability of known you know, known tools that really do do the job. And so rarely for me does a new tool actually improve anything.

Speaker 3: Yeah, I would uh I would maybe push back on the premise of that statement, which is that new equals state of the art. It's not necessarily true.

Speaker 2: No, exactly, exactly. It wasn't I wasn't pr i it's that tendency though. Oh, we must check out this, we must check out that to g otherwise we're getting behind somehow.

Speaker 1: Well, with that said, I did have a question for you, Adrian. So if you had to do a new web framework in Python today, is there any bit of Django that you go, hmm. I might change that. There must be something.

Speaker 3: Yeah, the fact that the settings are global is I think was a bad design decision. I would find a better solution for that. I probably Would have like a settings object instead of just having it in a module, a bunch of global variables within the module. And the whole setting, the Django settings module environment variable is It makes things awkward in certain situations. I would try to find a better way of doing the things that that was supposed to solve. In terms of the nitty-gritty of Uh views, URL patterns, models, templates.

Speaker 3: Views I think are really good. If anything, I would not have created generic views because I think that set a weird, messed up expectation with people that that was a good thing to do. And in fact, I think they're they're not worth the mental complexity whenever you work with them because you have to hold so much in your head, so much more than if you're just doing a writing it out from scratch I often think about uh the you know, the the physical work of being a programmer is so easy compared to anything in the real world compared to being a plumber, electrician, you get to sit at your desk and the the uh extent of your movement is your fingers. So for p program for programmers to be

Speaker 3: uh up in arms about not wanting to type a lot, that argument does not resonate with me. It I would all I would nearly always rather just pay copy and paste some stuff than have abstraction for the sake of abstraction. And I think that's what we had with Django 's generic views. You just have to hold too much in your head. But if you just have all the code written out, it's so much clearer and easier to understand and more maintainable

Speaker 2: So last one

Speaker 3: regret is sorry, go ahead.

Speaker 2: That last one is more maintainable. It's like when you come back to read it and if you if you have written the whole method out by hand, it's really easy to make the the one-time edit. Whereas if you just use the generic views and you've perhaps overridden one class which is a one-line hook and it is oh where does that go and you have to go and look it up. That's That can be taxing.

Speaker 3: Yeah, yeah, yeah. So yeah, that one. Um what else? The I think the template language, there's some fundamental limitations to the template language. Uh I remember emailing with Armin who made Jinja. Uh I was emailing with him years ago and asking, well, what would it take for us to benefit from the ginja optimizations and you know, all the stuff that's better about it and integrate that into Django. And he did s a bunch of research and just decided, you know, there's some fundamental problems, thus uh it can't be done. So I would want to fix those fundamental problems so that we can, you know, benefit from

Speaker 3: uh the ginger approach to things. Uh but otherwise I think we got a lot of things right. And I don't mean that in a tooting our own horn way. I just think like It it's fine, uh yeah, I'm

Speaker 1: It's not a bad not a bad scorecard 20 years on, I'd say.

Speaker 2: Yeah, exactly. What I like about your answer there is all the things you picked are kind of fine detail thing. Like you know, the settings, yeah, okay, it's not yeah, I get it, it's not architecturally fine, but it's not architecturally as good as it can be, but it works. It's not that much of a trouble, you know. You you need to put it somewhere. Um you know, complaints about g the generic views, they're kind of, you know, standard conversation a a Django meetup, that's okay, you know, the we can live with it. Um there's nothing fundamental, right? And as Will says twenty years later, that's that's perhaps why.

Speaker 3: Yeah, but I mean the huge caveat is that uh I and Simon and Jacob and all the original contributors wrote this to fit our way of thinking. So I'm one of the worst people in the world to ask about this because it's, you know, it's inherently my way of thinking. So Uh yeah, so it it's it does. It kind of works the way I think it should.

Speaker 1: If I could extend that. So What was what didn't fit your way of thinking about maybe PHP in particular, right? Like what caused you to say, you know what, I'll do my own version? There must have been some frustration separate from just the language and the approach that the frameworks at the time took.

Speaker 3: Interesting. Well, the the approach with PHP was that the code was littered in the template. And I know you can have some discipline and not do that. But I'm pretty sure that's how we did it is just having dot PHP files that are basically a mixture of HTML and PHP code. And that is really hard to maintain. That's probably one of the biggest things. Yeah, honestly, I don't remember you'd have to interview 2002 Adrian for that one.

Speaker 2: Back in the day that was glorious to a sort of certain period, you know, the first the first few days of a project that was just wonderful. And then

Speaker 1: tried to tail off after a while.

Speaker 3: Yeah, and you know, there's something I like about it, which is it's so accessible to people. You don't have to have a PhD in computer science to just edit a PHP file. It's so easy to deploy, just throw it on a server that has modphp, boom, you're done. There's some advantages for sure.

Speaker 2: Yeah. I mean d to go back to the way you y you think and like you know, I we'll talk about the Jenga book that uh Wills resurrected us last last week that that you wrote is how I learned Django. But one of the things I really liked about the template language was coming from PHP, was the discipline. It forced you know, it had loops, it had conditionals, but it didn't let you just dump your business logic in the template. And you know, often people will come on the forum and they'll they'll be want to, you know, add some much more complicated behavior to the template language. It's always the same old hands going, No, no, no, no, we like it how it is. We like it. Do a template tag. You know, keep it out.

Speaker 3: Yeah, well I mean you can use whatever tempo language you want, obviously.

Speaker 2: But it is it it was about that um way of thinking about it. I think, you know, um reading the the Django book that you and Jacob did was to learn Django, that was like, okay, yeah, this is the way to think about it. Will he are you pick pulled it up?

Speaker 1: Okay, pull it up. Yeah. So it and this ties in I think to a question about just community, but you and Jacob wrote the original Django book, which is now up at Django Book dot com. Um, that obviously helps, I think, to have a free good book on the community, right? This is still an issue. for any any framework is like what's a good free resource to help people out?

Speaker 3: Well back in the day, I remember there was a lot of hesitation from book publishers to write a book about Django because they considered our docs so good. And they thought it wouldn't be a commercially viable idea to have a book because the docs pretty much said it all.

Speaker 1: Hmm.

Speaker 2: I've got a question right there about the because every the Django docs are, you know, objectively very high high standard. But there's often um con complaints or or not complaints. Cla complaints isn't the right word. There's often like a desire for them to say a lot lot more about how to use Django and and strategies and the more kind of discursive um content, which It's interesting whether we have the capacity A to write, B to maintain, whether the docs are the right place for it, or whether books are, you know, books and courses are, you know, the sort of extra resource resource that you need alongside. kind of more s solid reference docs. And what you what you feel about that. Yeah, I

Speaker 3: don't ever

Speaker 2: think it is why isn't the Django book just in the Django docs? Why was it a separate thing?

Speaker 3: Well, I if I remember correctly, a couple of the chapters were taken from the docs and and ed edited for sure and expanded, but I think we even put some back into the docs. Yeah, I I I could see an argument either way. I could see an argument for uh giving a commercial incentive to authors because writing a technical book is so much work for so little money that maybe they deserve the the money they actually can earn from it. Uh but at the same time, if it's an open source project, the docs, you know , sh maybe should include as much information as possible.

Speaker 3: And maybe the biggest limitation is just making sure that they go go out of They don't go out of date. This is something I face with SoundSlice because we have a very extensive help section, hundreds of pages, and it's there comes a point where anytime you make a feature change. You start to groan a little bit because you're like remembering all the documentation pages you need to update. You know the hardest thing is the screenshots

Speaker 2: Yeah, right.

Speaker 3: 'Cause it's easy to edit, but the screenshots, oh that's and sometimes we have animated GIFs with you know showing parts of the UI and you have to redo those. That's why we basically stopped making YouTube videos, because like that goes all out the window once you change anything. Just as an aside, I think videos it's it's so much better to make instructional content in text than in video for Yeah, uh uh with the caveat that there's certain things like when if you actually need to see something like it's some sort of home improvement, obviously it's better to have a video. But in general I think that's something that's chained and changed in the world over the last few decades, not necessarily for the better, is this expectation that you search YouTube first. Like my son, who's fourteen, he

Speaker 3: uh had a task and I asked him to look something up and he just immediately went to YouTube to look it up, even though it's like something that a a single web page would have very easily answered. So anyway, long story short, how why am I even talking about this?

Speaker 1: No, I mean this I mean, I I agree. Like I've written books too, you know, but it's I have a soon-to-be thirteen year old, you know, she doesn't She doesn't use Google at all. Like she just uses LLMs actually.

Speaker 3: No.

Speaker 1: Because I don't let her use YouTube at home. So, you know, some of this has just been negated by the fact that, yeah, LLMs like in the most recent Django survey asking how people found and learned Django. So the docs I think were 79 % and then Tide at 38% was Stack Overflow still, though that will probably decline. YouTube and um AI, meaning like chat GPT. So I would strongly suspect that, you know, everyone just goes to an LLM now. So that that's sort of the thing. Like obviously I'm I'm biased towards text because you can sort of lean in, you can take your time, you're not stuck on someone else's schedule. But Everyone's just like, what's what's the economic incentive for text when you don't even get attribution anymore? You know, so for me and any other

Speaker 1: technical book author, we've all seen since around 2022 when something happened. just traffic sales fall off a cliff. So, you know, I mean and more generally too, if you think about even just the underlying economic basis for the web, you know, what's the point of You know, affiliate leak affiliate links, like, you know, why review 10 great hiking backpacks? You know, it used to be if you ranked you could get traffic and then you could make some affiliate money, but now if the LLM just gobbles it up. There's really no incentive to do that. Though actually one thing I heard interestingly is that um what what do they call is that Google is actually missing out on this because it's sort of has it's sort of um versioning creating a version of the web that then the LLMs are consuming.

Speaker 1: So people are are just take using Google's work semantically labeling the web. And then Google's missing out on that, but I can't say I feel so bad for Google. But they what do they call it? AEO? It's um yeah, it's the LLM-led search thing. I don't know. It's a brave new world. But you know, some some products, you know, for example, Button Down, which is a newsletter built with Django, Justin Duke we've had in the show, who's at DjangoCon US, it's now I think his number two referral is um LLMs. Like if you go into an LLM and say, what, you know, other than Substack, what should I use? Like his service pops up, right? So it's

Speaker 3: Well, I had an experience with that a couple months ago. Yeah, well uh so I mentioned the sound slice sheet music scanner. Uh every day or so I look at the error log just to prevent misuse and see the images that didn't get any good results. And I started to see screenshots of ChatGPT. where they were saying in uh copy and paste this text into SoundSlice into their ASCII tab feature and you'll hear the music played back Problem is we don't have an ASCII tab feature, so ChatGPT was telling people about something that does not actually exist. So we were faced with the question, what do we actually do?

Speaker 3: We're not gonna be able to convince ChatGPT to fix their database. I don't think that's how the nature of these models works. Uh yeah, just that's just not gonna happen. We could put slather our website with notices like, hey, if you're coming to us from ChatGPT and you're expecting this. Ask you tab thing, that does not exist, but that's just really lame. So we ended up just making the feature to meet that demand, which is kind of dumb because ASCII Tab is a very old-fashioned way of notating guitar tablature that Yeah, it's it's super old.

Speaker 1: I remember that from thirty years twenty, thirty years ago. Find a site, print it out, like I had binders of tabs tabs, and there'd be like four or five versions. You're like, oh, is the third one's the good one, the fourth one's the good one? You know, because the books, they had tab books, but they were they're pretty expensive. It'd be like 15, 20 bucks back in the day for 14 songs. And it's like, well, maybe it's in the wrong key, but it's close enough. You know, because the key would always be off too. Like

Speaker 3: Uh yeah. And yeah, there's all sorts of problems with the published tabs. The people who the fans who make their own transcriptions are often much more accurate because they care more than maybe there's a parallel there between open source documentation and the book authors. Um I don't know. Anyway, um

Speaker 1: So you do you have a phrase for this though? Was it was it LLM driven development or something? I think you did you you did a blog post on it.

Speaker 3: I did a blog post that got some attention. And nothing's really happened from it. Although funny funnily enough, the other day I saw another Chat GPT screenshot in our error logs. Or someone said ChatGPT incorrectly said that we support yet another thing called the Chord Pro format, which nope, that is not a thing. I I I just think there's some there's like a fundamental uh problem that our society really is gonna have a huge reckoning with if We're training a whole generation of people to trust this information that is not necessarily true. That is not a good thing

Speaker 1: Well, we're post-truth, right? That was the whole idea is with the web. Now all the answers you want, it turns out we're back to kind of misinformation central. Um oh I wanted to add it's yeah, answer engine optimization, AEO. I was just looking at that. That's the phrase for like Gemini or, you know.

Speaker 3: How do you do that? You how do you insert yourself into their training data?

Speaker 1: I mean, it's sort of like the early days of the web with like hidden text. There's all sorts of hacks that kind of work or I mean, I remember you can And you know, if you got in before the training deadline cut off, you have like a nine month window where like you're ahead 'cause you put in some keywords and someone else didn't. Um I mean it's all All gonna filter out. But um one one thing I wonder about, you mentioned just to circle back to typing in fun in uh function-based views. Um, I don't want to make this all about AI, but one thing I found, I just came from a company on-site visit with engineers uh at PyCharm talking about how we're doing stuff and Using using agents, you don't actually type anything yourself. So even if it gets the right answer on a query, which we'll just put that aside and assume it does.

Speaker 1: Um If you haven't actually typed it yourself, it like sort of that connection to your brain isn't there. So you don't really feel feel the code or the logic or you struggle with it at all. I don't know if you I guess that's a l roundabout way of asking, and I can probably guess, but are you using LLMs at all to help with your code?

Speaker 3: With the code, no. Personally, no.

Speaker 1: And your team too?

Speaker 3: My colleague Edward, who's a designer and and can do some you know, sort of knows enough to be dangerous sort of thing, uh in front and code. He's been using it to make prototypes, and I think it's a really good use case for that. It really has has empowered him to make some prototypes uh you know uh totally on his own as a single person. Uh but Uh would I use AI-generated code in our production code base? No. Definitely not. I have, of course, tried it and there's nearly always subtle bugs.

Speaker 1: Yeah.

Speaker 3: And they run the gamut from outright bugs that any anyone familiar with our code base could tell right away to very subtle things like Yeah, it it technically works, but it's not but it's gonna cause a problem in the future if we add this one feature. Like it's these these kind of things that we all hold in our heads as the developers of products that that the AI doesn't have access to. And and another reason is it's fun writing code. I like holding all that stuff in in my head and reasoning about it. Why would I not want to do that? Why why would I intentionally have less fun? For capitalism reasons? Like to

Speaker 3: to churn out more features and make more money? What like what what's what's the legitimate reason?

Speaker 1: Carlton, you have a thought here. Come on.

Speaker 2: Yeah, no, I mean that that rings true to me. I why do you know I'm gonna be forty eight years old in a month or so and um Like why why am I still at the keyboard rather than why have I not moved somewhere else after twenty years? It's because I love writing software. It's like, you know, crafting stuff out of nothing. And you know, I can type a I can tell I can write I write, you know, specs. I've been one one thing I'm interested in is that people are now suddenly keen to write specs. when for years and years they've oh I couldn't possibly write a requirement stop but now they'll do it so they'll do it for the machine but they'll never have done it for any other reason in the past. But I've always written specs up of what I was trying to do. And so I can paste that into a into whatever and I can get some stuff out and I can look at it and I can not really understand it and eventually I can see why it's not

Speaker 2: as nice as what I might have written. None of that's as enjoyable as just writing the stuff myself. And I don't know. Let's say it makes writing code faster. I'm not convinced it makes writing code faster, but let's say it makes writing code faster. The writing code bit is the least of my job. Like it's it's a fraction of my job. That's not what I'm paid for. That's not what I've made a good living in my my professional life doing. It's not the writing code bit. It's all the rest of it. And Yeah. Why take the fun away? It's like if, you know, I enjoy cooking. Am I gonna go down the supermarket and buy a microwave meal? Absolutely not.

Speaker 3: Or like that soylent stuff. Does that even still exist? You know, a couple of things.

Speaker 1: I I remember I think so. I'm not living in Silicon Valley still, but like I I don't s I think I there's probably still a dedicated culture, but they've moved on to Yeah. Something else. Yeah.

Speaker 2: So let 's swing let's swing let's swing topic the momentarily. I was at uh Django in the Med last week with Jacob. Um well amongst other people, Jacob Walls who's the new um Django fellow. And he's he's um he's a com um composer and he you know, has been into the music world and he was telling me that you're quite involved in the you know the technical specs for encoding music in the It was beyond what I knew about, but it sounded interesting and I wanted to ask you about it.

Speaker 3: Yeah, uh well there's a format For encoding music notation, well there are many, of course, because you know you can argue music notation is the world's most used language if you consider it a language, but there are many ways of encoding it And one of the probably the most used, the most popular these days is called Music XML. So it's As you could guess, it's an XML format where you encode all the notes, all the rests, all the chord diagrams, all the stuff from your score. And that uh is now a W three C community group. Uh it it's made uh maintained by this W3C community group, of which I'm one of the three co-chairs.

Speaker 3: And several years ago, we decided actually my predecessor, this guy Joe Burkwitz uh started a project to create a new format to address some of the fundamental limitations of music XML. Obviously insert XKCD number whatever into another format bumble. Exactly. Uh but I it sounds so stupid to say this, but this one will be better. Uh it's JSON, it it has a more Pythonic approach to things to be very.

Speaker 2: So is it gonna be called music JSON?

Speaker 3: No, it's called MNX, which was not my name. It doesn't stand for anything. It's just a random acronym, Music Notation X, M and X. So I'm in charge of that. have been working on it for years now and it's uh it's really great for I mean on the off chance that anybody listening here is working on any sort of sheet music thing. Definitely check it out and get involved in the development. Fun fact that documentation system is a Django app. Uh I made this app that is very has a very specific task of um creating documentation for

Speaker 3: uh JSON format where you can have examples and it automatically color codes things and links every attribute of the JSON to the appropriate docs page, blah blah blah. That's all open source anyway. So yeah, th this is uh what I do in my free time instead of It's sort of like what replaced Django for me and my open source contributions time.

Speaker 2: But this is the sort of thing that I think you know, it takes an i i an individual group of individuals to craft on over a while and it kind of has really long lasting value because that standard will be finished and then it will be around for you know a long time a lot.

Speaker 3: Yeah. Definitely.

Speaker 2: That's really cool.

Speaker 1: I have I had just one more question. Um and this goes back to Django architecture, which is around local versus deployment. So there's still this kind, you know, when you start a new project, it defaults to local. And then that leap to production. Um I'm wondering if you have any thoughts on maybe making that easier because it is still quite a bit of a leap and everyone does it, you know, when I think about how to put this in a book or to teach it. It just varies so w so much. There isn't even just a simple path and then we go from there. It's like even that simple path you still have to tweak. I don't know, eight, fifteen things. Just curious if you have any thoughts on you know, so there's talk of maybe we have when you start a new project

Speaker 1: Toggle something like local versus production. That's one idea like Jeff Triple has explored. But curious what you think.

Speaker 3: Think it may be inherently complicated.

Speaker 1: Yeah.

Speaker 3: So there might not be an easy solution. And I think we as programmers don't like to consider that option. Uh I'm probably one of the worst people to ask because I j once I set something up for production, it's set in forget it and I can set it up in SoundSlice like more than a decade ago. The other production site I have running, well, my blog, which I did probably around the same time Yeah, I so I personally haven't even faced that in years.

Speaker 1: Yeah.

Speaker 3: So I'm I'm definitely a a bad person to ask about it. Okay. It does seem like there could be some sort of more framework level switch between production and development. But yeah. I don't have much to say. Sorry.

Speaker 1: It it could be explaining that because that is you said it and then you kinda go on. Um Eric Mathis, who's Wrote Python Crash course. He's been working for a while now on this Django simple deploy third-party package that links into some common providers and um is trying to address that. So, you know, mainly from started from his uh pain point as an author of, you know, he would have a different provider each edition every three, four years and, you know, the free tier would go away or they'd change how they do something. And I can certainly relate to that just with having I've switched between Heroku and other and I can't remember Fly. io. Like, you know, you write this book and people kind of are like, hey, this part's broken. You're like, that's not even the Django part. Um I

Speaker 2: I think what's good about Django's simple deploy is that each provider has a plugin and so it's a way it that that plugin then becomes the kind of focus point for people in the community who are You know, if you're using that, you can contribute to this one plugin so that it that's kind of like a shared knowledge bank, if that makes sense. Um

Speaker 3: sounds like a great project.

Speaker 2: Well, yeah it's yeah, it's kinda cool. Uh deployment's one of the perennials, right? The you know, long gone are the days where you could just run, you know, mode Python and it was it was all taken care of.

Speaker 3: You would have thought that it would be solved by now. Not just for Django, but just like sort of for the whole world of web development.

Speaker 2: But maybe it's inherently complicated.

Speaker 1: Well, but or if you look at if you look at other web frameworks that you know that raise VC money, they just have a hosting platform. So like Laravel has a hosting option. Um fast API, right? They raise money. They're gonna do fast cloud, you know, kinda to address this. So Yeah. I did have sorry, I have actually one more last last question, which is you mentioned how you're with SoundSlice, you're using um Django and data pipelines together. I feel like this is the The issue I want to try to get a better story around and at DjangoCon US we're talking about how do what how do we say how Django fits into this AI world? Because people will misunderstand How things fit together. Like there are a lot of people the new generation are Python machine learning engineers, but they're not web engineers.

Speaker 1: And so they think, okay, I just have a fast API endpoint. My work is done, but you know, so I will get a question in others as well, like, hey, I want the Django ORM plus fast API, which I feel like the question sort of misunderstands what's going on. So I'm curious if you have a sense of how Django can market itself better is like, you know, okay, maybe on the inference path you don't want Django, but all this other stuff that you need, Django's there for you, but this new generation doesn't even know to ask, really. That's my take.

Speaker 3: So I have never used Django Rest framework, but I'm gonna bring it up. At the risk of being totally ignorant about it, because like I said, I never used it. I don't understand the point of it What is so difficult about just making a normal Django view that returns some JSON and that like throws the right HTTP status code if you use the wrong like HTT method. I don't understand that. And I I think there's maybe it's a generational thing. that uh people expect their hands to be held to such an extent

Speaker 3: where if something doesn't explicitly have like, oh, this is the thing for writing JSON APIs. that if they if the product doesn't have that, then they're like totally at a loss on how to do it. I think people maybe are scared of going too low level, even though low level is laughably still high level. We're talking Python here and typing two lines instead of one. So I I I guess I I question the premise of the question, if if that makes sense. Uh I maybe it's just a matter of educating these people like yeah, so you're preparing some training data for to train a model? Here's how to use the Django ORM to spit out some database records and create a CSV

Speaker 3: or whatever the format your training data needs. There there's no there there. It's just it it'll be different for whatever machine learning system you use. Like so we have we use like a image classification model, ResNet, it needs the data in a certain format. It's basically like a directory structure. There There's no there there. You just have to know, yeah, put the files in this right in this directory, name them this way. You can use Django to do that. It's just writing code. So Z I I I'm kind of confused, you know? Like wha what's the issue?

Speaker 2: Well no, I mean I okay. So so f from your answer, I think the the point there is peop that the phrase you said is some people won't need that hand told. Maybe it is a a kind of um uh skill level problem. Like people are expecting just to have out of the box solutions for absolutely everything. And it's like, well I don't know. I mean I I guess people uh want out of the on you know the REST API example, people want out-of-the-box solutions for a lot more than just returning JSON responses, I guess. What does REST framework give you? I mean it's got permissions, it's got It's got technology views that help help you out. It's got authentication. It's got um rate limiting as part of it. I guess people want those kind of things which are s

Speaker 2: perhaps more difficult. Andrew Godwin once said to me about the batteries that um Django provides. He he said the battery Django has to provide the hard batteries, the things you couldn't just write yourself Um yeah, okay. Um

Speaker 1: but I think uh you're qualified, Adrian, to say, you know, back in my day we had to write our own web frameworks. So that's part of the Yeah, well

Speaker 3: the thing is that nobody remembers this. Back in the day It was a joke in the Python community that there were too many Python web frameworks. This was before Django was open source. I remember at a PyCon years ago in Washington, DC, there was a keynote speaker who put a Yeah. We talked about this on the last podcast.

Speaker 1: Well that's okay. Not everyone. Yeah, on the the the uh the the talk python twentieth anniversary, yeah, you mentioned this.

Speaker 3: There was a slide Sorry to say it again.

Speaker 2: I was just gonna say if you go to the ASGI um ASGI ref um website, the ASGI. readthedocs. com , which is the the the docs for the ASGI spec, there's and you go to the implementations, there's about you know fifteen or twenty Python web frameworks j that implement Hasgi now. It's like it it's almost back to that old days where the, you know, thousand flowers may bloom.

Speaker 3: Why why did I bring this up? Oh because back in you were saying back in the day you had to write your own web framework.

Speaker 1: Yeah, I was

Speaker 3: you didn't have to. There were so many and we were kind of embarrassed that we added another one to the list.

Speaker 1: Yeah. Well, but you know, you need that combination of self-desire and maybe I don't know if I'd call you say you were naive, but you're just like, yeah, why not? Right? Like

Speaker 3: Definitely. Definitely. I mean, I was twenty -two or twenty-three or something. Simon Simon and I, fun fact, were born five days apart. Um but we're both like twenty tw uh twenty-two or something. Definitely not yeah.

Speaker 2: Still made of rubber

Speaker 1: Well, it is. I mean, this is so a perpetual thing I have, and maybe it's inherent to the ecosystem, is why isn't there a JavaScript batteries included web framework? There's always a new thing. And I like there kind of is, but there really isn't There seems to be for each language there's like you know kind of a Django, right? Like PHP you have Laravel, Symphony, Ruby you have Rails, I guess Java you have Spring. Like it feels like everyone wants to just write everything in JavaScript or they used to. But there have been efforts, but nothing is nothing that I see has any sticking power as like the Yeah, that we're just gonna do it this way in JavaScript.

Speaker 3: Maybe clear you're talking about server-side.

Speaker 1: Yeah, well maybe that's part of the problem. Yeah.

Speaker 3: Yeah. Well, this uh gets to the The idea I alluded to earlier where I said I have a whole theory on JavaScript that JavaScript ecosystem that could be a whole separate podcast episode. I think at some point this is already being erased from history, which is kind of sad. Uh some point it was like fifteen years ago Before JavaScript frameworks really came out, before React, before all the all those things, it was the era of jQuery and uh The reputation of JavaScript front-end developers was these were a bunch of clowns. They started out as HTML people. They're not real programmers.

Speaker 3: They don't know how to do any back-end stuff. There were they ho horrible things are being said about these people. Uh and I th my little pet theory is that That community got a huge chip on its shoulder and it needed to demonstrate, hey, we're real programmers, capital R, capital P. We're real programmers too. Therefore, we're gonna abstract the crap out of everything and make these huge architectures just to show how clever and smart we are. And I think that's what created this generation of frameworks. Why why did I bring that up?

Speaker 1: No, I was asking yeah, I was ask I forget, I asked did you something

Speaker 3: so if you grew up in that environment, you don't have the context. If you're 20 or even 30 now all your professional life you've known JavaScript web demon is using these crazy overengineered frameworks and you don't have a sense of the history and like Why why did that come to be? Not necessarily for good reasons, in my perspective. I'm just one person, but I've been around. I mean I've been a webvel per since the late nineties. So that That that's a whole thing that I wish more people were aware of. The world of JavaScript client-side frameworks. Is not they they didn't necessarily get created to scratch an itch, or they

Speaker 3: the itch that was meant to be scratched was not a great itch.

Speaker 1: Was also a big company itch, right? It was like Facebook size problems, Google size problems. It wasn't Hey, let's let's make it you know, for a small group to do. I think that's a big part of it. You can't say that about all the JavaScript frameworks, but like I mean Carlton, I mentioned this, you know, like Their problems are not your problems. So same thing now, like with uh ChatGPT, right? They're using what Remix now or Next. js, and so a lot of people are doing it, writing blog posts, it gets on Hacker News, and people becoming programmers think that's the way it's done. Right. Like if you go on Hacker News every six months, there's like, oh yeah, Django's still around and it works, but it's not like out there in the same way as cutting edge stuff, which again is not the problem most people are gonna have in their professional life, but they think it is.

Speaker 3: That I mean, we're getting into deeper philosophical takes on the world, but yeah, if you're loud and of attract a lot of attention, unfortunately you get attention. If you're just cool and just doing your own thing and you don't care to toot your own horn Chances you may be you may have the better solution, but just because you don't care to think about marketing, you kinda get screwed. I mean it's all it's a tale as old as time.

Speaker 1: Right. I was just seeing something. It was it was like this, I think it was a Reddit post about like what's the biggest flex. And my favorite comment was, the biggest flex is not caring what other people think.

Speaker 3: Exactly.

Speaker 1: Which is like great. But, you know, yeah.

Speaker 2: There's a genera there's a generational thing here, I think, because we talked about like preferring text to video, we talked to preferred to we talked about learning from typing in magazines and then what was it learning from CopStack Overflow and then these things.

Speaker 1: I guess that's a story.

Speaker 2: This I often think about this long arc of history. I've been using Django for a long, long, long, long time now. And when I see a new framework come up and everyone's like, oh Django's in trouble 'cause we're not like, you know, new hotness. I'm like, hey, take the long view because in couple of years time you hotness will have faded away and we'll still have the same fundamental problems. And what I haven't quite mastered is how to communicate that without sounding just like, get off my lawn, old man, you know.

Speaker 1: Right. We Carlton I feel like we're the two old gut Muppets, you know, up in the balcony a little bit for a number of reasons. You're like, you're like, but you know, there's something to that. Like, were they wrong? Were their takes wrong? Not always. Maybe maybe that should be the opening. I've been meaning to add like an opening uh snippet to the video thing. I'm like, maybe we should just enough so it doesn't violate copyright.

Speaker 2: What what do we have to do to stay open to the youngsters though? Like to, you know, the newcomers in so that we don't just sound like old farts.

Speaker 3: Yeah, that's a question for wiser people than me. I don't know. But the thing is I don't care. Right

Speaker 2: because

Speaker 3: it's good enough for me, you know. Um Yeah it

Speaker 1: 's fair.

Speaker 2: So uh I wanted to swing to just ask you about your music because you've got some albums and you tell us a little bit about you put one out recently, Gypsy Chat.

Speaker 3: Yeah, definitely. I I've uh I've got a full album and I've got an EP. The EP was released this year, album a year and a half ago. It's all my own guitar, instrumental guitar music. So if you like lyrics, this is not for you. It's uh yeah, uh the music that I wanted to see exist, you know, like uh certain combination of melodies and harmonies and instrumentation and aesthetic that I like that I haven't found as much as I would like to find. So It's a matter of being the change you wish to see. Um all the streaming services. And so I can make a chance to

Speaker 3: want to get

Speaker 2: a bot that plays it while the CI is running on your P PR. So you can listen to Adrian play with it. Yeah, I'm always scared if I could be managed.

Speaker 3: It's weird because I don't want to promote the music. It's like well I do and I don't.

Speaker 1: Right. I

Speaker 3: I don't want people to listen to it just 'cause like I'm the Django guy. Like you might not like it. Big deal. Like if it's if it's not for you, it's not for you. But I I like it. You

Speaker 2: like

Speaker 3: new stuff basically every every other evening. I'm always recording songwriting. Arranging.

Speaker 2: So that's kind of like your other part, your third space, your other

Speaker 3: Yeah, yeah. It's so fun. It just to make something uh Make try to make something beautiful.

Speaker 1: Well, as we go out, we've been doing favorite books and stuff, but maybe in your honor we should do favorite Jazz guitarists. I'd like to go first. I'll tell you who I like. Um I'm a big fan of Howard Alden. I think because I saw Sweet and Low Down. I there's that I'm always blowing bubbles song.

Speaker 3: Yeah. Forever blowing bubbles.

Speaker 1: So beautiful. And I was like Who the heck is this? And then I think ten years ago that sent me down the rabbit hole of um all his stuff. And I mean he's one of many, but he's just this beast of a guitarist. And kind of the problem is listening to stuff like that. I don't have to tell you. And then you listen to like a rock solo and it's like it's kind of Different different things.

Speaker 3: It becomes less impressive. That's the curse of getting knowledge about anything, you know?

Speaker 1: Yeah.

Speaker 3: You just realize the your your standards become a lot higher.

Speaker 1: Right. But at the same time, like not every most people don't have that level, so they're fine with whatever Like you know, so my kids now are always in the car, they're like, play some music. And on the one hand it's a little bit like I don't want to, but now I'm like, ooh, I can like slide in, you know. little more mature stuff that I like and see how they do. So um but I'm curious for you. Uh you must have a if you had to pick one, a modern jazz guitarist. It must be someone you listen to and go, wow.

Speaker 3: modern. Well my all-time favorite is Django Reinhard.

Speaker 1: Sure. Yeah.

Speaker 3: He's he is nobody, no guitarist could play as beautifully as he did. Every he could just play one note and it just sounds beautiful. And in modern jazz guitar, the concept of beauty and and just having a lot of yeah, beauty is not that prevalent for some reason. It's more about the note choice. Sorry, we're getting into kind of n uh musician talk. It's more at at some point, this is a whole other thing that I have a rant about. At some point jazz became uh a university subject. I think it happened in the sixties or seventies.

Speaker 3: And then books started to come out. And there's certain things that a book can communicate, and there's certain things that a book cannot communicate. Uh talking about music. A book When it comes to music, a book is really good at communicating the exact notes, so the note choice, the pitches, how long they're played but it can't communicate things like a bend in a note or vibrato. You cannot communicate that in any way other than listening to a recording. So there was a s several generations now of musicians who came up learning in that environment where there's this invisible hand influencing the music that was created that was influencing them to think about it like a what they will learn from a book.

Speaker 3: And this no one plays like Django anymore. But anyway, to rant over just sorry, just another aside. That's why I really love the saxophone as Johnny Hodges. He's like my second favorite musician after Django. But there's like a schism in jazz saxophone. There's like Johnny Hodges school and then there's Charlie Parker's school. Charlie Parker it's all about the note choice, the the um the phrasing, but for Johnny Hodges, it's more about like the beauty. It just sounds so beautiful, the tone. Charlie Park did not care about that. It 's totally different d dichotomy. Anyway Modern.

Speaker 1: Yeah, I can realize are all my wife, they're all super musical and they're old enough now where the lessons, it's not about the notes. It's all about, you know, taste or it's about The things that aren't on the page, because everything's on the page, but how do you get to next levels? You know, they f violate

Speaker 3: at that point. Yeah, they're yeah they're if you're starting out you want to do that but you don't have the technical capabilities so you're kind of like it's frustrating.

Speaker 1: Yeah, but it's hard to Yeah, get that across, right? It's not it's like the first stage is just playing the notes ro more or less in the time to signature, and then it's all about you know, the feeling and and all these things and then that's infinite, but

Speaker 2: It's just like programming.

Speaker 1: Yeah, I was

Speaker 3: Yeah, a lot a lot of uh commonalities for sure. So back to this topic in hand. Uh I would recommend an album by Adrian Mignard and Rocky Grossett called Well it's in French, so I'm gonna butcher it.

Speaker 1: Carl Carlton's been learning. Is it between octaves? Or what is it?

Speaker 3: I think it means b between us? Entre

Speaker 1: new? Huh? I'll edit. We can look it up and sound learned. Oh, between acts? What is what is that in for? Carlton. I don't know.

Speaker 2: I haven't got the album. I haven't got the album.

Speaker 1: Um

Speaker 3: well it's uh really beautiful modern jazz guitar album. It's just a duet to the Oh

Speaker 2: it's in the chat.

Speaker 1: Alright. Well we could keep talking, but we've already hit about it.

Speaker 2: Um, Miles Davis and Kind of Blue and then the um you know that that there was a kind of series of albums. He did uh Birth of the Cool and then Through to Kind of Blue and the the the interplay with him and John Coltrame a giant steps and love stuff. Supreme and that that kind of period there. And it gets later on it all got a bit much for me. I was like, oh I haven't you know I have to I have to have a had a specific mix of narcotics before I listen to the later stuff.

Speaker 1: Yeah, right.

Speaker 2: That particular period was just beautiful. for me.

Speaker 1: All right. We'll put we'll put links to all of that. Um Adrian, thank you for taking the time. This is truly when we started this podcast six years ago. We were like, oh it'd be great to have the creators you amongst them on and now we've now we've had all three so I feel like we can quit Carlton right?

Speaker 2: Yeah we can quit now we can quit we can go and put our feet up on the beach.

Speaker 1: Sidequest side quest over.

Speaker 2: Yeah Well ,

Speaker 1: but thank you for taking the time and thank you for yeah, sharing your your your perspective. I'm I'm personally glad that you're popping your head up a little bit more and Um yeah, I I understand the desire to sort of hide out. Carlton, I talk about this all the time, but I'm glad you're sharing your thoughts.

Speaker 3: Yeah. Well, thanks for giving me a platform to do that. Yeah, it was fun to chat. Thank you.

Speaker 1: All right. And we are DjangoChat. com. We'll see everyone next time. Bye-bye.

Speaker 3: Bye-bye.