Adam is a prolific Django contributor and author of a new book, Boost Your GitHub DX. We discuss how to get the most out of GitHub (or any Git-based platform), as well as current work on bringing Python bindings to the ICU (International Components for Unicode) library, and more.
🔗 Links
📦 Projects
📚 Books
🎥 YouTube
This episode is brought to you by Six Feet Up, the Python, Django, and AI experts who solve hard software problems. Whether it’s scaling an application, deriving insights from data, or getting results from AI, Six Feet Up helps you move forward faster.
See what’s possible at https://sixfeetup.com/.
Carlton (00:00)
So welcome to another episode of Django Chat podcast on the Django web framework. Carlton Gibson joined us ever by Will Vincent. Hello, Will.
Will (00:06)
Hey Carlton.
Carlton (00:07)
Hello Will and today we've got with us back on the show Adam Johnson. How are you doing Adam? Long time.
Adam (00:12)
Good to be with you again, yeah. Lovely to chat.
Carlton (00:15)
Well, let's dive right in because you've got yet another book off the press
Adam (00:17)
Okay.
That makes it a DX trilogy.
Carlton (00:25)
Is it only three? I was thinking it was four now already.
Will (00:25)
⁓
Adam (00:28)
There's four books, but it's the third in the Boost Your DX series.
Carlton (00:34)
No, okay. I'm going to have to remind you. No, no, no, hang on, hang on, hang on. Before we dive in, what are the titles again? Because you've got the testing one, which is super, but that's not a DX book. Right. Okay.
Will (00:34)
And this one is beyond just, yeah, this one is beyond Django.
Adam (00:41)
Yeah, okay.
Speed up your Django tests. And then... No. There you go.
And then you've got boost your Django DX, boost your Git DX, and now boost your GitHub DX.
Carlton (00:53)
Okay, so you've drawn a distinction there between get and get up.
Adam (00:57)
yeah, well, that's 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 a 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 2005-ish. Around the same time as Django was created and like it promoted...
Git and also promoted code being out there in the open on a reliable Forge. Previously we had things like Source Forge and Google Code that were harder to use, much harder.
Carlton (01:39)
What was always nice about
GitHub was you could browse the code. It was much easier to browse the code.
Adam (01:46)
you felt like
you're in the code. They put the read me front and center and yeah. But yeah, so you can use Git with many different Git hosting providers, GitHub, GitLab. Now things like Codebug, free open source ones are rising in prominence as GitHub is falling in popularity. Yeah, so I wrote this book on...
using Git better and to limit the scope. was all about things you can do locally with the Git command line and related tools. And there was always like this idea of I could write a chapter on some of these cool tricks I know in 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. So, you know, it was deferred until, you know, I finished off this book last year between February and November.
Carlton (02:30)
Right, okay.
Okay, great.
Will (02:39)
And I think it's fair to say, even though it is a book on GitHub, you can use a lot of 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 Git tool because increasingly they're adding things like the equivalent of GitHub actions and they're trying to 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?
Adam (03:07)
⁓ It is like, definitely think even if GitHub like, falls out of favor with the general community, 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 ⁓ these are the things that like still map into GitLab or whatever. Then yeah, I think that's something for everyone in there.
Carlton (03:31)
Okay, I mean, let's dive in there because you've mentioned it twice, the sort of falling popularity of GitHub. And yet, I feel that because there's a lot of new features that I just don't want. And there's also kind of a monoculture thing. 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?
Adam (03:35)
Yeah, okay.
I don't think so. There have been some prominent projects like Zig which moved off because of, I think primarily all of these AI contributions and definitely Aliso Mastodon as a developer community. There's a lot of ranting about the next co-pilot button or the slop PRs that are coming through.
Carlton (04:17)
Macedon is a particular, I mean I'm on Macedon, I like Macedon, I don't go on the other ones, but it is a particular community, right? It is more to the hardcore of...
Adam (04:23)
It is. It is.
Will (04:27)
It's an
echo chamber. mean, if you know, sitting in a larger organization where we talk about the socials, I think finally 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 the only social that matters honestly is LinkedIn at this point until they completely muck it up.
So I enjoy Mastodon, Fostodon 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.
Adam (05:02)
It's true.
Now, you know, my posts used to do like quite big numbers on Twitter before the takeover. Now the only one that compares in that kind of scale is LinkedIn.
Will (05:13)
Yeah, but let's plug the book. All right, let's talk about why you, where do some of the key, you know, we want people to read the book. What are some of the top features that you can learn in the book for someone who is using GitHub?
Adam (05:16)
Okay, okay.
Yep.
Yeah, so it's structured a bit like a run through of GitHub pointing out things in the UI 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, you know, now I can do pull requests in a few letters on my command line. And I think that's that's pretty powerful. Yeah.
Carlton (05:50)
I've always been a bit skeptical
about the GH command. I've had these old... Well, no, but okay, but that's me down to a nutshell, right? Why would I use a new tool when the tool I've got will do it perfectly happily? But there was a few things like, I don't know, Fetch a PR, check out a PR for which I had an alias and things. When the GH command came out, I already had those, so why would I change? I wouldn't.
Adam (05:56)
huh. Carlton is skeptical about something, yeah.
Yeah, it's
Will (06:18)
You're not
everyone, Carlton, right? This is the problem.
Adam (06:19)
just the...
Carlton (06:20)
No, I understand I'm not
everyone, but this is I'm asking Adam, because he's 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.
Adam (06:33)
Yeah, nearly every daily button on the UI has an equivalent command. And some of them are quite flexible as well, like creating a pull request, has like four different modes. So you can either 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. ⁓ So yeah, it's a pretty nifty piece of kit and woefully underused, I would say.
from what I see from people developing, like GitHub is normally that website. You learn how to clone, you learn how to make a pull request, you learn how to bug your coworkers on Slack for reviews, and then you start focusing on the code.
Will (07:22)
So are you using it more in a command line capacity then? Is that the sense I'm getting or? Yeah.
Adam (07:26)
Yeah,
definitely more and more, especially writing the book, like made me look at some of those corners I hadn't investigated.
Will (07:34)
Well, this is your, I'm sorry, I forget the tagline, right? Your, was it? Your development led through books, right? Where you always end up, you contributed to Git when you wrote the Git book and what's your phrase for that? I'm sorry, I'm forgetting. There you go, yes. Yeah, I haven't quite, I've...
Adam (07:43)
Yep. The book driven development.
A little
bit of BDD here. I got a few pull requests into the GitHub docs fixing inaccuracy. I did look at the CLI, but everything I wanted was there. Yeah. So I'm happy.
Will (07:54)
Yeah.
But so the main idea,
Carlton (08:02)
the tone.
Will (08:03)
sorry, I'll just go Carlton. ⁓ Of course I will. The main point of this book with DX and your other ones, is developers can save time using these techniques and tools that they probably either don't know about or don't know how to get the most out of. And that's fair to say, right? Because someone, why read the book? 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?
Adam (08:31)
Yeah, that's the basic thesis of these books is like, there's some ⁓ 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. like there's, yeah.
Carlton (08:53)
or the common one.
Will (08:53)
Or even an open source project like Neapolitan. had a previous... We had ⁓
Carlton (08:58)
Why would you read the dogs? Why would I read the dogs?
Will (09:01)
Velda on right before you who was talking about using Neapolitan for client work and ⁓ admitted to not directly reading the docs. So, yeah.
Adam (09:09)
How nice.
Yeah.
Carlton (09:11)
Why would I read those? Just intuitive.
Will (09:13)
Well, but
I do think at a meta level, the Git and Git, like what's going to remain if AI truly takes over? Like, you're still going to need Git. You're still going to need a way to look at compare pull requests. Like, I think the UX of AI is, yeah, whatever it is, like, you need like a bomb way to look at different Git and pull requests. That's the one thing I'm like, that's going to stay.
Adam (09:28)
Absolutely.
Yeah, I'd say that's
a key thesis here. like my book is about the fundamentals. It's about knowing them, you know, inside out, hopefully something that applies, especially as you become more senior or use more more code generators. It's best to know them and know all the keyboard shortcuts, the little secret tools on GitHub that will help you navigate quicker.
Carlton (10:03)
think
it's true of all your books is that if you're an experienced developer, you may know, say, 60 % or 70 % of whatever, but the things you pick up will be like, oh, they're gold dust. 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 going to learn an awful lot, like just every chapter, bam, bam, bam, bam, bam. And if you don't have something like this resource.
You'll just got to do the same thing over and over again. This is the pattern I'm in this. I saw I push my code. opened 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 remember Tim Schilling asked me if I had any tips for people to up their developer skills. like, get Adam's book. Just go and buy Adam's books. Just go and buy the set. Cause you know, that's an investment in your career.
Adam (10:58)
thanks.
Carlton (11:03)
I noticed you talked about markdown and writing.
Adam (11:06)
Yes.
Carlton (11:10)
Go on, that's a sitter, you've got to jump in.
Adam (11:11)
kind of
Will (11:11)
Is there a question in there?
Adam (11:16)
a sneaky almost Trojan horse right in the middle of the book, you're learning about how click around GitHub and suddenly you're learning how to write better through first the GitHub markdown syntax and then like just specifically rules for writing on GitHub. I think that's very important. I think even more important in the age of like being able to spew out pages of text.
It's better to know what good writing looks like. LLMs can write a lot and it can be cogent, but it can be 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. I don't know who that's for really.
Carlton (12:05)
It's like the comment where it's like, you know, open the file and then, know, file equals open. So the comment that just said what the code line follows does.
Will (12:05)
Well.
Adam (12:11)
Mm-hmm. And it's like, yeah.
It's like jangos. ⁓ yeah.
Will (12:17)
Well, but I think this is...
Sorry for this light lag. was just gonna say, think one of the themes that I would say out of this season of the podcast has come up with, you because AI comes up in all capacities is more than ever, 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, 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 got to know the basics and you got to go to experts and they still out there, you know, for now.
Adam (13:00)
Yes, thankfully.
Will (13:03)
But sorry, you were gonna say something on Django though, Adam.
Carlton (13:03)
So I mean, we both.
Adam (13:07)
Yeah, just as a good baseline, like Django's own Git commit history, the tickets, the docs, they're all examples of ⁓ fantastic technical writing. And once you get perhaps into Django, read a few commits as well as the docs, you might realize that you're spoiled there compared to most commercial projects you work on where the commit messages are all over the place or they're the letter A or the word update. ⁓
Why did you do this? We don't know.
Carlton (13:39)
Fix it, oops.
Adam (13:40)
Yes.
Carlton (13:44)
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 you think, it's just running black. Well, a lot of teams aren't running black or whatever format they're using. ⁓ it's just, you know, doing some docs. A lot of teams aren't doing docs. it's, you think that these are like the minimum bar. They're not, they're much beyond the minimum bar. if you, you know, contributing to an open source project and learning these tactics, these...
Adam (14:00)
Mm-hmm.
Carlton (14:15)
these techniques when you go to an interview and say hey do know what I do this I do that I do that you stand out as a good candidate so it's another reason to you know be interested in these techniques I think.
Adam (14:27)
Absolutely.
Will (14:29)
I mean, I'll just say I find that people who learning how to code based on my books, Adam's books and other things, and then sometimes when they email me, there's a real shock at seeing what production code looks like for a junior developer. Again, because they're just used to classroom stuff, open source, curated books. production code is always one tweak away from being broken. That's the business imperative, right? It's very rare to have a chance to actually
Adam (14:56)
Yeah.
Will (14:57)
Do good code for the sake of good code.
Carlton (15:01)
seems like segue into your day to day, Adam.
Adam (15:04)
Yeah,
well, it's just gonna say like it's a common thing for companies to do a quality week or a sprint to improve their code base. It's like, well, what are you doing the rest of the time?
Will (15:16)
Well, yeah, you're making...
Adam (15:17)
You're making it work, but maybe
not making it better.
Carlton (15:23)
So we talked about LLMs and you've been using them a bit yourself, how's your experience?
Adam (15:28)
Yes.
Yeah, it's a bit mixed. I've been trying to think like how much more productive do I really feel with an LM? I was making a list of things that I think that are almost on par, which are like having a clipboard history manager. I think that's just almost as useful as an LM sometimes. And like just generally copying. Like if I'm going to start a new open source project, I'm going to copy one of my previous ones. I'm not going to, you know, ask Claude to start.
from scratch in a blank directory. There's so much embedded knowledge in my code already. So yeah, there's tools 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 I think those are almost on par. So maybe LLMs are a good boost, but they're not as revolutionary as people are saying. I think I'm in the middle of the pack.
My recent project, ⁓ this ICU for Pi, which we can talk about more later, that's in C++. And before having access to an LLM that could help me generate the C++ binding between the C++ library and CPython 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 use the real one.
like maybe I just had the power in myself all along and I just wasn't as daring.
Carlton (17:05)
the scaring of the blank page though maybe.
Adam (17:07)
Exactly. Exactly. Like there's something
so I can start fixing it, editing it. Yeah.
Will (17:14)
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, you're a 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, more earlier in his career and like an LLM can help point you to, 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 might not know on your own. So I think they're useful for that. But if you already have 20 years experience, might be more like you just need to be bold, as you say.
Carlton (18:00)
Well, you might know, you know, might be an expert over here, but, know, if you want to work over here, there's, you don't know all the libraries and all the interfaces and all the whatnots and, know, they can give you a good first, first map of the range.
Will (18:13)
Yeah, like if you're
new to something, I think they're actually can be really helpful, but you have to then go and do the work. You can't just forever rely on them to do stuff, I would say.
Carlton (18:25)
I'm curious about these people that have this policy of not inspecting the code that's generated. just couldn't... The rubbish that is generated. It's fine, it can work and 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 times to come if you haven't really tightened every screw on it?
I'm still not quite there on just letting them run and...
Adam (19:00)
I don't
feel comfortable there either. What is it? The Maltbook, the AI social network. They had just the open database of everyone's API key and the security researcher who submitted to them, I found this. He's like, well, I'm going to fix it, but I'm going to vibe code that fix too. So I'm not going to look at the fixed code either. So it's fixed. Now the AI says it's fixed. It's like, okay, is it really?
Carlton (19:10)
Right.
Will (19:23)
But I think part of the problem, mean, like, you know, so Anthropic, right, Claude Code, they still have, something like 300 open positions to pay developers, you know, $500,000, 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 people making the models. you know, cause there's parts of Anthropic that put out papers saying, you developers get dumber or like pointing out limitations, right? Like the problem is,
Adam (19:36)
Mm-hmm.
Will (19:49)
No one else is speaking or promoting outside of people pushing the models, right? So they're not gonna, 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. ⁓ 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 coming from these companies. And so it clouds, yeah, in practice, most, I think almost everyone has some sort of nuanced.
Carlton (20:10)
posted.
Will (20:19)
I mean, I don't know, some people are, I don't know, some people are all on agents. 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?
Adam (20:29)
Mm-hmm. Yeah.
Carlton (20:31)
One thing I'm worried about which is slightly meta is there seems to be a big divide in the community. There seems to be a big cleave between people who are very pro, very anti and a breakdown of the community there. As soon as we become tribal, it becomes difficult to...
Adam (20:52)
Yeah.
And what's acceptable to send us a pull request, for example, to Django? Like, is it okay to open a hundred things that your AI agent found? No, not really.
Carlton (21:02)
Yeah, I mean, I'm really
struggling at the moment in that, you know, it's always been hard to keep the balance between contribute, you know, four kids, full time job, open sourcing on the side. It's difficult to find that time and the increase in just really low quality noise is I'm finding that problematic. ⁓ I wonder if you, I mean, you maintain so many projects, Adam, so how's it going for you?
Adam (21:32)
feel like I've been lucky, like very few things so far. ⁓ I've had a security report the other day that maybe the person doesn't speak much English, but in general, you know, it's replying as if it was replying to a person. It's definitely chat GPT or something that I've 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 out of a chat prompt? Not really.
Carlton (22:04)
No, I mean, as well, like, if it's like somebody doesn't speak English to use a machine tool to aid communication, that seems like a positive, but...
Will (22:13)
Yeah.
Well, I can go, I don't want to skip over the ICU for Pi. Could you talk a little bit more about, so Rippling is one of the clients you work with. Can you talk about who they are, what they're doing, and why you had to develop this library?
Carlton (22:17)
I don't I don't know.
Adam (22:24)
Yeah. Yes. yeah.
Sure.
So yeah, I work as a Django consultant, I bill it. So part of the time writing the book, writing the blogs, part of the time on client work, most of the time my clients have found for 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. So my primary mandate at Rippling is make things faster. So I'm writing the profiler, cutting things out of the tests, cutting things out of their...
Will (22:50)
Yeah, yeah, I remember that one.
Adam (23:00)
based libraries, some of which are forks of open source ones. But in the case of this library, ICU for Py, 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. This is a GNU project, I believe, that can gather your strings and you can write translator versions of those strings. ⁓ 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 INTL, I think framework in the browser. So that is a different format of messages. can express more complex things like pluralization rules between languages change. So like there's no plurals in Chinese and Korean, for example, there's many plurals in... ⁓
German, Greek, for example. So it's a mini programming language in your translation strings. And then I wanted to expose that to Rippling.
they support 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++ library. C++ libraries need to be compiled exactly on the right platform with the right architecture and...
You know, it turns out that if you install one of these libraries, those Python ones, they're going to 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, into the Python wheels for each platform architecture. So it ended up as two repos, one to build ICU itself and one to build the Python library on top. ⁓
Carlton (25:05)
You get your veterans medal for Python packaging the hardware, right?
Adam (25:06)
Lots of, yeah.
Yeah. Lots of, like build architecture and a little bit of code on top. Yeah.
Will (25:16)
That's
fun to do, right? It's fun to do something new, right? Rather than, or in addition to everything else.
Adam (25:20)
Definitely.
Carlton (25:23)
Is that something we might pick up in the Django ecosystem?
Adam (25:30)
Yeah,
I've been considering this. Rippling use Django, and that's why they're interested, but they aren't using, say, Django templates, 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, maybe a template tag library to begin with. ⁓ Maybe, you know.
⁓ 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, but we'll see.
Carlton (26:06)
Okay.
Okay.
Will (26:08)
I have stuff, I'm just trying not to speak over you, Carlton, which I tend to do.
Carlton (26:11)
No, no, no,
the question that came I wanted to ask you is about terms of performance. And in the news recently was about lazy imports being coming in to Python. I wonder if you've got that's going to make quite a big difference.
Adam (26:19)
Mm-hmm.
Yes, that'll make huge difference, especially for Rippling, whose startup time has ticked up over the years from 30 seconds plus. But it's also a matter of that's coming in Python 3.15. And you've got to upgrade all the versions in between. Those are months long projects for a big client. ⁓ Looking forward to it. But that's like three, four years time kind of thing.
Carlton (26:44)
Okay.
right. Okay. So that far out, right?
Yeah, it takes a while. Okay. So the other work you've been doing is on profiling and you've got the T-prof project. tell us about it. Because my favorite, my absolutely favorite chapter of your testing book was the one about profile.
Adam (27:00)
Yep.
yeah.
Yeah, DeepRof has, was like naturally arisen from my attempts to optimize Rippling, other projects and Django itself. There was even one Django ticket that like made things click for me, where it's like ⁓ Jake Howard optimized part of the template tag setup. So it's like, moved a slightly expensive function call from every template compile up to one time on that.
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, it's a targeted profile. I came up with that name. You target which function to profile. So you can say, that's the only function I care about, or these are the only functions I care about. And then it will...
Will (28:04)
Hmm.
Carlton (28:11)
That was a three drink naming session.
Adam (28:19)
It hooks in through the Python sysmonitoring API. It it in nanoseconds. It reports a little chart using the rich library for a nice table at the end.
Carlton (28:33)
anything using rich we're gonna support good good good
Adam (28:35)
Yeah, Stan Rich.
Will (28:38)
Okay. Well, if, if I may, I'm curious, cause you said it at an interesting position, Adam, because obviously Django background, but also doing work, not just in Python. ⁓ like, what do you make of fast API these days? Because for me, like when I go to conferences for pie charm 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? What do you make of it?
Adam (29:16)
I don't know, I don't really think about it. I'm hired to work on Django stuff and it's always like, well, we're not gonna change it out of Django.
Will (29:18)
OK.
Okay, because they already have a Django setup, so they're not going to...
Adam (29:28)
Generally
established projects, yeah. Yeah, I think.
Will (29:32)
Well, let me change that slightly
then. ⁓ sorry. Like with asynchronous in general, like, cause Django obviously is improving that story. Have you found actual production uses for uses for a async capabilities in Django?
Adam (29:45)
A few,
yeah, like background, async, WebSocket stuff. Yeah, I had one client that was connecting via WebSocket to thousands of electric vehicle charges a few years ago. So that's when I really dug into channels.
Will (30:03)
Carlton, you're familiar with channels.
Adam (30:03)
think there's an overuse,
overuse maybe of async.
Carlton (30:08)
Yeah, I think people jump to async for because it's like cool basically. It's like, it sounds good. Unless you need a long-lived connection, you almost have no business dealing with it. And then once you need a long-lived connection, then okay, let's talk about async and then okay, your deployment policy and move things slowly. But people are like, we must replace the ORM and with a fully async.
Adam (30:14)
Mm-hmm.
Carlton (30:36)
the database connections, might have async Python wrappers, but they're still serialized ⁓ over the actual wire to the database. So it's not async and you're not getting massive concurrency in your throughput with your connection to the database. So you're still blocked in exactly the same prices as you always were. And it's that communication message about that async isn't an end in itself. It's a specific tool to use for specific cases. ⁓
Adam (31:07)
Yeah. I I think there's this, 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 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 free before. So.
Carlton (31:08)
And I... Go on then, go on.
Adam (31:36)
doesn't like magically do it.
Carlton (31:37)
And yeah, and here's the question, do
you think the kernel is better at swapping between active threads or is it more likely that kernels good at swapping between active threads or that you got every await in the right place and didn't make a blocking function call somewhere without really realizing it? Like I'd rather trust the know, 99 and half times out of a hundred.
Adam (31:55)
Exactly.
And Python code often doesn't isolate between threads or between async tasks properly. There's so much global states that a big client like Rippling, it's almost impossible for them to turn on threading, let alone async workers, because it's just sitting everywhere. There's one odd call to change a logger's level temporarily. that's global. So suddenly every other thing in that process will stop logging whilst this.
Viewers access, example. Flushing that out is almost impossible.
Carlton (32:33)
And
yeah, you just mentioned threading. the real threading, the free threading, which I, my mouth refuses to go between the F and the TH there. What are your thoughts there? Because in theory, that's going to do Django a lot of good, right? If we, cause we have this kind of threaded model and it would be nice to be able to do that. Currently we've spin up multiple worker processes to get around the gill, but real threading should help us in theory.
Adam (32:40)
Mm-hmm.
Yeah, lots of bits of Django are thread safe already. Like when you access a database connection, that's thread local, right? So fingers crossed, know, free threading plus Django becomes a sensible deployment strategy. But as I say, it's hard to guarantee you're leaking state between threads because there's so much global state in Python.
Carlton (33:25)
And it's still a while out, right? We're still on 3.12 being the minimum supported version. It takes a while for these new versions to come through. OK, good.
Adam (33:30)
Mm-hmm. Yeah.
Will (33:38)
Are you able to attend JengaCon Europe this year,
Adam (33:41)
Yeah, it should be there. Yeah. Looking forward to it.
Will (33:44)
Looking forward to the keynotes.
Adam (33:47)
⁓ yeah, I don't, I didn't look them up. Is that you plugging yourself?
Will (33:49)
Sorry, that's me. Yeah. No, not me. Not me.
Well, that's a very indirect way of ⁓ getting at a typing question. But Carlton's giving a keynote there and maybe announcing something.
Adam (34:05)
Cool, exciting.
Carlton (34:05)
Yeah, I'll
be giving a talk on that.
It's called Static Islands Dynamics C.
the relation between where we want to use static typing and Python's dynamic core and Django's dynamic core. mean, Django was specifically built 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. And so I'm going to talk about that.
Adam (34:25)
Mm-hmm.
Exciting, exciting, I love it.
Carlton (34:42)
Hopefully
Will (34:43)
Yeah. Well, I appreciate it because I feel like there's a lot of momentum towards
Carlton (34:44)
we'll see.
Will (34:48)
making it all static and turning Python into something else. if I may, Carlton, I think you're pushing back a little bit and showing maybe an in-between approach.
Carlton (34:56)
Yeah,
mean, You know, if, if, if we're in a place where, it has to be static and dynamics only for toy projects, then we're using the wrong programming language. Basically we should be using 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 pins, optional typing, static typing won't ever do. And, 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 that dynamic nature, at least sometimes, there really is a question as to why we're using Python at all. ⁓ And so yeah, I want to push back on ⁓ this idea that ⁓ this vibe that
actually static Python is the new ideal. Yes, there are cases where it's important and yes, there are cases where it can help, especially large teams. can be useful to add an extra layer of security, but okay.
Adam (36:12)
Yeah, well, T-way for that.
Will (36:16)
Yeah, yeah, that's Meta's Meta. Yeah. Yeah, well, I mean, on the PyCharm team, 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 certainly, anything from Astral is a pretty strong candidate as a default these days.
Adam (36:19)
That's true, yeah.
Carlton (36:35)
Yeah, no, it's a lovely,
you know, I'm not saying we shouldn't do typing. I'm not saying we shouldn't use them, but this, that there is, I think, like all these things, you know, you have this pendulum effect, so we swing too far. I think there is a certain ⁓ vibe that, you know, dynamic code should be askewed at all costs now. ⁓ And that's wrong. ⁓ Anyway, wait for the talk.
Adam (37:04)
Thanks.
Carlton (37:05)
Yeah
Will (37:05)
Yes. Sorry, Carl. I'm excited on your behalf, but I know I'm giving away. ⁓ I did want to mention Adam, I'm, really impressed that you, know, just cause 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'm just very impressed. You still seem to have your, 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. ⁓
I'm impressed by that balance. I'm glad you're doing it too, because I think sometimes people come in and have a burst and then, know, job or other things, ⁓ get in the way and they sort of, you know, sort of die out.
Adam (37:38)
Thanks. Yeah.
Yeah, I've kind of made it work where clients understand that 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 a PI, for example, initially it looked like that might be something just internal to Rippling. Like we're calling one function through C++. How hard could it be? It turns out 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? Cause 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.
Carlton (38:26)
it sort of
feeds the ecosystem as well, right? And 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 ⁓ collectivizing the maintenance cost of that package. And they'll find bugs that you didn't.
Adam (38:28)
Exactly.
Will (38:45)
Yep. Well, I did want to ask, you're still on the security team. You've had many positions in Django over the years, but you're still on the security team. How's any quick updates on how that's going these days?
Carlton (38:46)
it makes sense.
Adam (38:52)
Mm-hmm.
It's just about managing to read my share of the issues and contribute back. That's definitely low on priority with worrying about kids and stuff at the moment. But yeah, it's fun. Yeah.
Will (39:10)
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.
Adam (39:18)
It's fun, it's shared, I also don't worry about reaching out to the security team when I have questions in my own projects. think it's very nice to have this kind of private community channel that's still people I trust to take a look at some code. ⁓ Yeah, very reassuring that 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 slup, there's also people grabbing lots of high profile issues on these projects.
Carlton (39:55)
We should link in the show notes to Jacob Wells put ⁓ a post up on the Django blog recently about ⁓ the recent work in the security team, because ⁓ I think they found quite a lot of the level of reports rising with the new tooling available. think people are ⁓ taking existing reports and finding very similar ones elsewhere in the code base. And, you know, that's causing an increase in the volume of work for the security team.
Adam (40:00)
Mm-hmm.
Will (40:02)
Yes.
I know we want to talk about books and projects. there anything else we should mention before switching to that?
Adam (40:35)
Nothing from me.
Will (40:37)
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 DeepMind. And yeah, I'm really enjoying it. 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.
He has a real focus on that and it's interesting because I for me because here in Boston I have quite a few friends who are PhDs and work at Pharma and so they There's an in-between before he's like, you know code can solve all the biology stuff and they're like It's a little more complicated than that. But you know somewhere in the middle that will meet ⁓ so I appreciate it's very well written and a lot to think about like yeah AI is gonna do a lot of stuff, right? He's obviously he's not negative about it, right? He's not a doomer, but he doesn't seem
Adam (41:33)
Mm-hmm.
Will (41:35)
unduly boosterous either. So yeah, I highly recommend it. Somehow I missed it in the past, but I'm enjoying it.
Adam (41:39)
Nice.
Will (41:44)
And over to one of you.
Carlton (41:44)
Okay, Adam.
Adam (41:47)
Sure, I'll do it. I sometimes watch Hank Green, the science YouTuber, and one of his episodes that caught my attention was on this book, The Fabric of Civilization. He's been doing this thing where he finds some interesting idea and he just like contacts that person, does an interview. So the author of this book, whose name I didn't write down, she's really great, and it's about the history of fabric.
textiles and how it's like almost an erased side 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 was a very feminist, like for most of history, women were spinning cloth to clothe everyone. Like the whole time it was like the spare time activity until the invention of the loom.
Will (42:28)
Mmm.
Carlton (42:29)
Alright.
Adam (42:45)
And then obviously that links into computing. ⁓ Looms were the inspiration for punch cards, were the inspiration for the woven memory that was used on the Apollo ⁓ program. And so many terms from 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, $10, right? Like how is that physically possible? Like before...
You'd have three pieces of clothing if you were lucky.
Carlton (43:18)
Yeah, yeah. It's interesting as well because ⁓ the invention of the loom corresponds with the Industrial Revolution and ⁓ the massive ⁓ upheavals in lifestyles that people had then. And we sort of face the same now, lots of talk now similar with this wave of AI coming in. But I like to think that ⁓ the loom is a bad thing. 200 years later, it frees people from spending all day every day.
Adam (43:30)
Yes.
Carlton (43:47)
you know, all their spare time working on weaving materials and that's not something you have to do. So it seems like a lot of opportunity is freed there, whether or not it gets society structured. Yeah, something like
Will (44:00)
Well, the problem is the politics. It's not the technology, it's the politics. And it always lags.
Adam (44:02)
Yes, exactly.
Will (44:05)
There's some
term for it. But obviously we conflate the two.
Carlton (44:09)
You know, obviously everyone's worried at the moment or concerned at least at the moment about what the effects of the current thing, you know, the current changes would be, but I like to be optimistic about the technology being a liberator for ⁓ human ⁓ activity, not necessarily.
Adam (44:27)
absent.
Will (44:28)
Well, we still need, right, there's a glib saying, right, I want AI to cook my dinner and do my laundry and, you know, that's the one I really want.
Carlton (44:38)
Rather than it writing the poetry and doing the pictures. ⁓ So I'm going to go. ⁓ I need to introduce my book and my project together because my book is the Beam book, which is Understanding the Erlang Runtime by Eric Stenman. I wasn't going to talk about it on the show because it's sort of crazy sort of thought I had about running Python.
Adam (44:38)
Yes, please.
Will (44:41)
Yeah, yeah, yeah, exactly. Yeah, exactly.
Carlton (45:08)
combined with Erlang and thinking, well, you know, I could potter away on that. But it's just so sort of left field that I thought, ⁓ I won't talk about it on the show. That's a silly recommendation. But then Benoit Chesno, who's the maintainer of Gunnar Korn, he's on absolute fire at the moment. Not only is he updated Gunnar Korn with the first new version in a couple of years, and he's added HTTP2 support with early hints and...
Trailers and for whiskey and for ASCII and he's done all these things you think wow that's a massive upgrade for gunna call But now he's released this new Erlang web server called Horn beam where Python meets Erlang and it's a whiskey whiskey ASCII web softkit server built on the Erlang VM with Interop between Python and Erlang and it's wow my crazy side project It wasn't totally crazy as well Ben was gonna actually done it
So my project of the week is Hornbeam, is this when Python meets Erlang web server. And my book is the Bean Book about understanding the Erlang runtime system, because it really explains how Erlang's put together and why it's able to do the things it's able to do. And if you are going to program in it, understanding that runtime is worthwhile. ⁓ So anyway, that's my book.
Adam (46:26)
That's always been close to Django because obviously Celery started as backing onto RabbitMQ, always in Erlang. And it was always a mysterious beast to me, know, this language that can hot swap running code and do like tens of thousands of connections per core. That's wildly different.
Carlton (46:31)
Yeah. Yes.
Yeah,
I mean, thing that Erlang is it does the concurrency bits easily, right? Those are sort of baked into the language. Why would you use Erlang? Because I want 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 kind of business logic in, or your web logic in the Python that you know and love, that for me is a very appealing story.
that Benoit has just gone and actually produced this thing. I'm very excited to dig into that and see what's going to happen. So, projects.
Will (47:17)
Adam, do you have a project?
Adam (47:20)
Yeah, my project's part of the upcoming Python version. It's Tachyon, which is the nickname for the new sampling profiler coming into Python. So yeah, I've used a bunch. 3.15, yeah, sorry. Yeah, so I've used a bunch of profilers. I recommended PySpy back in my Speed Up Your Django Test Book, and that's kind of stood the test of time. It works well.
Will (47:30)
315, right? Yeah.
Adam (47:44)
I've written one profile just now for just single functions as explained and I often use Python's built-in C profile. Tachyon'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, TUI, right? A terminal UI. And I'm very excited to use it. Waiting for projects to be on 3.15. but I guess I can.
Carlton (48:13)
It's another three years.
Adam (48:13)
profile some stuff that works already.
Can start profiling Django itself, right? Yeah, take a peek.
Carlton (48:19)
Yeah.
Will (48:23)
Good, well mine is quick. ⁓ 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 a, which one of you, is that you Carlton?
Carlton (48:35)
That was me. was me. So go on. mean, explain explain it.
Will (48:38)
Well, no,
I'd seen Django Control Room, but I hadn't realized it was the same author. ⁓ But it seems like a nice visual way to, I guess, inspect your Django app in one place. Yeah, it looks really interesting. I want to dive into it more. I saw it, but I haven't given it a full playthrough.
Carlton (48:55)
So I think the thing there is that the DJ URLs panel is just like one option. He's got a reddish one, he's got a celery one, he's got, I don't know, signals errors, and then he's packaged them all up into this control panel thing, which has just been released this week. So.
Will (49:03)
Okay.
Mm.
Okay, was a nice website,
DjangoControlRoom.com. yeah.
Carlton (49:15)
Yeah.
But yeah, I was going to mention that as my project until I opened the notes and saw that you put the URL. No, it's OK. It's OK. I went for the warm beam.
Will (49:21)
I'm sorry. we know what I if
I may you, you told me about the Bean book, like Christmas or November, right? Like you. ⁓ This is Adam, this is what he does. He's like on the beach reading. He's like the red book. got the red book. But yeah, it all ties ties in together in a way for you.
Adam (49:34)
Mm-hmm.
Carlton (49:39)
We
You know, I mean, it's really, I'm super excited by this. It's, I say, I just thought it was a silly, like, know, crazy, mad experiment on my part. And then I was gone and actually built the thing and it's like, oh wow, okay. I'm very happy to give that a play.
Adam (49:59)
Yeah, that's exciting.
Will (50:02)
Yeah. I guess I'll, as we conclude, ⁓ Adam, I'll ask you the magic wand question, right? So one thing to change about Django or Python ecosystem, as you sit today, what would you pick?
Adam (50:17)
I think last time I answered about adding the what have become called model field fetch modes and turns out I managed to get that done. So for that's coming in six one. So I better be careful what I wish for here. I wish there was a team, an army of people like throwing their profilers at their projects and finding the...
Will (50:31)
Hahaha
Adam (50:43)
one percent optimizations here and there. think Django could go twice as fast just on default Python if we we if we were dug in and did that.
Carlton (50:52)
Yeah, I
think there's so much slow hanging fruit just sat there if we actually want it. ⁓
Adam (50:55)
There is. Yep.
Will (50:58)
Maybe that's a Google
Summer code or some way we can push that a little bit. I don't know.
Carlton (51:02)
I mean, you know, interested
with the work of Farhan and Adam Hill and ⁓ Andros who does Daniel Lively. They've been benchmarking with different options and different approaches to doing APIs and shown that there are big changes, big speed ups available just changing the serializer, say. Or Farhan has just got a PR merge that will be in 6.1 as well to make the multi-passer swappable.
Adam (51:06)
Mm-hmm.
no,
that's done.
Carlton (51:29)
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 wants and then use that with our request object. And all of a sudden, can, know, big passing, big multi-pipe repress, maybe get a 33 % speed up, he benchmarked that just as an initial thing. Even if don't get, even if you get half of that, that's still massive, right? ⁓ If you're processing big request.
Adam (51:53)
That's cool.
Carlton (51:55)
⁓ But there's just, think, yeah, I agree with you, Adam, totally. There's just loads of these available if we wanted.
Adam (51:59)
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 show up different things.
Carlton (52:15)
That's a good one.
Will (52:15)
All
right, well, we'll see when we have you on again in, you know, whatever it is, 18 months, 24 months, if it's come to pass.
Adam (52:20)
Yeah, all right. ⁓
Carlton (52:22)
when you get your next
book out. So Adam, yeah, before we just say goodbye, to remind people how they buy their books. And there must be a bundle that they can get where they get all of them and haven't got them. And just do, folks, it's the best money you can spend.
Adam (52:24)
no pressure.
Will (52:28)
Yes.
Adam (52:29)
Yes, exactly.
So it's adamj.eu slash books, link in the show notes, I presume. Yeah, four books available, bundle of the 3DX books is one option. 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 past class, but you can find that too. Yeah.
Carlton (52:51)
It's generally interesting.
Will (52:53)
Wait,
wait, I have to ask. Do you have another book on the horizon? you booked out? You must have one per... Okay. Okay, fair.
Adam (52:58)
It's definitely on pause right now with a toddler and a baby in the house, but ⁓ there
Carlton (53:02)
Yeah.
Adam (53:03)
are the little notes growing in like bullet points day by day. that's a handy technique, you know. We'll see. Yeah. ⁓
Will (53:11)
Hmm.
Carlton (53:11)
We'll speak to again in a year's time.
Will (53:15)
Yeah.
Well, Adam, thank you for making the time, of course. ⁓ And thanks for all the stuff you do for Django. mean, yeah, it's just absolutely 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. so I appreciate it. yeah, we'll have. ⁓ wow.
Adam (53:23)
No, thank you.
Thank you for everything you're doing too. I always love
listening to Django chat. It's like number one, like if it comes, when it comes out, always first on the podcast queue.
Will (53:44)
I'm just happy to give Carlton a platform, try not to speak over him and sit back a little bit.
Adam (53:46)
Hahaha
Carlton (53:48)
You should bring yourself up as well, Will. know, sitting there with your, you know, complete set of books and courses and... ⁓
Will (53:55)
God. Well, Adam, you know,
Adam (53:55)
Come on,
Will (53:57)
we resisted making this like a lament about, you know, maintaining projects. But ⁓ yeah, that's the nice thing about tech books is they're useful, but then 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.
Carlton (54:16)
See you next time. Bye bye.
Adam (54:17)
Thank you everyone.