Boost Your GitHub DX

Speaker 1: So welcome to another episode of Django Chat, podcast on the Django Web Primer. Carlton Gibson joined as ever by Will Vincent. Hello Will.

Speaker 2: Hey Carlton.

Speaker 1: Hello, Will. And today we've got with us back on the show Adam Johnson. How are you doing, Adam?

Speaker 3: Long time. Good to be with you again. Yeah. Lovely to chat.

Speaker 1: Well, g let's dive right in, because you've got yet another book caught off the press.

Speaker 3: That makes it a a DX uh trilogy, yeah.

Speaker 1: Is it only three? I was thinking it was four now

Speaker 3: already. There's four books, but it's the it's the third in the Boost Your DX series. No, I

Speaker 1: guess beyond just

Speaker 2: Yeah, yeah, this one's just

Speaker 1: before we dive in, what are the titles again? Because the the y you've got the testing one which is so

Speaker 3: speed up your Django tests.

Speaker 1: But that's not a DX

Speaker 3: book. No. There you go.

Speaker 1: Right, okay.

Speaker 3: And then you've got boost your Django DX, boost your Git DX, and now boost your GitHub DX.

Speaker 1: Okay, so you've drawn a distinction there between Git and GitHub.

Speaker 3: Oh yeah, well that's uh Uh interesting, isn't it? So Git is the version control system. It's what we use. It's local software and it can go on our server too. And GitHub is the website that basically popularized Git. They kind of like rose in prominence together. GitHub was you know, some engineers saying, hey, Git is like the next level in version control in like two thousand five ish, around the same time as Django was created. And like it promoted Git and like also promoted like code being out there in the open on a reliable forge You know, previously we had things like SourceForge and Google code that were harder to use. Much harder to do it.

Speaker 1: It was much easier to browse code.

Speaker 3: Yeah. You felt like you're in the code, they put the readme front and center and yeah. But yeah, so you can use GitHub Git with many different Git hosting providers, GitHub, GitLab, now things like Codebug, free open source ones, are are rising in prominence as GitHub is falling in popularity. Um Yeah, so I wrote this book on using Git better and to limit the scope it was all about things you can do locally with the Git command line and related tools. And there was always like this idea of, oh, I could write a chapter on some of these cool tricks I know on GitHub. But by the time you start listing out all of these things and doing a bit of research, you're like that's not a chapter, that's a book. Right. So you know, it was deferred until, you know, I finished off this book last year, between February and November.

Speaker 1: Okay. Brilliant.

Speaker 2: And I think it's fair to say, even though it is a book on GitHub, you can use a lot of these um techniques and things that you talk about on GitLab. I mean not directly one-to-one, but it's basically any hosted CI tool or s uh Git tool because increasingly they're adding things like the equivalent of GitHub actions and they're trying to Not let you not have you have to do everything yourself locally or in your own production setup. You can just offload test runners and these types of things, right? Is that fair to say?

Speaker 3: Uh, it is like I definitely think even if GitHub like uh like you know, falls out of favor with the general community Um there'll be a lot of things to take forward from that, whether that's like these are the cool features, and I think you know other platforms should implement them or um these are the things that like still map into GitLab or whatever. Then yeah, I think there's something for everyone in there.

Speaker 1: Okay. I mean let's let's dive in there because you've talked you've mentioned it twice, the the sort of falling popularity of GitHub. And I And yet I feel that 'cause I I there's a lot of new features that I just don't want and I there's also kind of a monoculture thing and you know, it it there is a risk of having everything all in the same place. But I don't think GitHub's going anywhere anytime soon, is it, right?

Speaker 3: I don't think so. There have been some prominent projects like Zig which moved off because of uh I think primarily all of these AI contributions and definitely at least on Mastodon as a developer community there's a lot of ranting about the next co-pilot button or the slop piers that are coming through.

Speaker 1: Mastodon is a parti I mean, I'm on Mastodon, I like Mastodon, I don't go on the other ones, but it is a particular community, right? It is more to the ex The hardcore.

Speaker 2: I think finally the the um The news has gotten out that maybe X, Twitter, isn't the best platform, which I was interested to see was not as much the case in Europe as America, but It the only social that matters honestly is LinkedIn at this point until they completely muck it up. So so I enjoy Mastodon Fastodon for hanging out with friends, but in terms of like reaching, you know, blue sky is not it. I think it's LinkedIn for the for now and then something else.

Speaker 3: before the takeover. Um now the only one that compares in that kind of scale is LinkedIn. Yeah.

Speaker 2: Yeah. But all right, but let's let's plug the book. All right. Let's talk about why you what what are some of the key we you know, we want people to read the book. What what w what are some of the top features that you can learn in the book? for um someone who is using GitHub.

Speaker 3: Yeah, so it's structured a bit like a r a run through of GitHub, pointing out things in a UI. uh that you might have missed as well as command line commands. So there's the GitHub CLI that I've leaned more and more into as it's become powerful and capable and Uh you know, now I can do uh pull requests and a few letters on my command line. And I think that's that's pretty powerful.

Speaker 1: I've always been a bit skeptical about the GH command up. Uh-huh. Well no, but okay, but that that's me down to a nutshell, right? Why would I use a new tool when the tool I've got will will do it perfectly happily? But you know, there was a few things like um I don't know, fetch a PR, check out a PR for which I had an alias and things. You know, when the the the g G H command came out, um I already had those, so why would I you know why would I change it when you're not gonna be able to do that?

Speaker 2: But you're not everyone, Carlton, right? This is the problem.

Speaker 1: No, I understand I'm not everyone, but this is what I'm asking Adam, 'cause he's you know, much more open to experimenting with new things than I am. But I think it's grown quite a lot of capacities over the years. It's quite fully featured now, right?

Speaker 3: Yeah, nearly every like daily button on the UI has a equivalent um command. And some of them are quite flexible as well, like creating a pull request, it has like four different modes. So you can either like provide all the details in one long command, or if you run it without any arguments, it will prompt you, or you can get it to open an editor where you type it in your favorite editor. Um So yeah, it's pretty pretty nifty piece of kit and woefully underused, I would say, uh, from what I see from people developing like GitHub is normally that that website you learn how to clone, you learn how to make up a request, you learn how to bug your coworkers on Slack for reviews, and then like You you start focusing on the codes.

Speaker 2: So are you are you using it more in a command line capacity then? Is that the sense I'm getting?

Speaker 3: Um

Speaker 2: yeah.

Speaker 3: Yeah, definitely more and more, and especially writing the book like made me look at some of those corners I hadn't investigated

Speaker 2: Well this is your I've sorry, I forget the tagline, right? Your di Oh, was it your development led through books, right? Where you always end up c you contributed to Git when you wrote the Git book and what's your phrase for that? I'm sorry, I'm forgetting.

Speaker 3: Book-driven development, yeah.

Speaker 2: There you go. Yes. Yeah. I haven't quite I 've got to do it.

Speaker 3: A little bit of BDD here. I got uh a few pull requests into the GitHub docs fixing in the PC. I did look at the CLI, but everything I wanted was there. Um yeah.

Speaker 2: But so the main idea though is uh sorry, I'll just go Carlton. Um of course I will. The main point of I mean of this book with DX and your other ones is People developers can save time using these techniques and tools that they probably either d don't know about or don't know how to get the most out of, right? And that's fair to say, right? Because someone, you know, why read the book? Like there's lots of ways they could speed up their development workflows with GitHub. That they're just not doing if they're just clicking on the website and bugging people through Slack, right?

Speaker 3: Yeah, that's that's the basic thesis of the of these books is like There's some, you know, low-hanging fruit for nearly everyone out there. And it's hard to discover this through like the usual mechanisms of like just using the product. or like reading the docs. Nobody really reads the docs top to bottom, especially for like a web UI like GitHub.

Speaker 2: Or even an open source project like Neapolitan. We had a previous we had Vel Velda on um right before you who was talking about using Neapolitan for client work and um admitted to not directly reading the docs. So

Speaker 1: why would I read those?

Speaker 2: Well but intuitive I I do think at a meta level the get and get like what's gonna remain if AI truly takes over? Like you're still gonna need get you're still gonna need a way to look at compare pull requests. Like I think the the UX of AI is yeah, whatever it is, like you need like a bomb way to look at different Git and pull requests. Yeah. That's the one thing I'm like, that's gonna stay.

Speaker 3: Yeah, that's a key thesis here. It's like my book is about the fundamentals. It's about knowing them, you know, inside out, hopefully something. that applies it, especially as you become more senior or use more and more code generators. Um you just it's best to know them and know all the keyboard shortcuts, the the little secret tools on GitHub that will help you navigate quicker Um

Speaker 1: I think it's true of all like all your books is that if you If you're an experienced developer, you may know, say, 60% or 70% of whatever, but the what the things you pick up will be like, oh that gold dust. You know, the one or two things you pick up. They're worth it in and of themselves. If you're not a senior developer, you're gonna learn an awful lot. Like just, you know, every chapter, bam, bam, bam, bam, bam. And if you did If you don't have something like this resource, you'll just sort of do the same thing over and over again. This is the pattern I'm in. This I so I push my code, I open the web UI, I fill in my, you know, there's just a routine that you'll go into. without ever opening the box for what's more. And that's what I like about the whole series, to be honest. I think there, you know, I I remember um

Speaker 1: Tim Schilling asked me if I had any tips for people to up their developer skills. I'm like, get Adam's book, just go and buy Adam's book. Just go and buy the step because you know that's an investment in your career. I noticed you talked about g um markdown and writing.

Speaker 3: Yes.

Speaker 1: Go on, that's the system.

Speaker 2: Is there a question is there a question in there?

Speaker 3: Kind of a a sneaky almost Trojan horse right in the middle of the book, like you're learning about how clicking around GitHub and then suddenly you're learning how to write better um through first the GitHub markdown syntax and then like just specifically rules for writing on GitHub. Um I think that's very important. I think you know, even more important in the age of like being able to spew out pages of of text, it's It's better to know what good writing looks like. Um LLMs can write a lot and it can be cogent, but it can be yeah, almost like low information or zero information. There's a lot of these tools that summarize your PR, but all they're doing is like echoing back what the code changes are. And I know what the code changes are because I can read them. I can read the code. It's I don't know who that's for really.

Speaker 3: Uh

Speaker 1: it's like the comment where it's like, you know, um op open the file and then you know, file equals open sort of things.

Speaker 2: Well but I think this is

Speaker 3: Oh yeah.

Speaker 2: Sorry sorry for the slight lag. I was just gonna say I think one of the themes that I would say out of this season of the podcast has come up with, you know, because AI comes up in all capacities, is more than ever you need you need books, you need primary resources from people you can trust. Because an LLM will give you the average of whatever it trained on. But it won't give you, you know, Adam Johnson telling you how to do something. It won't give you Carlton Gibson. It won't give you like whatever canonical book on systems design Like it will only ever give you at best okay stuff. And so I think just for myself too, more than ever, like you gotta know the basics and you gotta go to experts. And they're still out there. Yeah.

Speaker 3: Yes, thankfully. Yeah, just as a as a like um a good baseline, like Django's own Git commit history, the tickets, the docs, that are all like examples of of fantastic technical writing and once you get perhaps into Django or read a few commits as well as the docs, you might realise that, you know spoiled there compared to most commercial projects you work on where the commit messages are all over the place or they're just the letter A or the word update. You're like, why did you do this? We don't know.

Speaker 1: Fix it. Oops. Yeah.

Speaker 3: Yes.

Speaker 1: I think that's something that's, you know When you contribute to open source, you do get to see kind of best practices in a way that's much better than the median team is doing. You know, you think, oh, it's just running black. Well a lot of teams aren't running black or, you know, whatever formatter they're using. Oh, it's it's just, you know doing some docs. A lot of teams aren't doing docs. Like it's you think that these are in like the minimum bar. They're not, they're much beyond the minimum bar. So if you you know, contributing to an open source project and learning these tact these these techniques. When you go to an interview and say, hey, do you know what I do this, I do that, I do that, you stand out as a a good candidate. So it's a it's another reason to be interested in these techniques, I think.

Speaker 3: Absolutely.

Speaker 2: I mean, I'll just say I find that people who learning how to code based on you know my books, Adam's books, and and other things, and then they em Sometimes when they email me, there's a real sh shock at seeing what production code looks like for a junior developer. Again, 'cause they're just used to classroom stuff, open source, curated books and Um you know, production code is always one one tweak away from being broken. That's the business imperative, right? It's very rare to have a chance to actually Do good code for the sake of good code.

Speaker 1: That seems like a segue into your p uh your day to day, Adam. Like

Speaker 3: Yeah. Yeah, well I was just gonna say like it's uh it's a common thing for companies to do a quality week or uh you know, a a sprint to improve their code base. It's like well what are you doing the rest of the time?

Speaker 2: Well yeah.

Speaker 3: You're making it work. Maybe not making it better.

Speaker 1: So we talked about um LLMs and um you know you've been using them a bit yourself, Adam. How's how's your experience?

Speaker 3: Um yeah, it's a bit mixed. Um I've been trying to think like how how much more productive do I really feel with an LM. I was making a list of things that I think that were almost on par, which are like having a clipboard history manager, I think that's just almost as useful as an LLM sometimes. Um and like just generally copying. Like if I'm gonna start a new open source project, I'm gonna copy one of my previous ones. I'm not gonna, you know, ask Clawed to start from scratch in a blank directory. Like there's so much embedded knowledge in in my code already. Um So yeah, that's tools like like that are more deterministic too, like linters and formatters, the kind of stuff in my Django DX book, which does admittedly need updating for the world of Rough, but um I think those are almost on par, so like

Speaker 3: maybe LLMs are like a good boost, but they're not they're not like as revolutionary as people are are saying. I think I'm in the middle of the pack. My recent project uh this ICU for Pi, which we can talk about more later. That's in C<unk>. And before having access to an LLM, that could help me generate the C<unk> binding between the C plus la plus library and C Python API. I might not have taken that on. But then on the same side, like once I started doing it and I realized I was fixing loads of errors and like looking up APIs and finding that they were deprecated and I had to tell it to d use the real one. It's like maybe I just had the power in myself all along and I just wasn't as daring.

Speaker 1: Power of the blank py the the scare of the blank page though, maybe

Speaker 3: Exactly. Like there's something so I can start fixing it, editing it. Yeah.

Speaker 2: I do think that for like LLMs to me that where they shine, well two areas. One is just obscure bug stuff that maybe you wouldn't find it quickly on your own. But the other is for someone who's not at you know Adam, Urra, or Carlton's level, someone who doesn't know where to look So we've had, you know, for example, we had Farhan on who's very accomplished, but more earlier in his career, and like an LLM can help point you to, oh, maybe It'll suggest things, but then it's on you to go in and research them for yourself. So it can uncover the map of programming tools and techniques that you know you might not know on your own. So I think they're useful for that. But if you already have twenty years experience, you know, you might it might be more like you just need to be bold as you say.

Speaker 1: As well, I like you might know, you know, you might be an expert over here, but you know, if you want to work over here, there's Yeah, you don't know all the libraries and all the interfaces and all the the whatnots and you know they can give you a good first first method.

Speaker 2: Forever rely on them to do stuff, I would say.

Speaker 1: I'm curious about these um these people that ha have this policy of not inspecting the code that's generated. I'm I'm like I can't I couldn't I just couldn't

Speaker 3: Yeah.

Speaker 1: Like the the the rubbish that is generated. Like it's fine, you know, it c can work and it it's useful stuff maybe, but it's not good. And I kind of think, okay, you might get something working, but how are you going to maintain it in you know, in times to come if you've haven't really tightened every screw on it. I'm I'm still not quite there on just letting them run and I d

Speaker 3: I don't feel comfortable there th either. The what is it, the MOAT book, the AI social network. They uh they had just the open database of everyone's API key. And uh the security researcher who submitted to them, Hey, I I found this is like Well I'm gonna fix it, but I'm gonna vibe code that fix too, so I'm not gonna look at the fixed code either. So it's fixed. Now the AI says it's fixed. It's like, okay, is it really? Like

Speaker 2: But I mean I I I think part of the problem I mean like you know, so anthropic, right? Claude Code, they still have they have something like three hundred open positions to pay developers, you know, five hundred thousand dollars, right? Even as they say that no one actually writes code, they're still hiring a ton of You know, I think the problem is the people talking about this are generally the f the people making the models. So th at you know, because there's parts of Anthropic that put out papers saying, you know, developers get dumber. or like pointing out limitations, right? Like the problem is no one else is speaking or promoting outside of people pushing the models, right? So they're not gonna, you know like Apple did a really great paper what two years ago pointing out just like inherent limitations to the LLM architecture. before they did their deal with Gemini. Um so I don't know. I think I always have to think like what are the part of the problem is the only thing you see on Reddit or Hacker News is generally hype

Speaker 2: coming from these companies. And so it clouds yeah. In practice most I think almost everyone has some sort of nuanced idea. I mean, I don't know. Some people are I don't know. Some people who are all on agents, I still think, yeah, I can't help but be suspicious as much as I want to be open-minded about it. I'm like, really? Really?

Speaker 1: One thing I'm worried about, which is slightly meta, is um there seems to be a big divide in the community. There seems to be a a big cleave between people who are very pro, very anti, and the the a la a breakdown of the community there in that, you know, if we as soon as we become tribal, it it becomes difficult to

Speaker 3: Yeah. And what's acceptable to send as a pull request, for example, to Django? Like is it okay to open a hundred things that your AI agent found?

Speaker 1: Yeah. No I mean

Speaker 3: not really.

Speaker 1: I'm really struggling at the moment in that that you know it i i it's always been hard to keep the balance between contribu you know, four kids, full-time job. open sourcing on the side, it's it's difficult to find that time. And the the increase in just really low quality noise is I'm finding that problematic. I wonder if you I mean you maintain so many ad problem uh projects, Adam, so uh how's it going for you?

Speaker 3: I feel like I've been lucky, like very few things so far. Um I've had a security report the other day that maybe the person doesn't speak much English but in general like, you know the it's it's it's replying as if it was replying to a person. It's a it's chat it's definitely ChatGPT or something that I was sent. And like the underlying issue is somewhat legitimate, but is Is this a great way to receive it? You know, two pages of text that are like uh out of a chat prompt? Not really.

Speaker 1: No. I mean and as well, like if it's some if it's like somebody who doesn't speak English, to use a a a a machine tool to aid communication, that seems like a positive but

Speaker 2: Well if I can go I don't want to skip over the ICU for Pi. Like could could you talk a little bit more about so Rippling is one of the clients you work with.

Speaker 3: Yes.

Speaker 2: Can you talk about you know who they are, what they're doing, and you know why you had to develop?

Speaker 3: Sure. So yeah, I'm I'm I work as a a Django consultant at Billet. So part of the time writing the book, writing the blogs, part of the time I'm on client work. Most of the time my clients have found from me through my blog. And in the case of Rippling, that's true, because I wrote a post a few years ago about improving your startup time in Django.

Speaker 2: Yeah.

Speaker 3: Um

Speaker 2: I remember that.

Speaker 3: My primary mandate at Rippling is make things faster. Uh so I'm writing the profiler, cutting things out of the tests, cutting things out of their base libraries, some of which are forks of open source ones. But in the case of this library ICU for Pi, that was creating a brand new capability for them and the Python ecosystem, as it turns out. So in Django, we do translations with get text. Um this is a GNU project, I believe, that um you know can gather your strings and you can write translator versions of those strings. I uh the Unicode consortium has this library ICU, which also has a competing kind of translation standard. It's the one that's made into JavaScript, for example. It's part of the IN

Speaker 3: INTL I think framework in the browser. So that is a is a different format of messages. It can express more complex things like pluralization rules between languages change. So like there's no plurals in uh Chinese and Korean, for example. There's more many plurals in uh German, Greek, for example. So It's a mini programming language in your translation strings. And then I wanted to expose that um to Rippling. They support uh hundreds of countries around the world and they want their translations to be perfect for all of them. They were looking for a library to use ICU and the existing ones, they're all hard to install and it's basically at the ground level because ICU is a C

Speaker 3: library. C plus plus libraries need to be compiled exactly on the right platform with the right c architecture. And you know It it turns out that if you install one of these libraries, uh, those Python ones, they're gonna compile from scratch on install every time. They can't build wheels right now. because they don't ship ICU. So it kind of looped into like a whole project of like baking ICU into each i into the Python wheels for each platform architecture. So is it's ended up as two repos, one to build ICU itself and one to build the Python library on top. Um

Speaker 1: You get your your veteran's medal for Python packaging the hardware, right?

Speaker 3: Yeah. Lots of uh like build architecture and a little bit of code on top, yeah.

Speaker 2: But that's that's fun to do, right? It's fun to do something new, right? Rather than

Speaker 3: Definitely

Speaker 2: in addition to everything else.

Speaker 1: Is that something we'll we might pick not you know, obviously we're never gonna do anything quickly, but is that something we might pick up in the Django ecosystem?

Speaker 3: Yeah, I've I've been considering this. Um Rippling use Django and that's why they're interested. But they aren't using, say, Django templates um because everything's an API for them. So it wouldn't make much sense to build like a specific Django integration for them, but I think it could be useful, like maybe a a template tag library to begin with. Um maybe, you know, um a management command like the existing one, compile messages. You might want something else to extract your strings for translation. So it's a bit early days there, Ripley have yet to deploy it to production. Okay, we'll see.

Speaker 1: Okay.

Speaker 2: I have stuff I'm just trying not to speak over you, Carl.

Speaker 1: No, no, no. I the question I came I wanted to ask you is about um so performance. Um and in the news recently it was about uh lazy imports being coming in to Python. I wonder, you know, if you've got that's gonna make quite a big difference, I would imagine.

Speaker 3: Yes, that would make a huge difference, especially for Rippling, whose uh startup time has, you know, ticked up over the years from 30 seconds plus. Um But it's also a matter of that's coming in Python 315 And you know, you've got to upgrade all the versions in between. Those are months long projects for for a big client. Um looking forward to it. But that's like, you know Three, four years time kind of thing.

Speaker 1: Oh right. Okay. So that far. Yeah, yeah. So the other work you've been doing is on profiling and the you've got the the Tprof project. So tell us about it, because my fav my absolutely favorite chapter of your testing book was the one about profiling.

Speaker 3: Oh yeah. Yeah. Tprof has w was like naturally arisen from my attempts to optimize rippling other projects and Django itself. Um There was even one Django ticket that like made things click for me. Whereas like we're uh Jake Howard optimized um Part of the template tag setup. So let's like it moved it moved a slightly expensive function call from every template compile up to one time when the template package is imported. And it's like, okay, you know, there's a small reduction here, but it's very hard to measure with a traditional profiler because you profile the whole program and then you try and find that slice out of it. And then the noise kind of adds up from profiling everything. So Tprof lets you

Speaker 3: it's a targeted profile. I came up with that name. You target which function to profile. So you could say that's the only function I care about or these are the only functions I care.

Speaker 1: A three night a three a three drink naming session.

Speaker 3: It it hooks in through the Python sys monitoring API as to when that function gets called, it tracks it in nanoseconds, it reports like a little chart using uh the rich library for a nice table at the end.

Speaker 1: Anything using rich we're gonna s support.

Speaker 3: Yeah.

Speaker 1: That's

Speaker 3: standard.

Speaker 2: Okay. Well if if I may, uh I'm curious um because you set it in at an interesting position, Adam, because obviously Django background, but also doing work not just in Python. Um, like what do you make of fast API these days? Because for me, like when I go to conferences for PyCharm and stuff, you know, all the usual metrics show that fast API has eclipsed Django, which is a little bit of the Flask Django thing we're familiar with. But are you seeing examples where it does make sense in client work over Django? Or Or yeah, what do you make of it?

Speaker 3: I don't know. I don't really think about it. Um I'm hired to work on Django stuff and it's it's it's always like Well we're not going to change it out of Django.

Speaker 2: Okay, because they already have they are I guess they already have a Django setup, so they're not just

Speaker 3: generally established projects, yeah. Um

Speaker 2: Well let me change that slightly then Oh sorry, I like with asynchronous in general, like because Django obviously is improving that story. Have you found actual production uses for uses for uh async capabilities in Django?

Speaker 3: A few, yeah. Like um background async. WebSocket stuff. Um, yeah, I had one client that was connecting via WebSocket to thousands of electric vehicle chargers a few years ago. So that's when I really dug into channels. Um channel.

Speaker 1: Yeah, I think people jump to async for because it's like cool, basically. It's like, oh, it sounds good. It unless you need a long living long lived connection, you almost have no business dealing with it. And then once you have once you need a long lived connection, then okay, let's talk about async. And then Okay, your deployment policy and you know, and move things slowly. But people are like, oh, we must replace the IRM and with a fully async but the database connections, they might have async Python wrappers, but they're still serialized um over the actual wire to the database. So uh it's not async in you're not getting massive mm concurrency in your throughput for with your connection to the database. So you're still blocked in exactly the same prices as you always were.

Speaker 1: And it's it's that communication message about that async isn't an end in itself. It's a it's a specific tool to use for specific cases. Um And I th

Speaker 3: I think

Speaker 1: go on there. Go on.

Speaker 3: I think there's this um this kind of surface level learning when you're like, what's the difference between sync and async? And like async means that one process can do multiple things at once. And like that that appeals, right? That's like I learned something more about how computers work. Now I know async fast, sync slow, and you don't realize that like the kernel was already doing the swapping of processes for for for free before. So

Speaker 1: Do you think the kernel is better at um uh swapping between active threads? Or you uh is it more likely that the kernel's good at swapping between active threads? or that you're you got every await in the right place and didn't make a blocking function call somewhere without really realizing it.

Speaker 3: Exactly.

Speaker 1: Like I'd rather trust the kernel, you know, ninety-nine and a half times out of.

Speaker 3: Yeah. And Python code like often doesn't isolate between threads or between async tasks properly. There's so much global states that like you know, uh a big client like Rippling, it's almost impossible for them to turn on threading, let alone like async workers, because it's just sitting everywhere. You know, there's one odd call to change a logger logger's level temporarily. Oh, that's global. So suddenly every other thing in that process will stop logging whilst this viewers access, for example. Flushing that out is almost impossible.

Speaker 1: Yeah, and you just mentioned threading, so the the real threading, the the free threading, which I my mouth just refuses to m go between the F and the T H there. The what are your thoughts there? Because in theory, that's gonna do Django a lot of good, right? If we 'cause we have a kind of threaded model and it would be nice to be able to do that. We currently we we've spin up multiple worker processes to get round the gill. But Real threading should help us in theory.

Speaker 3: Yeah, lots of bits of Django are are are thread safe already. Like when you access a database connection, that's thread local, right? So Fingers crossed, you know, free threading plus Django is is uh becomes a a sensible deployment strategy. But as I say, it's hard to guarantee you aren't leaking state between threads because there's so much global state in in Python.

Speaker 1: And it's still a while out, right? We're still on, you know, three three twelve being the minimum supported version.

Speaker 3: Yeah.

Speaker 1: It takes a while for these new versions to come through. Okay, good.

Speaker 2: Um are you uh able to attend DjangoCon Europe this year, Adam?

Speaker 3: Yeah, I should be there. Yeah. Looking forward to it.

Speaker 2: Looking forward to the keynotes?

Speaker 3: Uh yeah. Yeah, I think that's a good thing. Is that you plugging yourself? No, not me.

Speaker 2: Not me. Well that's is it a very indirect way of uh Getting at a typing question, but Carlton's giving a a keynote there and maybe an announcing something.

Speaker 1: Oh cooling. On you I'll be giving I'll give be giving a talk on um it's called uh Static Islands Dynamic C. It's about you know the the relation between what where we want to use static typing and Python's dynamic tool and Django's dynamic tool. I mean Django was specifically by design to be a dynamic web framework. And it's very difficult then for us to bolt on or enforce static typing because it just wasn't built with the right patterns in play Um and so I'm gonna talk about that.

Speaker 3: Exciting. Exciting. I love it.

Speaker 1: Hopefully. We'll see.

Speaker 2: Well, I appreciate it because I feel like there's a lot of momentum towards making it all static and turning Python into something else. So If I may, Carlton, I think you're pushing back a little bit and showing maybe an in-between approach.

Speaker 1: I mean y you know, if if if sta if if we're in a place where oh it has to be static and dynamics only for toy projects, then we're using the wrong programming language basically. We should be using, you know, Rust Or wherever where you've got an actual compiler that does actually enforcing other types and that actually guides you as you're writing your code in a way that Python's type checking, type pints, optional typing, static typing won't ever do. You know, not only do you get the better compiler with something like Rust, you don't get the performance penalties of having to do the checks for the dynamic lookups at every operation. The reason why Python's slow is because it's dynamic by nature. So if we're not gonna lean into it that dynamic nature, at least sometimes, there really is a question as to why we you know

Speaker 1: why we're using Python at all. Um and so yeah, I put I I I want to push back on um this idea that um this vibe that actually static Python is the is the new um ideal. Yes, there are cases where it's important and yes there are cases where it can help, especially large teams, it can be it can be useful to add a a an extra layer of things. security, but okay.

Speaker 3: Well TY for that.

Speaker 2: Yeah, yeah. On the on the PyCharm team, like PyCharm has long had its own type checker and now there's TY and many others, and so there's a question of which one do we use? How do we implement it? But um certainly anything from Astral is pretty strong. Candidate

Speaker 1: as a detail these days. I think like all these things with you know, you have this pendulum effect, so we swing too far. I think there is a certain um vibe that you know, dynamic code should be askewed at all costs now. Um and that's wrong. Um anyway, wait for the talk.

Speaker 2: Yes. Sorry, Carlton. I'm excited on your behalf, but I know I'm giving away. Um I did want to mention Adam, I'm I'm really impressed that you, you know, just because from running the Django news newsletter and Like seeing how prolific you still are because, you know, you're still writing very regularly on your blog, you're still I just very impressed. You still still seem to have your both the passion and also the time to to do new things, right? To talk about new packages, to talk about Django things, to really dive in there. Um I'm impressed by that balance. And I'm I'm glad you're doing it too. I think sometimes people come in and have a burst and then, you know, job or other things uh get in the way and they sort you know, sort of die out. But

Speaker 3: Yeah. I've kind of made it m work where clients understand that if if they're hiring me, I might go write a blog post, I might go make a package for them. And yeah, you know, with the ICU for pi, for example. Initially it looked like that might be something just internal to rippling, like we're calling one function through C<unk>. How hard could it be? Uh does that it's really hard to actually, you know, go build ICU and stuff. So why why not do it in the open and actually be easier for me too? Because I I can just run it on my own GitHub account, no need for you to give me loads of permissions to All kinds of stuff. I can just I can get out crack on with it. So yeah.

Speaker 1: But it sort of feeds the ecosystem as well, right?

Speaker 3: Exactly.

Speaker 1: There's this whole cathedral versus the bizarre thing. If you can put your package out there then Even if you only get a few contributors, those contributors are essentially um collectivizing the maintenance cost of that package. And they'll find bugs that you didn't find.

Speaker 2: Well, but I didn't I did want to ask um you're s you're still on the security team. You've you've had many positions in Django over the years, um, but you're still on the security team. How's uh anyway Quick updates on how that's going these days?

Speaker 3: Just about managing to sort of read my share of the issues and contribute back. Uh that's definitely like lower priority with uh

Speaker 2: Yeah. Well I mean there's multiple members of the team, but I know it's it's sort of hidden hidden hidden work, so I always want to like give it a little bit of sunshine on the podcast.

Speaker 3: It's fun, it's shared, and you know I also I don't worry about reaching out to the security team when I have questions in my own projects. I think it's very nice to have this kind of s private community channel that's still like people I trust to take a look at some code. Um yeah, very reassuring that You know, without this, would Django be secure in the age where it's so much easier to find these vulnerabilities, like people using AI tools. There's a lot of slot, but there's also People grabbing lots of high profile issues on these projects.

Speaker 1: We should link in the show notes to Jacob Wells put a um a post up on the Jenga blog recently about uh the recent work in the security team because um I think they found um quite a lot of the level of reports rising with the with the new tooling available. I think people are um taking existing reports and finding very similar ones elsewhere in the code base and you know that's causing a an increase in the volume of work For the obscurity team.

Speaker 2: Um I know we want to talk about books and projects. Is there anything else we should mention before switching to that?

Speaker 3: Nothing from me.

Speaker 2: All right. Well, if I may, I'll go first. I'm enjoying this book, The Coming Wave, which is I think two years old. It's written by one of the co-founders of um Deep Mind. And yeah, I'm really enjoying it. I I thought I was burned out on these sort of AI prediction books. But the author knows what he's talking about and does a really balanced way of talking about what LLMs will do and also AI generally, especially in synthetic biology. Um he has a real focus on that. And it's interesting because I For me, because here in Boston I have a quite a few friends who are PhDs and work at pharma, and so they there's an in-between between where he's like, you know, code can solve all the biology stuff, and they're like, well, it's a little more complicated than that. But you know, somewhere in the middle that we'll meet. Um so I appreciate it's uh very well written and a lot to think about of like, yeah, AI is gonna do a lot of stuff, right?

Speaker 2: He's obviously he's not negative about it, right? He's not a doomer. Um but he doesn't seem unduly boosterish either. So um yeah, I highly recommend it. Somehow I missed it in the past, but I'm enjoying it. And over to one of you.

Speaker 3: Sure. I'll do it. Um I sometimes watch Hank Green, the science YouTuber, and one of his his episodes that um caught my attention was on this book, The Fabric of Civilization. He's been doing this uh thing where he, you know, finds some interesting idea and he just like contacts that person and does a uh an interview. So the author of this book, um, whose name I didn't write down, yes, she's really great and Um, it's about the history of fabric textiles and how it's like almost an erased side of of of our history. Like we find the stone tools from the Stone Age, we do not find the string they used to tie the stone to the wooden handle. All the way through, you know And it's also very feminist, like for most of

Speaker 3: of history, women were spinning cloth to clothe everyone. Like the whole time. It was like the the spare time activity until the invention of the loom. And then obviously that links into into computing. Um looms were the inspiration for punch cards, were the inspiration for uh the woven memory that was used on the Apollo uh program. And so many terms from uh the history of textiles make our way into the modern day and we also do not realize the abundance. Like t-shirts are like five, ten dollars, right? Like how how is that Physically possible, like before you'd own three pieces of clothing if you're lucky.

Speaker 1: Yeah, yeah. It's interesting as well because the um the you mentioned the loom sort of corresponds with the Industrial Revolution and um the the massive um upheavals in life lifestyles that people had then. And we sort of face the same now or there's you know, lots of talk um of now similar with, you know, this wave of AI coming in. And but I to think that Um, the loom is a bad thing, you know, to two hundred years later frees people from, you know, spending all day, every day, you know, all their spare time working on weaving materials suddenly Yeah, that's not that's not something you have to do. So it seems like that a lot of opportunity is freed there. Um whether or not it gets

Speaker 2: Well the problem is the politics. It's not the technologies, the politics. And it always lags. There's some term for it. Um, but obviously we conflate the two. Yeah.

Speaker 1: You know, we it it's obviously everyone's worried at the moment or concerned at least at at the moment about what the effects of the current thing uh you know, the current changes would be. But I I like to be optimistic about the technology technology being a liberator for um human um activity, not necessarily.

Speaker 3: Absolutely.

Speaker 2: Well, we still need, right, there's a a glib saying, right, I want AI to cook my dinner and do my laundry and, you know. Well that's the that's the one I really want.

Speaker 1: Rather yes rather than it writing the poetry and doing the picture.

Speaker 2: Yeah, yeah, exactly. Yeah, exactly.

Speaker 1: Yeah, yeah, yeah. Um so I'm gonna go. Um I need to introduce my my book and my project together because um my book is um the Beam Book Um which is understanding the Erline Rank runtime by Eric Eric Stenman. Where is it? There it is, right? I wasn't gonna to talk about it on the show because it's um a sort of crazy um s sort of thought I had about, you know, running um Python combined with Erlang and thinking, well, you know, I could potter away on that. And i but it's just so sort of left field that I thought, oh I I won't talk about it on the show, that's a silly recommendation. But then um Bemoad Cesno, who's the maintainer of Gunicorn, he's on absolute fire at the moment. He's Not only has he updated Gunnar Corman to first new version in a couple of years and he's added HTTP two

Speaker 1: support with um early hints and um trailers and for for Whiskey and for ASGI and he's he's done all these things. You think, wow, that's a massive upgrade for Gunicorn. But now he's released this new Erlang um web server qu called Hornbeam, where Python meets Erlang and it's a WesGi Whiskey AsGee WebSoftKit server built on the Erlang VM with Interel between Python and Erlang. And it's like, oh wow, my my crazy side project. It wasn't totally crazy as well. Benoit's gone and actually done it. So my my my project of the week is Hornbeam, which is this when Python meets Erlang web server. Um And my book is the Bean Book about understanding the Erlang runtime system because it you know, it really explains how Erlang's put together and why it's able to do the things it's able to do.

Speaker 1: And if you are gonna program in it, understanding that runtime is you know, worthwhile. Um that's my book and

Speaker 3: that's always been close to Django because obviously salary started as backing onto RabbitMQ, always in Erlane.

Speaker 1: Yes.

Speaker 3: And it was always a mysterious beast to me, you know. This language that can hot swap running code and do like tens of thousands of connections per core and you're like it's wildly different.

Speaker 1: Yeah, I mean well the thing with Er Erlang is it does the concurrency bits. Um easily. Those are sort of baked into the language. Why would you use Erlang? Because I w I want the those concurrency bits. So if you are handling lots of connections and long-lived connections and you could do that in Erlang and then your uh your kind of business logic in or your your web logic in the Python that you you know and love. That's for me is a very appealing story. And that Benwell's just gone and actually produced this thing. I'm I'm very excited to dig into that and see what see what's gonna happen Um anyway. But yeah.

Speaker 2: Adam, do you have a project?

Speaker 3: Yeah, my project's part of the upcoming Python version. It's Tachyon, which is the uh the nickname for the new sampling profiler coming into Python. So yeah, I've used a bunch. Three fifteen, yeah, sorry. Um yeah, so I've used a bunch of profilers. I recommended PySpy back in my SpeedUp Your Django test book, and that's kind of stood the test of time. It works well. I've written one profile just now for just single functions as I explained, and I've used Python's build in C profile. It's like a brand new alternative profiler that's very low overhead, very high fidelity, they call it up to a million Hertz. So it can take a million samples a second from a single process and It's got a fancy UI, UI, right? A terminal UI. Yeah, very excited to use it.

Speaker 3: Waiting for projects to be on 315, but I guess I can

Speaker 1: program

Speaker 3: some stuff that works already. Come start profiling Django itself, right? Yeah. Take a peek. Yeah. Yeah.

Speaker 2: Good. Well mine is quick. Um it's actually DJ URL's panel, which I think one of you commented in the notes, might be now this Django control room. But it's uh which one of you? Was that you, Carlton?

Speaker 1: That was me. That was me. So d go on. I mean explain.

Speaker 2: Well no, that I I'd I'd I'd seen Django Control Worm, but I hadn't realized it was the same author. Um but it seems like a Nice visual way to, I guess, inspect your Django app in one place. I've yeah, I've it looks really interesting. I w I want to dive into it more. I saw it, but I haven't given it a full place run through.

Speaker 1: So I think the thing there is that the DJ um URLs panel is just like one option. He's got a Redis one, he's got a Celery one, he's got I don't know. Signals errors. And then he's he's packaged them all up into this control panel thing, which has just been released this week. Um so

Speaker 2: yeah. He has a nice website, Django Controlroom. com. So Yeah.

Speaker 1: But yeah, I was going to mention that as my project until I I opened the notes and saw that you Oh I'm sorry.

Speaker 2: If I may, you uh you told me about the Beam Book Like was it Christmas or November? Um

Speaker 1: this is

Speaker 2: Adam, this is what he does. He's like on the beach reading, he's like, the red book, I got the red

Speaker 1: book.

Speaker 2: But yeah, it all ties ties in together in a way for you.

Speaker 1: I'm super excited by this. It's as I say, I I I just thought it was a silly Like, you know, create you know, mad mad experiment on my part and Benwell's gone and actually built the thing and it's like, oh wow, okay. I've I'm very happy to give that a play.

Speaker 3: Yeah, that's exciting.

Speaker 2: Yeah. Um I guess I'll I'll as we conclude, um Adam, I'll ask you the the magic wand question, right? So one one thing to change about Django or Python ecosystem, you know, as you sit today, what w what would you pick?

Speaker 3: I think last time I answered uh about adding the um what have become called model field fetch modes and turns out I managed to get that done So for that's coming six one. So I better be careful what I wish for here. I wish there was an a a team, an army of people like throwing their profilers at their projects. And And finding the 1% optimizations here and there. I think Django could go twice as fast just on default Python if we if we if we were dug in and did that.

Speaker 1: Yeah. I think there's so much low hanging fruit just sat there if we actually want it. Um

Speaker 2: that's a Google summer code or or some some way we can Well

Speaker 1: I mean, you know, I 'm interested with the work of Fahan and Adam Hill and um Andros who does Daniel Live, they've been do you know benchmarking, you know, with different options and different, you know, approaches to doing APIs. and shown that there are big changes, big big speed-ups available just, you know, r changing the serializers, say, or um Fahhan has um just got a PR merged that will be in 6. 1 as well to get make the multi-part Parser swap. And then so we can use a third-party package from the ecosystem, right? A very small wrapper layer to just make sure that it returns data in the format. Django once and then use that in our with our request object. And all of a sudden we can, you know, big passing big multipipe requests maybe get a th 33% speed up he benchmarked at just as an initial thing.

Speaker 1: Well even if you don't get even if you get half of that, that's still massive, right? Yeah. If you're processing a request board. Um but there's just I think yeah I agree with you, Alan, totally. There's just loads of these available if we want to.

Speaker 3: Just everyone do it a little bit on your own project and see what pops up and Yeah. I'm sure it's different for each project too, like whether you're API heavy or form heavy, template heavy, it will it will show up different things.

Speaker 1: That's a good thing.

Speaker 2: 18 months, 24 months.

Speaker 3: It's come to get

Speaker 1: your next book out. So Adam, yeah, but just before we just take a buy, to remind people how they buy their books. And there must be a bundle that they can get where they get all of them if they haven't got them. And just do it the best money you can spend

Speaker 3: So it's adamj. eu slash books, link in the show notes, I presume. Um four books available, bundle of the 3DX books is is one option. Um and there's the Git bundle too. That's Git and GitHub. So if you're not using Django, don't know why you're listening to the podcast, but uh you can find that too.

Speaker 1: Generally.

Speaker 2: Yeah, wait, wait, I have to ask. If you if you if you do you have another book on the horizon? Are you are you booked out? You must have one.

Speaker 3: Okay.

Speaker 2: Okay.

Speaker 3: There are there are the the little notes growing in like bullet points day by day. Oh that's a handy technique, you know.

Speaker 2: Yeah Uh well, Adam, thank you for making the time, of course. Um and and thanks for all the stuff you do for Django. I mean Yeah. It just absolute w one of the pillars of the community, both on the code and also writing about it, right? Which not everyone who does the code part. has a blog and so I appreciate it. And

Speaker 3: Thank you for everything you're doing too. I always love listening to Django chat. It's like number one, like if it c when it comes out, always first on the podcast queue.

Speaker 2: I'm just happy to give Carlton a platform. Try not to scroll over him and sit sit back a little bit.

Speaker 1: You should you should pick yourself up as well, Will you? complete got set of books and

Speaker 2: courses. Well Adam, you know, we we resisted t making this like a lament about, you know, maintaining projects, but um yeah. That's the nice thing about tech books is they're useful but then they they go out of date. Yeah. Anyways, DjangoChat. com. We're on YouTube. Thanks again, Adam, and we'll see everyone next time. Bye bye.

Speaker 1: Thanks, Tom.

Speaker 3: Thank you, everyone.