Transcript: Git and Django 5.0 - Adam Johnson

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hello, Will.

And we're going to talk about his new book on Git.

Welcome, Adam.

Thank you for inviting me on.

And uh gotta say, Snap.

Carlton and I are both wearing Django.social t-shirts.

So what is that?

Tell tell people what tell people what that is.

I think there was there's gonna be one at DjangoCon US.

Uh or am I I'm guessing here, I think.

But um, yeah, John Gould, uh recruiter here in the UK for Django Specific, uh, who's uh just a great member of the community, giving back a lot, hosting these events, giving back to the DSF.

Um so Django Social is his project for running meetups socially everywhere, and he's also ready to help anyone who who wants to jump on and start a meetup in their city for socializing with Django developers.

So if you if you're a Django developer near me on the Costa Brava, let me know, and then we'll do a Django social.

Are you are are you attending Adam or you're not, right?

Okay.

One of the things that we'll get there.

Yeah, yeah, yeah.

And maybe actually since we have you on Adam with all your many hats, steering council, maybe we this could also be an opportunity to talk about 5.0, because we just as we're recording the feature feature freeze just went into effect, I believe.

What what are we what are you all excited about that's coming out in 5.0?

Uh I I've got I've listed three features that I wanted to highlight.

The first would be generated field, which um Lily Foot and others pushed through, and Myas got it in at the last minute this last week.

Um, this is a database field that is computed in the database from some calculation across other database fields.

So a classic example would be you have a user with a first name and a last name, but for some reason you want to be able to search across their full name, you can create a virtual field there that is a combination of those two, and then you can write a query set that queries against people's full names.

So, like if you've got a um type ahead search, you might be able to let someone type part of a any part of their name and it will search across all of it without query set tricks.

It's all just done once in the model.

You know, but go on that was one then, what was two?

Uh the db default.

Yes.

Uh like number 470, when new tickets are under 33,000.

Um this is big because uh having your database as a single source of truth for things like timestamps is is very useful.

It also means Django doesn't need to do anything extra before saving such fields.

You can get the database to do the computation if necessary.

So with constraints, we'd instead of just having say validation at the form layer, you're able to make the database have those, and then that feeds back up to the form layer now, which is super cool.

But then to have constraints and then database DBs.

Uh database defaults as well, that's like ah, yeah, brilliant.

Yeah.

Um there's a PR open for that, but I think it needs a bit more work to get it over the line.

Yeah.

That would be cool as well because it would save like this giant cost that we often pay when deleting in Django, because Django pulls everything in itself before it deletes it.

Whereas just letting the database do that work and clean out the disk is a lot faster.

And then your third exciting one?

Python 3.12 added this and now Django 5.0 exposes it through its wrapper.

That's just a great way of seeing like what are your slowest tests.

You can say dash-durations 10, it'll show you your 10 slowest tests, and then you know where to work if you're trying to uh speed up your Django tests.

Adam has a book on speeding up your Django tests, so you should uh check that out if you haven't seen it already.

Oh, cool.

Thanks.

Um, but it have you started work on the update there, or you that's sort of later on?

I do that, but I haven't pushed those updates yet because I'd like to compile with the latest Sphinx and whatever so the EPUBs and come out in the best way they can.

That has been an issue in the past with older versions.

And that oops, yeah,

Yeah.

Like you it's it's sort of like a chore to put an actual book out, and so there's all these updates that if it were just a website, you could just kind of do.

Yeah.

Um yeah.

Yeah.

But you you you smartly avoid all that.

So um yeah.

So yeah, so maybe that's

one but this one.

So you know how when you render a form field, it's got like the field that the actual input, like you know, the text input where you enter your data, but it'll have a label and then it'll have errors, and then it'll have help text and all those things.

And um that's all great, but when you if you need to customize your form template, having to do all those for each one is a kind of bit of a pain.

So um bound field now has this as field group helper, which will render that a specific template for groups them all together, which means if you want to customize your form layout, you kind of just do field as field group, field as field group, and you do the surrounding markup.

Maybe you want to use a field set or whatever.

It just makes writing those custom forms um that much smoother or that much quicker.

I'm really I'm excited about that.

So anyway.

But I would recommend that if the docs aren't fully sufficient, as they were not for me, but his talk made it very clear.

Yeah.

So you know, let's let me have the naive.

No, come on, easy.

Get it together.

Yeah, let's make the puns.

Maybe what's the quick why is it worth its own book of performance enhancements?

Sure.

We all use it, but what what more can there be beyond you know, git status, git add, git change?

I think for a lot of us, like, I mean, git is git is not the work, right?

The work is like building a website, and it's a thing that's there, that's useful, but it's also like in the way of each time you make a change.

So I think um it naturally becomes something you learn enough to get going, and then everyone like stops.

I think that's also a problem a problem from the Git docs perspective.

Their docs are incredibly dry, low level, use a lot of terms, they mix up terms because there's like three different names for a commit.

Um so it's quite hard to do.

I meant to say commit, not change.

Um so like I found that like there's this kind of um genre of hit tweet where a developer shares, like, change this one thing in your git config, and then it gets like 10,000 likes because, like, oh wow, that just fixes this thing where I had to annoyingly type a command every time.

And I just kind of like kept seeing these, and I like I changed my own config over the last nine years I've used Git, 10 10 years.

Um but there's no like central place I found that would explain all these to a new person.

Like you can throw them at your git config, but that's not really a help.

Like, what does this actually do?

So this book is basically my attempt to compile all of that stuff that I've seen uh into one series of logical short explanations.

Yeah.

Well well what maybe what's uh what's an ex what's one example of something that you now use all the time that like saves you time, improves performance?

Like what are some of the like what are we doing wrong, right?

If we're just using the main the main big three and like, oh that's enough.

So if you've ever typed git commit with one M, it by default just says, I don't know what you're talking about.

Maybe you meant commit with two M's, but try again.

But the autocorrect feature, you can actually switch it so it like goes, did you mean commit?

And you can just press yes, or you can actually have it go immediately, like there's only one thing close enough, it's commit.

Let's just do that.

So that's like one simple tweak, and that'll actually save you maybe an hour a year, an hour a month.

I don't know how well you type.

Automatically correcting your type out.

I think, ooh,

One of one of your chapters is on aliases, because this is something I find that you know beginners have no idea about.

And if you see someone do a YouTube video or something, everyone has a slightly different alias, and they just go the speed of they just blast through, and it's completely uncomprehensible for a beginner.

Um so those are very exciting, and like maybe you can tell us about that chapter because you know, like for me, like I just do GS for get status.

You know, all these little things, to your point, they they do save you real time, but it's just like how do you learn about them other than peering over the shoulder of someone doing it or seeing some random video?

Um, there's like two kinds of aliases I cover on the book.

There's the shell aliases and the get aliases.

So shell aliases are set up in your bash or zsh uh config and they can map to any command.

You can basically say, for this, when I type this series of characters, actually do this.

And that can be five commands in a chain or or just one command with a bunch of arguments or something like that.

Um in the book I actually recommend pulling in OMIZ shells aliases, even if you don't use OMIZ shell, because they're a curated standard bunch of aliases.

Um and I've I've helped actually contribute to those in the writing of the book.

But uh yeah, they they've got about 300 aliases, but you probably only need 20 to 30 of them on a day-to-day basis.

But if you spend the time just to learn those, then you could go way faster.

You'll be typing like GC instead of git commit, gc exclamation mark for git commit dash dash amend um and so on.

Um the other kind of alias is the git alias.

That's something you put in your git config, and that's where you have to type git space and then your alias.

That's more useful for wrapping up slightly larger commands with a uh a a single word.

Um so I have one in the book that's like git switch recent, which helps you switch to recent branches that you've committed to.

It lists them all in order and shows a setting.

Basically, I just couldn't work without it.

It's like git PR and then the number of the PR and it just goes and fetches the branch and and whatnot.

And without that, you have to do well, what's the URL, what's the you know, what's the remote?

It's just a a lot of faff, whereas you know git PR number, damn, and uh yeah.

I literally couldn't Yeah,

Hit tweets.

But yeah, so just giving love to aliases.

Yeah.

And you know, I just you just forget what's n w what we know, and it's like, well, how would they actually learn that, right?

There's no an aliases or one of the ones.

Um that huge time saver that you may not know about.

And yeah, and as you said, also very accident prone.

Like you just that that's the thing that when I first got into coding a while ago now, I thought that coders had like perfect typing skills, and now I realize they're like the worst.

It's just the hit tab and have all these linting and tools, and you know, it's it's almost worse than than writers with uh grammar.

Yeah.

You gotta do it perfect, perfect.

Yeah, no, there's all these.

Like it's really helped this book.

I was finding I wasn't putting commas in the right places.

Well don't you're legal comma Nazis.

Yeah, the com the commas, the commas thing is really, you know, to I that's the one area where I consistently am like, no, no, no, no, no.

I I don't need a comma around every every comma, single comma word.

But anyways, well maybe that ties in.

So one of your our sections is book-driven development.

I think you've talked about this before, but what is this concept?

How does that manifest for you?

Because uh not how I write my books, but maybe I should.

And all the things I'm talking about are open source, so it means I can dive in and improve them in some way if I spot something on the way.

Um I've this is how I've become a Git contributor through this book, uh, which is a bit of a gauntlet to get a patch actually into Git.

It's not done on GitHub, it's done on the mailing list, it goes through your email inbox only.

No, no.

In comparison.

Because that was the original workflow, right?

It was designed to send patches to um Linus, basically.

And how did that go?

I mean, how how what's that like?

It has a command to format a patch and then uh you attach your text to that and it sends us an email using the SMTP setup on your laptop on your computer.

I didn't use that.

Uh I didn't want to like s set up all that.

So I used this thing they added uh a few years ago for making a pull request on GitHub and converting that to an email.

So I still had to chase up my comments on email, but at least I got to submit it the kind of normal way to begin with.

Um it's alright, like receiving comments over email is pretty much how I'd use GitHub initially anyway.

It's a bit all over the place reading an email that's like got strips of your text of your patch with comments underneath.

Uh it's a little bit harder to go through.

You can't just check the box, done that one, okay, resolve conversation.

But functionally it's all similar.

Um, GitHub's just a much better UI for doing that than plain text email.

Uh that's the other thing.

Getting an email onto listen, it has to be plain text, so you've got to go check a box on Gmail or whatever.

And if you don't send it plain text, you don't really get an error message like oops.

Okay, Carol.

Anyway, I just wanted to know because I did I I was how did that come up?

Somebody tooted at me about how this was the this was the one true way.

And I was like, okay, I've never done

it, but maybe it is.

It's okay.

It's it it it it's functional and that's all it needs to be.

I think it's good for the Git project long term that it isn't tied onto GitHub or any other provider.

Yeah.

A sort of well, what is the alternative?

What happens if GitHub becomes somewhere we need to leave?

Are we able to?

And every year they do something that causes another wave of people to decry that this is the final straw, but it hasn't actually been yet.

Um yeah, I think it'll be interesting what the future is for Git and Git hosts.

I think Git will outlast GitHub by some margin still.

Um and I think whatever comes next in terms of source control will be one of these Git compatible tools that still uses Git as the back end for storing it and just presents a nice uh command line interface and whatever.

There are a few in the in the works out there.

Like how does Git get replaced or something?

You know, like what what what could it do that it can or what structurally are there any th obvious things structurally that it if they're gonna redo it now from scratch, you would be changed about its architecture or just how it's used?

Um I've uh uh dived into like recent changes in Git.

They're all about like modifying these file-based data structures to scale better.

Whereas Fossil, which is a competitor, that's the SQL Lite source control, that stores everything in SQL Lite.

And so scaling that would be a matter of optimizing a few SQL queries.

You don't need to rewrite all the data structures, um maybe optimize some tables, but that's a very well-known kind of space of like how do we get SQL databases going faster.

Whereas Git's doing a lot of low-level, okay, now we need to build a special index file for this particular use case.

Now we need to build a special thing.

And they're absolutely never take on a dependency like SQLite either, because they want to work on every platform that only has a C compiler.

That's a little tip you have.

Like what can we say about that?

No.

No, no, no, no.

So git reset will take your take your working tree and reset it back to how it was before you made some horrible mistakes.

But I don't I don't know the keep flag there.

It's the way I would talk about it.

One is it can unstage a file.

So you've clicked, you've done git add on a file, it's the opposite of that.

Um but the other thing is if you pass it a flag and a commit uh ID or name, like a branch name, it will move the current branch to point to that one.

And then people typically learn about the dash-soft and the dash-hard options.

The soft one, it keeps the changes.

So you can like git reset soft to a previous commit, but that will keep the files in the current state.

So you're ready to re-commit those changes.

Perhaps you meant to put them on a different branch, perhaps you meant to make some tweaks.

So you can redo the commit you just did or the last three commits you just did in one or something like that.

And then hard is for when you want to like throw away changes.

It moves the current branch and doesn't keep the changes.

The problem I have to do.

I just see uh hard hard is the one where I'm like, oh my god, like I get a little nervous whenever I do or try not to use it, but sometimes you just get lazy.

Like it's this thing that you're like, it's gonna throw away everything.

Um so git reset keep is like a better version of hard because what hard does is it not only moves the current branch to point to some other commit, it also throws away everything that you haven't committed yet.

It's like a side effect that you don't really want most of the time.

So like if you use dash dash keep, then like you can have some like test file you've modified and then reset to like say you're resetting to origin slash the current branch to undo whatever fixes you've attempted locally to go again.

So you can do that and keep the working changes.

And I I think this is quite important because the only data that Git doesn't let you recover is stuff that you haven't committed yet.

So if you have local changes you haven't committed, keep keeps them around, whereas hard throws them away.

Whereas if you could do this.

So if you create a folder for like static files, like images, and you don't have any images yet, and then you try to track it or or do anything with it, you have to do this like dot keep or just put in a dummy file, right?

Like that's that's something that has tripped me up in the past, and I get questions about that.

People, yeah, if if it's not, if it doesn't have anything in it, git's not going to automatically track it if it's empty.

Like uh Git's Git's data model only tracks files, and that kind of makes sense if you think about it, because you wouldn't want it to like keep around empty folders that have had all their files deleted.

You wouldn't want to uh have to worry about file folder permissions as well as file permissions, um, things like that.

Um yeah, so I did write a blog post about this.

I guess that's why you're asking a question.

Or no?

I just have a thing in my book book on this, and it causes problems for people.

And so that's why I added one of the updates like dot keep or blank files, because uh right.

Which is to say it's a common thing.

Oh, yes?

Okay.

Yeah.

There is this uh practice of adding a f a blank file called dot git keep or something, but that still requires you to

Yeah, I I swear to god, I I didn't see this.

Um, but you can actually do this by just dropping a gitignore file in the folder you want to keep around and writing a couple rules.

The first rule is star, meaning ignore everything in this folder.

And the second rule is exclamation mark.gitignore to say, but don't ignore this.gitignore file.

Right.

I actually I was thinking of the an older, like an older.keep, not not not git keep.

But actually, um something you promoted, which um I was like, oh yeah, yeah, that's important, is the work that um Brett Cannon just did on Python 312, right?

We're gonna have automatic um gitignores for the virtual environment, I believe.

Um very happy to see that got uh accepted and merged.

Um yeah, Python's virtual environments uh if you use the virtual env package, which is was the original way to create a virtual environment, that added at some point this feature that drops a.getignore file with just the rule star, meaning ignore everything in this directory into each virtual environment.

So you can't commit those virtual environments and push them to GitHub, which is a classic beginner way of duplicating code.

Uh and now that's been added for Python 330 in the Venv module, the built-in version of virtual env.

So that will save a lot of Git environment, uh virtual environments getting committed.

And it'll also mean we can all remove a rule from our gitignore files from that point on.

I hate just copying.

I don't I try I don't like to cop just copy over the Python one from from GitHub because it's so long, but it's there's always like 10 different things every new project I need to just put in by default.

Like um, and maybe Jenko could do that.

Cool, that's controversial.

Is it is it's not

you want to have?

So especially okay.

I haven't I haven't uh

but like

But actually, a lot of people get upset about it, it's like no, okay, we just won't do that.

So Django's um default um uh git ignore is quite minimal, blah blah blah.

I don't think it even has one in the default template, and you know, and but even in the like in the repo, we don't put every possible git ignore in there.

So, you know, you might use um PyCharm and I might use VS Code, and you might use you know some other one, and so uh we don't put like the git ignores in the Django repo for every different IDE.

We say, look, use the local git exclude option.

Now, Adams, you've got a different take on the git exclude.

You you saw I saw a post you did a few weeks ago on.

So if you're using PyCharm, ignore PyCharm across every repo you ever work on, and then don't bother any uh adding stuff to every repo you work on.

Um that's in the book, but it's also a blog post.

And I just that's why I thought you were gonna do a book on type Python typing, because you just you know a whole series of blog posts on typing.

Well, oh Adam's gonna do a book on this, and you you you didn't at the time, you know, whatever reasons.

But like you've you've blogg quite a lot to to um what first draft it or to to think through your ideas, clarify your ideas just for fun?

Okay.

And then you phrase it exactly as the title of your blog post because that's how you think, right?

I find that, right?

Even if it's a topic with lots of stuff, like I always, you know, future me phrases it like past me, and then I'm like, oh.

Um I guess

Like if I'm about to make some um project-wide change on a client project, um, I'm always like, hmm, I should write up exactly what I think I'm about to do, and then by the end of it, I've got a blog post because I've like found all the potential flaws and gone like, okay, here's how you use this tool in Django.

Here's the problems that I found doing it.

So it's

Like, um, I mean, let me just pick one that I think that you took over core's headers.

Like, you can't really do most APIs without this.

Um like what I don't know, talk to talk, I guess talk to me about like what how do you manage all that?

How do you how big a burden is it for you to manage things like that that are just core pieces of the infrastructure of Django?

And then I know you have some newer, some newer ones as well.

And one issue that always frustrated me coming into the Django ecosystem and working with it for a few years was that these packages were sitting there, they had a lot of stars, they had a lot of downloads, but the maintainer wasn't around anymore.

The pull requests were piling up, the uh uncertainty had added to like, am I gonna be safe upgrading to the next version of Django with this package?

Oh, it seems to throw a warning, maybe it has a problem.

How will we ever fix this?

Um I just decided to like carve out my own little niche of like the packages I own.

I'm always gonna try and keep them up to date for Python and Django.

And maybe I'm not like super active on adding features or um making them like more modern in some way or another, but I want to keep them working.

That's like my baseline.

And to reach that goal, I've I've like normalized them all to like a single uniform template, and then I can script editing them.

So with the Django 5.0 Alpha, I decided to test them all.

It took me about 60 minutes of work this morning to actually add that to the 16 packages that I have.

I was like, yeah, yeah.

And I you mentioned before, like I think maybe the conference, how you did that because otherwise you just couldn't.

Like it's just such a it's too much.

They've gone for poetry rather than setup tools, they've gone for testing with Travis or still using Travis when Travis has stopped working, or they're all in this kind of like landscape of different tooling that is very hard to navigate.

And I do go and make you know new Django version pull requests to packages that my client projects depend on, but it it's a lot more work figuring out where all the pieces are.

Like where do I write Django 5.0?

Where do I write the update on the docs?

Um, so yeah, keeping them uniform is like my secret weapon there.

I took a Django filter.

Why?

Because I was using it, it was basically unmaintained.

I needed I needed to know it was going to work.

Same with Crispy forms.

I was using it in projects, it was basically unmained, it was going to break.

And you know, somebody had to take that on.

So I took that, you know, and so on.

Um, you know, that was how I did it.

I look at you and what you do with the number of projects you maintain.

I'm like, yes, that's that's the way.

So slowly, you know, it's not something I'm gonna do all on the weekend, but slowly, okay, can I systematize slightly more so that those small differences between the packages slowly go away?

And then this what's this tool?

All repos is the tool that you use, right?

I use one called MyRepos.

There is all repos.

Okay.

I I wouldn't necessarily recommend my repos, it's right, okay.

Just a way of running shell commands in each of many directories.

Um so I need to get to there, I'm not there yet.

But you know, yeah, mostly it's like, okay, we're gonna use talks, we're gonna use GitHub actions, we're gonna declare the talks file this way, you know, that sort of thing.

And there's just so many.

I mean, I, you know, you wrote a book on improving your Django developer experience, but you know, when you just don't have all the tools that we we have and set up, it's just like, you know, it's like one hand behind your back, it just oh all you know, don't having pre-commit.

Like, I mean, it's just hard because there's but yeah, there's your there's your book, right?

It's just like a a bunch of setup that takes time and like why am I doing this?

And same with you know optimizing your Git, right?

But once you do, you just don't realize how much faster you can go with these tools.

Amen.

Well, I just wanted to ask you in the notes about the um Git book.

You've you've got this um you mentioned Pigments Git.

Now hi that's for highlighting, right?

So tell tell us about that, because that's that tweaks my sort of what's that?

Um I think GitHub used it even until they made a Ruby version of the same thing.

Um but uh yeah, Pigments is like got a lot of highlighting rules.

It can highlight Python code, shell code, like a hundred other languages built in, but there's nothing for like Git related files.

And so I was finding that my Git blog posts and my book were very dreary, that it's all black and white, even when the editing is.

Yeah.

It's already about git.

So I I wrote something that tries to restore some of the colour that you would see when using Git or using um Git syntax highlighters in your editor for things like the commit message file.

So it makes the book a little bit more realistic and hopefully a bit easier on the eyeballs.

I f I forget.

I'm not sure if I see that.

There you go.

So I've written a few small extensions that do what I want, and sometimes if I've got some large refactoring, I'll write an extension that does a few different editor commands for me.

So it's not quite the same as like just regex replacing everything in your code.

You're stepping through still, maybe you have to type something at each step, but that's a cool middle ground, I think.

I think I wrote a blog post on this because I was fiddling around with it for a reason.

Um you've written a bunch on this.

I think, and there's some stuff on Git and pre-commit.

Like what would be your little sound bite on that?

Like what maybe for people listening, what is pre-commit and why is it you know worth a mention in your book?

Um I've actually written a chapter on it in both the Django DX book and now the Git DX book, which is much less Python Django specific.

The cool thing about it is that it's it's not just a way of running tools, it is also a kind of package manager.

So you can throw in a tool that uses the Rust or Go or JavaScript or Python toolchains, and the user does not need to have those installed.

It knows how to bootstrap entirely each of these programming languages, package managers, and then the tools from scratch.

So um very easy to throw in one extra tool that is maybe not something that you know in not using a language anyone in your team is using, but it just works.

And yeah, it's stability and flexibility, the sheer number of tools, yeah, it all adds up to like a pretty good developer experience.

Do you like Ruff or are you still on the Flake 8 bandwagon?

I know you have some new Flake 8 uh packages you've been working on, but

Um I use Flake 8 still.

I've never had the need for like extra speed.

Um I think the unification aspect is very interesting and probably will help a lot of projects, especially if you're getting to a larger scale.

Just keeping everything managed.

We'll see where it goes because I'm more of a fan of like open source community managed than open source company managed.

Because I so I I'll put my hand up.

I'm you know front of the line for I'm quite slow to change my tooling choices.

You know, I'll I'll be second last off the boat quite happily every time.

Um, and that's fine.

How do you because I basically I'm just not interested in taking on the churn.

You know, if you get into every new tool, you're changing tools three times a year, and it's I just the time saving is never worth it for me.

That's that's kind of my natural my reaction there.

How do you handle that kind of tool change yourself?

How do you you know how do you balance between the considerations of oh, I'm spending a lot of time looking at tools and oh, this is actually a better, this is a step forward.

Um, but I'm also very happy to go add new tools.

I guess part of what I do is is helping companies add tools.

So I've added flaking

several projects

Is there a typical type of project you get brought into?

Is it like everything's on fire?

Is it like everything's slow?

Like is there is there kind of a bread and butter, or is it, you know, hey, we need someone who really knows this stuff?

Um I've helped a few companies this year like just improve their DX tooling in some way.

So that might be setting up pre-commit and all the tools for the first time, or it might be like updating things and uh writing a Flakeate plugin for logging after I was auditing the logging setup for my client Silver.

Um, one client uh this year asked me to improve their startup time because I'd written a blog post on how to improve a project's startup time, the time it takes to import everything before Django actually does run server or shows you the shell or whatever.

So I could show very obvious improvements there, like doing this thing saved a second, doing this thing saved five seconds.

If you do this thing, you know, that's the classic consultant move.

If you do this thing,

yeah, well no, you know I do yourself.

No, fair enough.

Good.

So uh, right, like I mean, if we all look to each other's code, well maybe I wouldn't help as much.

But you two would definitely like add a lot of insight, but it's not often done unless it's like a new team member or you have that external gaze, and there's just stuff littered every right.

I mean, there's just not always hard tr hard stuff that is just unawares because you're busy doing the thing that you're doing.

Yep.

Um, I just want always wonder if there's any way to improve that.

Or I mean, even something as simple as like I'm in Boston, there's all these doctors, like surgeons, you know, you get trained in surgery for forever, and then you're just solo for until you retire.

And a handful have like brought in like retired surgeons to just like w watch them operate and like you know, everyone needs a coach basically, um, in any field.

And it's you know, in coding, you don't always you definitely don't have that.

Um I don't know.

A vague thing I've thought about.

Like, is there a way to do that?

I guess the answer is you hire a knowledgeable consultant periodically to come in and be like, hey, like this is what's changed, and also here's these obvious things you're doing that could be improved.

Um if I like look back through all the things I fixed in all the projects, there's a bunch that didn't quite make it into blog posts or a bit nebulous, but definitely something to check when reading code.

Um that's your retainer, you should have you should have an AI, AI of yourself, Adam, uh, you know, Adam code pilot.

What what what else can we talk about, Adam?

What like what are you working on?

What do we or Carlton, you have well no, I

So I've got Adam in the room.

I want to ask, come on, so Django 5.0 just out the door.

What's on, you know, your steering council member, what's on the what's on your roadmap now?

What are your exciting things that you want to look for us to do over the next you know, 5.x series?

So or if we could wave a magic wand and change one thing, what would that be?

That makes it easier.

Um same thing.

And that changes the prefetch behavior from prefetch uh well when you access a field that wasn't fetched in your query, like a foreign key, Django by default fetches a single one.

It changes that to fetch that field for all of the instances that were in that query set.

It's a clear performance win for nearly every situation.

Nearly all the times that you fetch a query set, you're gonna do something with everything in that query set.

And uh last year I had a discussion about a way that we could get this in with Simon Charrette.

And I was about

Um it's a big one because the idea is not just to like add this one behavior, but to add at least one other, which would be, you know, anytime you access an unfetched field, like just error, which is necessary in the async case because you can't do a database query on attribute access.

But it's also something that several packages have created in in third-party cases, Django seal, Django Zen queries, they're both

I just wanted to

So in core, it would be nice to have it that you could tell the ORM actually do this, and maybe it'd be a context manager or just an option that gets changed.

And you know,

And when I was on the board, I was always like, no, no, no, no, the board can do it, like let's like we can raise the money.

And I have to say I've gone full circle to like, you know what, like uh the DSF has enough to do, and the cool you know, if people want it, maybe maybe a Kickstarter or something like that isn't the worst way to do it, because it's just to have it within the the meat grinder of Django machinery is is probably too much.

It'd probably get in the way of things.

But at one point I thought, oh well, the DSF can raise money more easily than a Kickstarter or something could.

And yes, but then you have all the friction of a community, I guess, as opposed to just doing a great new feature.

I think you've softened on that sense that you had the PSF pays for coding, right?

They looked into it, they said it's fine.

Um, so you know, if there were any problem, we could just point whomever at PSF and they could deal with it.

Uh yeah, I don't I don't I don't think it's a restraint.

I I don't I don't think that's the I think that was often used as a reason why not to, and um at least I'm pretty sure the current board know that certainly knows that the PSF is doing it.

It was like, no, we've had legal advice such that um you are a community manager, um, you can, you know, you can volunteer, contribute to Django as a volunteer, but you're not your fellow role is not that.

Um now that you know since that that that discussion with Python has evolved.

Okay.

I think that advice was a very conservative take by someone at the time who wasn't actually in the tech space, and then it was treated as gospel.

You know, we want to be conservative.

That's that's pretty fine.

Oh no, we we sh we didn't like that answer.

Let's just go with this one that we made.

No, but but this was literally like

And I was like, well, you know, you could you you could do something.

And and yeah, I think Kickstarters or something like that.

Like, I mean the question is should do we need to vote in any way?

Like just send around like, hey, here's like five ideas, or you know, but the problem really is you know, how do we get the time of Adam and some people

Well, no, no, no, carry on.

I wasn't I was putting my finger up not to interrupt.

I mean, the money to me is easier than the community agreement and the people who can actually do it, finding the time to do it.

Um, and could we arrange that?

And there's keenness.

Oh yeah, I might, you know.

So if we could organize that and get in a space together, that would be an amazing job.

Like, and yeah, they don't have to be attached to the conference.

Yeah.

Um, well, I think unfortunately we're coming up on time.

Adam, we're gonna have links to everything.

Is there anything else you want?

Uh currently you can pre-order the book, right, and get a discount.

Is that right?

When is there an official It's

You get 80% of the book, and then you open up some pages and they say to do.

I've written up to 90% now.

I covered the two big bits that were left, which are git blame and git bisect.

Um as more advanced combines, I taught them from scratch rather than just being like, you know, get blame, right?

Well, why don't you just turn on this thing?

Um it will be done.

I don't know.

I'm not gonna commit to any timeline with a young baby in the house, but it's it's coming together.

Well, thank you so much, Adam.

It's always a pleasure.

People should check out his work if you're not already using it.

Um and DjangoChat.com, right?

That's our usual going out.

See you next time.