Transcript: Improving Django - Adam Hill

Hi, welcome to another episode of Django Chats, a podcast on the Django web framework? Still a web framework.

I'm Carlton Gibson, joined as ever by Will Vincent. Hello, Will.

Hey, Carlton.

Hello, Will. And today with us, we've got Adam Hill. We're really excited to have you on. Thanks for coming on, Adam.

So we were just talking offline about your podcast, Django Brew. How's that going?

So my friend Sangeeta and I went to it and I was just like, hey, we should start this podcast and talk about Django because there aren't enough of them floating around.

And so it turns out that scheduling and actually making time to do it is challenging.

And then editing afterwards.

Editing afterwards is also time consuming, but we have put out a couple of them and they're really fun to do.

I don't know if anyone listens to them. That's not really the point. The point is just to chat.

I listen to them.

Okay, great.

And I'm like, well, sample code with the episode, that's a step up.

You know, we have bloopers at the end, which is honestly my favorite part because it just shows how silly.

We are and how bad we are at this.

But yeah, it's been pretty fun.

But the other day I was asking on Macedon if anyone knew how to make the editing a little bit cleaner and easier.

And actually, I think Will, you and a couple other people chimed in about Alphonic, I think is how you pronounce it.

And it's sort of like a AI way to get rid of all the filler words that I am very prone to say, like ums and ahs and things like that.

So.

So we've been using it from the beginning and it's still, he's still working on it and it's still great.

And I still, I'm like, I still need to pay for this because there's tools built into Riverside and other things, but it's still better.

But it's like, it's almost like pre-AI, AI, right?

Yeah, yeah, yeah.

Because it wasn't.

It's real.

Yeah, it's real.

You can tell, right?

I mean, it's better.

It works great.

We also use Riverside and we were trying to use their editing and it was pretty janky.

It didn't work as well as I wanted it to.

And so, but this Alphonic thing works great.

So.

Yeah.

June, 2019, episode 18.

Carlton, you remember that seven years ago?

I remember the recording, but like seven years.

I can say now.

I remember the recording because he actually.

Had a bad microphone.

It was like the one time we were like, okay, if anyone like, just like, don't give a whole

speech and for whatever reason it was slightly off.

I mean, not that he doesn't know audio, but I remember having a sense of like, oh, I was

slipping there.

Yeah.

You know, I had to do a lot of.

Yeah.

Probably now it would handle it, but I had to do a bunch of, I was doing a bunch of EQ

stuff.

Anyways.

Yeah.

It's, it's great to see the podcast.

I mean, I'm curious how your journey will go.

Cause like when, when we started off doing this, I was trying to make it like NPR here and there.

Yeah.

Yeah.

Trying to make it like NPR here in the U S and make it just perfect.

And then you just slowly kind of let go of things.

And, and actually Michael Kennedy of talk Python, he was great at telling me just where

that line is.

And, you know, you still need to have a high enough quality.

It's not distracting, but people, people just want to hear what you have to say in a non

distracting way.

And if, and they want to have another episode, not have you spend 20 hours on an episode

and then burn out from that.

Yeah.

That makes sense.

I think is the, is the hard part.

Uh, cause I have a lot of stuff going on, which I will probably cover some of those

things, but, um, you know, making time to, to do it.

And I think the, the podcast that I listened to the most are on a weekly cadence.

Um, but I just can't do that.

And that's just, that's really hard to do.

And I would say too, like I, when we switched to Riverside this fall, I thought I hoped

that, Oh, we'll just do everything there.

And it'll be more efficient.

And I think I put out one episode like that.

And then my wife was like, it sounds different.

The audio version.

Cause it didn't sound as good.

Cause I didn't run it through a phonic.

I didn't do all the tightening I do in garage band.

So I still do both now, which I think is worth it.

I'm sorry, Carlton, you were going to say something.

that conversation for any project that you have going, be it a podcast, be it a blog,

be it an open source project, whatever.

Yeah.

You have to do it in a way that is sustainable.

And, you know, it can be the same.

If you've got an Instagram account, you, you know, you see people putting so much effort

into a 30 second video.

It's like, can you really do that?

Or can you do something that might not be as high production value, but you, and it's

sustainable because in the end, it's no fun if you're killing yourself to trying to produce

something that's, uh, you know, against professional production teams when you're a one person,

you know, one or two person bad.

This makes me think about, um, Django Unicorn.

Which I spent, well, I started in 2020.

I just looked back and I was like, oh my gosh, it's so long ago.

But, um, so basically it is a interactive component library for Django.

So you can make, you know, things that kind of interact and you don't have to write JavaScript.

And it started with just like a simple idea.

Um, and then, you know, I consistently made changes to it and made it better, but at some

point, probably a couple of years ago.

I kind of burned out on it because it wasn't like a sustainable thing that I was, I was

doing and it got popular enough that, uh, people were using it in production and then

were upset when there were bugs.

And I was like, well, I got, you know, a life and a job and stuff.

Uh, so I think that really rings true, which you're talking about Carlton for the, for

the open source maintainers, you know, just being able to, um, have something that you

can.

You can just be consistent with and, and not burn out on it.

It's, uh, it's really tricky, I think.

So, I mean, you've got a million projects and let's talk about some of them, but like

Django Unicorns, probably your, your sort of biggest and one to tell us about it.

And, you know, where, where is it at the moment?

Cause I see, I've seen recent activity.

maintainer.

So trying to get some help and, um, oh, I also started the process to get it moved into

Django Commons, uh, which is sort of like a community organization that kind of helps

with Django libraries, uh, because I was kind of, I was getting frustrated.

I would say of just like all the bug reports and, uh, just feeling responsible for this

thing that, you know, I put out a lot of stuff and mostly I'm just prototyping.

And trying things out.

I just want to see how it goes.

And this kind of took a life, uh, took a, uh, took on a life of its own.

Um, but, uh, there's someone from Django not space, uh, Johan and Johanan, and he reached

out and said that he would help me, uh, maintain it.

And so now there's a lot more activity we got.

Um, he has a roadmap for, uh, 1.0, which I'm really excited about.

And he's squashing.

He's squashing a lot of bugs.

So I think one of the lessons in here for me around just being able to maintain these

big projects is having other people help out and not feeling like it's just on me to do

everything.

So I don't know if you felt like that with Django template partials, Carlton or, or anything.

had a fixed, we had a fixed scope, but, um, you know, we said on the, um, the last episode

about, um, you know, there's no way that I could have, um, I know there was no way because

I started the project several times was have done the work to get it into Django without

the Google summer pro project.

So I did need him for that sense.

But with other projects I've worked on, um, you know, channels I've tried over the years

to bring people on.

I've had people come on and they've, they've stayed for a while then disappeared.

And that's something that is like, I'd really like it if we had, we have got an active community

around it, but it's not quite how I want Django filter.

I've looked after that myself for many years because it's just.

The right size for me needs very little updates and whatnot, but rest framework, I really

felt that, you know, it was kind of stuck.

And now that's moving into Django commons as well for similar reasons.

I think the bottom line is you've got your project.

Are you really going to be maintaining it by yourself in 20 years time?

No, you're not.

So you're not going to be answering every issue.

You're not going to be interested in merging the pull request.

So you need to at least have some idea of, well, can I be open to new contributors?

And I think Django not space is just phenomenal for that because it's bringing youngsters

into the community.

And like getting over those first few steps, which are really hard, it's really intimidating.

You know, if you turn up with zero experience and to a repo, well, you're going to struggle

to get the mentorship you need there because the maintainer probably doesn't have the time

to take you under their wing.

We have generally people from Django, not space who come in and do the updates to Django

where they list, it's usually double digit and, um, and I'm so thankful that, you know,

people do that.

And, but I think it's also a great entryway.

It's, you know, it's easier than some other tasks you can do.

You can contribute to Django, you can get experience.

And so, I mean, that section would not exist without Django, not space and the people who

manage it and do it.

So it's another great thing.

how much is happening in Django and what new things are happening.

And then it's like eight articles and we're like moving some of the next week.

Like it's.

Crazy.

Yeah.

It's like, I think that is one thing that we, as the Django community have maybe not

done as good a job as I would like is sort of showing all the activity and making sure

that people know that Django is evolving and is, uh, continuing to push forward.

Um, so I really, I really love that.

There is like, cause I think Django is quite dynamic, but that's because I'm very close

to the co-base and I see all the changes that get loaded in, loaded in every release.

And I literally every major release, I'm like, wow, that's another absolutely amazing release.

But there's also a lot of frustration or felt or perceived frustration or whatever about

Django moving too slowly, or I don't know what, what are your thoughts in there?

Because, and what can we do?

And I don't know, you might, I know you've got half ideas at least.

I mean, I think.

Part of the, the, have you ever been on Reddit Carlton?

No, I never go to Reddit.

I'd never go there.

Oh, come on, come on.

He won't cop to it.

He's my, my children go on Reddit and I'm just like, they're like, it's the only source of truth.

I'm like, it's not a source of, I'm turning into your kids now.

You know, they take it down, you know, I just, yeah, sorry.

Go ahead.

when you're inside the project, you do see everything that is happening.

Um.

But we, I think historically haven't done a great job of marketing all those things.

And so, you know, I think if you look at the, the homepage, um, it's not always

clear, like when the new releases are now it's on the sidebar, um, or like what the

actual features are of Django or let's say Django tasks now got introduced in 6.0.

Like that should.

In my opinion.

Be a lot of fanfare around that.

And just like, here, here are the new features.

These are the things that are getting pushed forward with Django.

I know there's, um, a social media working group.

They're doing a good job of pushing some of that.

Um, but there are other things that I would expect, I think, um, from a, from a

major web framework, like a, like an email list where we announce new things.

Keep going.

Yep.

Yeah.

happened for, for reasons.

Um, that's fine.

I'm just bringing up, but you know, I do think it would be beneficial for Django going forward.

I mean, I'll give a shout out Sarah Boyce, uh, Django fellow.

She's giving a talk at this, uh, pie charm TV unplug day in about a month that you're

going to be at Carlton and her talk is titled Django has a marketing problem.

So.

We'll do our best to promote that.

Can we, can we show the, you mentioned the homepage.

You've done some work on this.

Can we, can we talk about that URL link?

Is that okay?

I can share it for people.

All right.

So I'm going to put it in the show notes.

Well, I can do better than that.

Cool.

Watch this.

Watch this.

Sorry, audio people, but, but Adam did all this work on this interactive.

We'll put the link in homepage that looks, I mean, just look at it.

Like.

It has everything we want and it's, you know, and I think, you know, why don't things happen?

You know, partly we have volunteers, right?

We have, we have a new board.

We have new people there.

Like, I mean, Jeff triplet is the new president.

He's doing tons of stuff.

I think we just have a capacity problem.

So we all agree or mostly agree on what should be done.

And then it's like, okay.

And who's going to do it?

I mean, I, I think we talked about this on the last podcast episode.

That I was on, which I don't remember when that was, but, um, you know, I think the Django community is great and I love that it's all volunteer and, um, it feels very egalitarian.

I do think it makes it hard to push big, um, big features forward or big new ideas forward because, uh, it's a lot of people have opinions about things and it just, I think it's a little challenging.

I would say, I mean, so, right.

Code.

Yeah.

Code in, there's always a question of how big or small to make core.

You know, if you update the website, okay, well then you're going to be there for a little bit, but then it's someone else's or the community's problem eventually.

So I think.

Like, people who are in positions of authority are very aware of the cost of changing anything.

And I think that, and I speak for myself, too, it can make you a little bit gun-shy to, that's probably the wrong metaphor, but, you know, a little bit reticent to do things.

Because you're also immediately thinking of what's the parachute of obligations coming with any change.

But, I don't know, maybe DjangoCon Europe, we can get people to swap the link for this homepage and, like, put it up for a week and see what people think.

There probably should be some, you know, back and forth with people who are interested and who have opinions about, like, oh, this should be different or we shouldn't change the top nav because, like, now it's too hard.

So, I don't think that I have 100%, like, the perfect solution for these.

I just, I made a Django forum post and I was like, hey, does anyone want to work on this?

And there was a lot of conversation in there and not a lot of actual, like, okay, and this is what we're going to do.

And my personality is wired to just, like, do things and then see what happens.

And so that was my, like, oh, okay, I'm just going to make this thing and then see if there's a reaction and see what we can.

And what we can do going forward.

It's like we've been talking about getting content negotiation into the request object for a decade.

We've been talking about updating the homepage for a decade.

It's just really hard to do because Django is a slow-moving beast.

And on the code side, it's why I'm so militant about just throw it in the third-party package because you can create something.

You can shoot it up.

You can see if there's a reaction.

Whereas if you're like, no, this has to go straight into court, the chances of it happening are, you know, minuscule.

Because there's just so many barriers.

There's so much inertia.

Whereas if you put it in a third-party package, there is a chance that it can get adapted, you know, as Django tasks or template partial shows.

Yeah.

I think it's a great new addition to sort of surface these things.

Because I think a lot of people have ideas about what should be added to Django and what shouldn't be.

And this is sort of like putting it to the marketplace, so to speak.

Of just like.

Are there people who are interested in this?

Are there people who want to sponsor it going forward?

And so I really love that.

Because, I mean, from a steering council perspective, we didn't know it was an experiment.

We were like, we had a problem.

We've got a problem that, you know, people would go to track with new feature ideas and it'll get closed.

It won't fix.

And that was no good.

That wasn't any good for the fellows.

It wasn't any good for the people proposing it.

And so, you know, we came up with this idea collectively and we refined it.

And, you know, a lot of work went in on that.

And it's nice to hear, you know, that you think it's going well.

We'll put a link to it.

I'll tell you the flowchart.

Yeah.

Can we I'll just while I have this up.

You also have this Django API frameworks repo that's relatively new.

Can can you talk about that?

So there.

There was a keynote at the last DjangoCon in Chicago from Zags, I think, about adding

lows around like all the all the use cases of Django.

So you can have Django as a cron, you know, management task runner.

You can have it as a website.

You can have it as an API.

At the end, there were some proposals of like, we should make REST API more inside of core.

So.

The thing that comes up a lot is like, oh, why don't we just merge DRF into Django, which I have opinions about, but it's neither here nor there.

But it made me wonder about all the ways all the different API frameworks for Django because I knew of three at the time.

And so I wanted a way to basically see how they all worked.

And I have benchmarks in there.

I don't know if the benchmarks are super useful.

I will say I was a little, you know,

fended in the podcast with Farhan when you were talking about, oh, benchmarks are only for beginner developers.

I'm like, I think I think they might be beneficial for everybody, but that's OK.

And so I think it kind of comes back to my marketing conversation from before.

It's like.

Like, it's really good marketing if you can say, like, we're the fastest framework.

And if you have if there's nuance to that, it becomes harder to convince people to use Django.

I'm not saying we have to be the fastest.

I'm just saying, like, it would be great if we were, because that is a way to market Django.

We just need to be not loads slower.

And what I liked about the.

Come on, Carlton.

Come on.

What was the.

Recommend?

OK.

So I've got.

A project that I've sort of.

I gave Carlton advice on naming for this.

I've got a project that's in a Google Doc, which I'm like, OK, this could just call it the fast Django project, where I was lining up to do exactly these kind of benchmarks that I've seen Adam doing, that I've seen Farhan doing, that I've seen Andros doing.

Andros, who's the creator of Django Live View, he's been doing these kind of benchmarks as well.

And I was like, wow, that's amazing, because there's other people doing the benchmarks.

I don't have to as well.

I got, you know, am I going to get to it?

Not till later in the year, right?

I'm just not going to get to this at all.

But so to see other people doing it, but then to see like Farhan in particular, he sort of started it.

He picked up Django, was it?

He picked up MessageSpec and just created some serializers around MessageSpec and just by doing that, we were able, he was able to show that Django will run, you know, as fast or, you know, in same ballpark as FastAPI or all the other frameworks without making any other changes.

Right.

And it's like, we don't.

It doesn't necessarily have to be the fastest, but we have to be not loads slower.

Yeah, we just need to be close.

Yeah.

And the big problem with using the last generation serializers is that we're always going to come out low slower because every time they create, they do field lookups and it's just not, you know, that's just not how modern approaches work.

So anyway, I'm really excited to see all these benchmarks.

I'm really excited.

I was surprised when you jumped in, Adam, because I think of you as a front end kind of person and then this is more backend, right?

This is, uh, I thought that was interesting that you mentioned that I don't think of myself as a front end person at all.

I, I do think of myself as sort of like a developer experience sort of person.

Like I just want like a good developer experience, which I think Django has in some places.

And then there are like paper cuts all over, uh, in other places.

So I mostly try to think about like, how can we smooth out the first person who is starting Django?

Yeah.

Or the person who like creates a lot of Django apps.

Like I make a lot of Django apps and I copy and paste the same thing everywhere.

I'm like, this probably, there's probably a better way to do this.

Yeah, no, fair enough.

Why do I say you're a front end person?

Angles?

Can we talk about angles?

Well, yeah, let's get, let's drop angles in at the end of the list so Adam can spin off on it.

But like, you've got your, um, Unsuck CSS site, your Unsuck JS site, you've got, um, Django Unicorn, you've got, and then Djangles, DJJangles.

What's, tell us about that Unicorn.

Yeah.

And you can do a little sparkle hands, uh, after it.

Um, it was, I was looking at Django Cotton and, uh, they have, so that's another component, uh, framework on top of Django, uh, and they had added, uh, a

nice, like, HTML, it looks like an HTML element.

It's like C dash and then whatever your component name is.

And I looked at that and I was like, oh, that's interesting.

Like, I wonder how they, they did that.

And it's basically, um, uh, a template loader that looks at HTML and then converts that to a, a template tag, a regular Django template tag.

So you don't have your, your curly and then the percent, um, Django, you know, normal

Django syntax and as what happens when I look at things and my brain starts firing, I was like, oh, like, I wonder if we could just do that for everything for every Django template tag.

And so that's sort of how it started.

I was like, well, it can be, you know, bracket DJ dash and then include, and then whatever the name of your include is.

And so I started with all the, the Django template tags, the built-in ones.

And if you look at it, it looks just like HTML syntax.

Like you, it doesn't look like Django template language at all.

Um, which I think is kind of nice.

It gives you your syntax highlighting and everything.

It just, everything kind of works.

You don't have, um, like indent and, um, de-dent problems like, because it, you know, normally it doesn't know where things are.

So I started with that and then I have some integrations, uh, for most of the component libraries, like, uh, Django components and, um, Django bird and Django template partials.

And then the new Django template partials for 6.0.

Um, so you can use those as you want to, and then there's like a smattering of other things inside that library.

Just everything.

That's basically template focused.

Um,

ways to call code without making a, uh, a temporary or like a, a smaller template tag.

And I did something around, uh, date filters because in the Django template tag for date is uses like a weird syntax.

It's not like the Python, um, syntax and I understand why, but it still is bothersome to me.

So like I made something for that.

So yeah, it's sort of like a, it's a grab bag of a bunch of stuff.

But it's all all around templates.

I'm, I don't, I never mind it because I could never remember either of them.

So I had to look them up by the way.

So it's like, okay, I'm looking at, I'm looking it up.

It doesn't matter which it is.

So

That's button down.com email software for developers.

Like you, there are hundreds of email marketing software services out there.

And they will pretty much offer the same thing, collecting clean addresses, send out broadcasts or drip campaigns, get analytics.

So you can see what's resonating and what's not button down is designed to hook into the tools that you already care about everything from static site generators like Jekyll or Hugo to payment platforms like Stripe and memberful.

You can hook your site up to button down with just a form element or a simple rest call, write emails and markdown, and then get on with the actual work you're supposed to do new customers can save 50% off their first year with button down using the coupon code.

And if you email support, they'll white glove migrate your existing subscribers and archives for free.

Yeah, fair enough.

Fair enough.

So, okay.

You give it, you.

So with the whole, that whole Django thing, like what, what are your kind of, what does Django need in the front, the front end?

Cause another part of that, um, that keynote that you mentioned from Django con us was that, um, Django needs a better front end story.

I, you know, do we, do we need to, you know, tie ourselves to view or.

React?

I, I think I've listened to you long enough for both of you long enough to be like, I don't think we should, you know, tie ourselves to react or view or angular or some other framework that, that seems like a bad idea.

I do think.

Probably we need.

A way to, inside of core call out to other libraries, other, the way I was thinking about it the other day was, um, you know, there's database backends, right?

So core doesn't need to support, I mean, I know it has like Postgres and SQLite and things like that, but you can have a database backend that is a third party library and it calls out to that.

And that's what it uses.

So there's an API inside of Django that says like.

This is how you deal with front end, um, projects or front end frameworks.

And then it calls out to those things.

Okay.

That's interesting.

Yeah.

I use Django compressor a lot.

It's kind of like the filters, I think, um, idea, but, um, I don't know if there's any, any appetite for having something like Django compressor.

I know there's Django pipeline.

There's a couple of sort of like asset management things.

Um, so yeah.

So core functionality seems useful, but like time does something specific doesn't.

And I've used it with jQuery.

I've used it with, um, uh, the, uh, backbone.

I've used it with Ember.

I've used it with react.

I've used it with sort of web pack with VEET.

I've used it with Elm.

I've used run tailwind through it.

The list goes on and the trick, the trick is it's got this lovely pre-processes setting where you can just add.

Your, your, your, your media type for whatever X tailwind, and then you can, um, give it a command that it runs when it finds that to, to, to run the tailwind backend or whatever it is, the web pack constructor you've got, um, got going on.

And that turns out to be really, really, really lightweight and really, really flexible.

And it's not that Django compressor has to don't have support for react or support for web pack or support for Elm or support.

It's just that you share, you basically shell out to the tools.

And that lovely ability to just define how you shell out very, very, in a very lightweight way has meant that it's been sustainable more for me for a long, long time.

Now, Dan, Dan compressor needs to handle imports and.

import maps and all these new newfangled things that we and um you know es modules that you know

and are now very commonplace that jang compressor still doesn't handle but with given that that need

for modernization it's it's come an awful long way with a very light um api so surely we can do

something in django core which it doesn't need to solve all the things that white noise solves but

there's probably a there's you know a an 80 that django could probably do it's cache headers and

um you know it seems like that would be really useful for most deployed django apps and i think

the the frame that i have around some of this stuff is like what are the what are the third

party apps that i always include in every django application that i that i make and it is white

noise django compressor and there's probably like three or four other ones like how can i make that

list smaller or i think it would be useful to make that list smaller um i think it gets a little

complicated because like that keynote was talking about django can be used in lots of different ways

so uh the way that i'm using django is to make it smaller and i think it's a little bit more

complicated than what i'm sort of thinking about it is there are different use cases you have django

as a web framework for web applications you have django for just running tasks you have django just

for apis and like maybe we don't need to solve all of them but maybe we need a good story for like

different use cases that people are trying to use django for instead of trying to solve like

is that i want the apis battery pack or i want the cms battery pack or i want that you know

whatever i want the react battery pack i think there are standard sets of functionality that

start project which are confusingly named to me because it's it's too many templates um but those

would be the solution for those but it doesn't seem like they have as much um use in the community

as i would expect or maybe they're not as easy to find or something but um i don't know what have

improving the start project command um tom carrick put this forward and it's you know the idea is to

is to improve the story about how you create your own template the story about how you use templates

have two or three you know example templates that are more powered up and have a better start

project template which is a bit more user-friendly for beginners um you know the whole start project

start app add that to start installed apps that that bit of getting very first going we could rub

that away right we can make that you know one command and there's your projects that's ready

so there is a provisionally approved debt for that it just

just needs implementing but like we're agreed that that is a gone i mean this is the whole

they just want something to work and django gives you batteries which are super powerful but you have

to kind of know how to use them so i mean there's been ideas i mean jeff triplett has mentioned you

know maybe there's i kind of like you know to go on adam what you were saying about how we have

back-end support maybe there's like some middle ground between a third-party package and official

back-end support right where you could add flags right so you could do start project dash dash

production or maybe even start project dash dash production dash adam and it's like how you like

to do it or something right because even as trivial as it seems a third party is like just

enough friction sometimes to get in the way of stuff but i don't know it's hard to know like i

mean starter projects i have this thing called lithium now that used to be django x that i

constantly think about where is the line because i want it to be easy to use so right now it's

bootstrapped it's very basic but still very helpful and then there's like what i would use

which is like way more complex but there's definitely at least one grade in the middle

which is you know has white noise has a whole bunch of stuff where i'm like i think 80 percent

of people could use this right and yeah i don't know i guess it's being comfortable with an 80

case and just putting it out there but then people have to find it you know and then you have to

market it and uh i don't know then then we all lose momentum right because the thrill of making and

discovery is just like weeded away by like do i need to market a free thing really yeah that gets

library called uh django new so django dash new because i had seen that there was a project called

fast api new and i was like well we could we could do something like that um so that is

my sort of opinionated way of starting django projects but it is um it's less opinionated

than some of the starter starter projects that are out there um but it's still got opinions

because it kind of has to um but that's sort of that takes that idea of different um use cases

to an extreme which is just like there are flags for web for api for tasks and for one other

one i forget like data or something yeah data worker yeah api data website worker yeah so like

based on whatever those things are it just spits out you know a django a django project um the next

step to me is being able to install third-party apps really easily so like when someone needs to

add in white noise you have to go to the white noise uh manual page or

you know docs and say okay i have to add it to installed apps and then i need to maybe there's

a middleware and then i need to do um you know for some apps it's like oh i gotta go to urls and

which urls do i go to because there might be more than one year yeah like it's just i think it gets

back to that like uh smoothing out the the install process for for new people or smoothing out just

the like i'm ramping up a new django app

um and then i need to do um you know for some apps it's like oh i gotta go to urls and which

i think there's lots of ways that we can make that better and um it's something that i think

about a lot so i mean it's a checklist kind of right yeah yeah i mean like you know pilots have

conferences this year is around deployment and i think it's it's exactly this idea of like okay

like i have a sense of like 80 boom boom boom boom here they all are and let me talk through

them so you have a idea for them but then you need the checklist and then you need to do it

and you know because and there are checks in django um i'd say most people have no idea that

that check exists but you know i want to finally put some effort to being like there's not a lot

of argument around like you got to handle your static assets like a lot of people use white

noise if you don't use white noise you can do something more custom but you know just good on

the list of i don't know it's 10 12 things um at least so people can look at it and see what are

these ones because i think the other issue is a lot of people all three of us create a lot of new

projects and we're not going to be able to do a lot of new projects and we're not going to be able to

i'd say most django developers don't you know they work on the same one for years and so they

don't feel this pain in the same way as you know someone who spins things up for fun or as a

consultancy does that's that's something else i'm very aware of they'll be yeah steering council

members sometimes who haven't started a new django project in years right i mean they're still

working on django but they're feeling different pain points and they're also not dealing with

deployment right i think that's like the quick take on my talk besides here's the thing i'm

the checklist of deployment is also why isn't this more of an issue it's because in a production

setting someone's done it and you're just using it or even you did it a couple years ago and you've

forgotten about it it's not something every time you load up your project you have to deal with and

so it's easily forgotten or not thought of which means that when you're a newcomer you're doubly

frustrated by why isn't it documented why isn't it easier and it's because it's not you know it's

not like fiddling around with your views which i do every day yeah i mean i i burned into my

how do i get this online and i was like oh no there's the same time again in learning how to put

working locally i deploy it and then i go in and like you know i didn't do the command to migrate

the database on production because i'm like wait why doesn't it work you know it's like oh god now

i have to like migrate that yeah do all this stuff yeah if you're not doing it you're not doing it

all the time you lose that uh that sense no okay adam you've got several more projects i want to

needed to or i wanted to basically have markdown files inside of a django app and have them render

as html so that's how it started um i had a lot of

side projects and i would write documentation and it didn't really need to be formatted like

super well and i wanted to just write it in in markdown and then show up on the site easily

so uh there is a markdown renderer inside of there i've switched between a couple but um

that's how it started and then at some point i sort of started thinking oh i could take all

this markdown and i can make a static site out of this instead of being inside of a django app

it would just render out as static html and so there's also a static site builder in there i know

there's a couple different solutions in django um that people have built for for static sites but

this is my take on it um and so it kind of it kind of solves both of those those purposes i don't use

the static site generator as much for my own personal stuff because i almost always am deploying

a django app so i don't use the static site generator as much for my own personal stuff

i just want to render out that that markdown and then uh after that i started playing with

different ways to um have different template tags and uh different ways to like structure

the the markdown so basically in one repo i can deploy it to two different sites and then

have them rendered differently um because i needed i needed

like one deployable but like rendering in different ways so i kind of like build out

this little site framework um but yeah that's that's that's the gist of it so it's like a

still stuck on jekyll for my personal site because i just can't be bothered and some reason pelican

just can't be bothered and i'm just gonna have to try this again because i'm still stuck on jekyll

who is the guy who does the cli the rich and is will will yeah um yeah on twitter at some point

will was like you know i want to use python for my for my static site but you know i don't i don't

want to use hugo or jekyll anymore and so i was like well i mean django django can do all this we

don't need to use python for my static site but you know i don't i don't want to use hugo or

important with sorry carlton i'll just quickly say like i want people to use python and django but

not everyone wants to host a database for a blog you know and you don't have to right because you

can put it on github pages you can put on netlify and so i yeah i'm gonna give this another try

because i still think there's that space like when i can see when i tell when people like oh

you can do it in django but i'm like but then you gotta host it and i just see the like enthusiasm

fade away even if it's like oh it's just her you know some hosted thing lose them but if it's just

drag and drop or github hosting i don't yeah that's a big barrier so yeah i know um emma

and there's a django distill package which is very mature and i think the author there is keen to

you know modernize it and make and and get it in i mean i'll just throw you a softball and you think

there's that you know having django better static site story is something we could do for our users

of static pages it is a little bit different than how i normally think about django which is like

database oriented you know web applications but there is probably a set of people that

that would really benefit from just generating html and i'm throwing it out there somewhere the

something on the socials yesterday about how i'm you know are reinvigorated by rss carlton gave me

a nice reader and i'm like okay i'm gonna put it out there and i'm gonna put it out there and i'm

you know it's like increasingly disgusted by uh mainstream everything and then wanting to focus

so yeah it's right because django obviously i think again most people don't know django has

its own built-in way to generate feeds and i'm sure there's a way to do that in a static site

thing as well and then and then you're there right that's all you need so you got your feed you got

assume it does um i know in cold train i i automatically generate um rss feeds

because it is so easy to do in Django.

Basically, it's all built in.

So yeah, that worked out really well.

because when I started,

I started with a web server and a folder

and you uploaded HTML

and you didn't get a backend thing

until you wanted to use a form.

And it was only when you used a form

that you need some way to handle form input.

So you had a CGI script for that.

But this is why I don't use white noise

because why on earth would I have my Python process

serve my static files?

Because that's what the web server's job is.

But anyway, that's the side.

But we've come so far, it seems,

that now we start with the dynamic process

to do the easy thing of serving template views,

which never change.

And you don't want to run a whole process

to keep serving the same thing time and time again

and infinite.

Anyway.

so current hotness is out there.

So UV rough types,

do you have any hot takes you want to share on?

Either of those areas?

Fine if you don't, but.

although Carlton might disagree with me.

But I think UV has sort of won the Python packaging war.

I don't know.

I wouldn't call it a war.

It seems to have taken a lot of the mind share.

And, you know, I've moved basically.

I was a big fan of poetry for a long time.

And I've...

I've moved everything from poetry to UV.

I've moved everything from black to rough.

And I'm in the process of moving everything from MyPy

to Ty, T-Y, which is the new Astro one.

or that there aren't...

Like, I have my own concerns about the longevity

of those tools and how they're going to play out.

Long term.

But for right now, it seems to be fine.

They're open source.

It seems like they're being good stewards

of those open source tooling.

And so if I need to move back to PIP at some point,

like, that's fine.

It's all code.

I can change in the future if I need to.

But right now, I got some benefits

from moving to those tools.

And I think that has been great.

Which I think is important to remember

because I think we all have various concerns,

but you can just switch back.

before UV was released.

And it looked at PIPMV, Hatch, PDM, Poetry, I think.

So I did a...

Oh, and Rye.

Rye was like a package manager

that was floating around for like six months.

But basically, I was just trying to figure out

where's the future of Python packaging going?

And I wanted to try all these things out.

And after UV came out and I tried that one,

I basically dropped everything else

and I moved to that.

And I do want to say that I really appreciate...

There was an article that came out somewhat recently

about making PIP faster.

And I know that there's a lot of people

who are doing a lot of great work improving PIP

and all the underlying technologies there.

And so this isn't to say those tools are bad

or they're not good or no one's working on them.

It's just that I just got some benefits

and so I moved over.

Can we come to the projects and books phase of the show?

Well, Adam, as our guest, is there...

All we've done is talk about your projects.

Is there another project out there

you want to draw attention to

or that you've been looking at recently?

I brought this up earlier,

and how much effort there was put into that

to make it ready to get moved into Django Core.

And I think it's really solving a problem

that a lot of people have.

So I'm really, really happy that that got pulled in.

And I just wanted to shout out that project.

And all the work there.

I think the other one that I wanted to mention

was Farhan was on the podcast,

so maybe he doesn't need this shout out.

But basically all of his GitHub projects,

I just follow him and I'm like,

oh, that's really cool.

I'm glad someone is doing this.

And I really am looking forward to seeing what happens next

and just following along to see what happens.

And he was on,

but he's been doing all this work on Django Bolt,

which is this Rust-based, super fast Django wrapper type thing.

But out of that came some work on the multi-part parser

and using different Python packages

for parsing multi-part parsers.

So there's now a PR to try and make that pluggable

on the request object so that if you want to,

and if you don't need strict backwards compatibility

with Django's multi-part parser,

you can swap in one of the packages

from the Django ecosystem,

from the Python ecosystem,

so you can just pip install whatever the alternative is

and give it a little wrapper,

use it in your Django request.

And you can get, I can't remember the figures,

but it was something like 30% higher throughput

on parsing large multi-part requests.

So go far ahead.

Yeah, the cool thing is he's working on these things

that are sort of ancillary to core,

but I think he's going to come across all these problems,

which you can solve in core.

And it'll be fun to see if, you know,

if we can move some of those things into core.

Yeah, yeah, no, it's super good.

That's a good, good, good shout out.

Will.

I'm going to shout out La Suite Numerique,

which is this French existing project

of trying to open source

and have non-corporate versions

of all the infrastructure your government runs on.

They're heavy users of Django.

They contribute to Django.

I think lots of countries and places

should contribute to Django.

They should consider having their own versions of things

and it's not the hardest thing in the world to do.

So pleased to see that they announced,

I think publicly they're going to try to switch over,

I think all of it or most of it in the next year or two.

And I would be very surprised

if other countries do not do the same

for all the reasons everyone can imagine.

So cool to see that and cool to see it's Django

and it's using all the modern stuff out there.

Carlton, what's yours?

Very good.

So I'm going to start with Django.

I'm going to call out a project from Jamie Matthews

who's the co-founder at Dab Apps.

We've had him on the show before.

He was influential in the early days of REST Framework.

But he's published an online guide.

It would be a book, but it's online.

It's free to read called Django Rapid Architecture.

So it's at djangorapidarchitecture.org.

And it's basically how Jamie does web apps.

And it's, you know, he's very function-based

about compositionality, keeping things clean.

He's anti-type hints.

He's like, come on, every Django developer knows

that a request takes a response

and it gives back a response.

I'm sorry, takes a request and gives back a response.

You don't need to type in that.

He's, you know, he's got his views.

It features the absolutely amazing Django readers package,

which enables you to kind of compose the exact queries

that you want to make from the ORM.

And it handles the selecting just the fields you want

and it handles your prefetch related for nested queries.

It's just beautiful.

I use that a lot.

So go check it out.

It's a very experienced Django.

I'm a Django developer with, you know,

20 years of experience using Django,

telling you how they do Django.

So, you know, it's worth a read.

Django Rapid Architecture.

That came out a little while ago.

He really, he made it.

Yeah.

Two, three years now.

It's just gold dust.

It really is.

I was going to say, I think it came out

like over Christmas or something.

Because I remember seeing it and,

looking at it and being like,

oh, this is going to be great.

I need to really focus and look at this.

It is good.

I don't, you know, there's obviously bits

that it's Jamie's opinion.

I don't agree entirely with him.

So when we get him on the show,

we can argue about those little bits again.

But yeah, when somebody,

their experience gives you, you know,

this kind of breakdown of how they see it,

that's always worth a read,

whether you agree with individual points or not.

another package you have, Adam Django-FBV.

Which is things around function-based views

and trying to make them not class-like,

but less annoying to use.

Yeah, that's one of the packages I install

So I use it, yeah.

I'm going to, I'll go first.

A River Runs Through It by Norman MacLean.

This is, again, my trend of trying to read fiction.

If people haven't read it,

I think it's one of the great American novels.

It's really more of a,

more of a novella.

They made a movie about it.

But fathers, sons, kind of Hemingway-esque.

Just, if you're in the right mood, amazing.

And I think underappreciated for how good it is.

So, Adam, you go.

That's sort of one of the things that I,

that I tend to do as a hobby.

And I watched a movie called Nightmare Alley.

And it was by Guillermo del Toro.

It was released in 2019.

It was based on a book written from 1946 or 40.

Yeah, 46.

And so I recently read the book.

It's about sort of a scam artist,

I guess I would call him,

who joins a circus and then kind of his,

his progression.

And then he continues to be a scam artist and then sort of gets his come

up and set the end.

But I don't know.

I really,

I really enjoyed the book.

It sort of has what is it is like clockwork orange where they like make up

words, but they don't tell you what the words are.

It kind of does that a couple of times where you kind of just have to piece

things together based on context of what they're talking about.

But yeah, I really enjoyed it.

So.

And well, I've been, I haven't been reading a book this week.

I've been mostly just reading the newspaper but it's not the particular newspaper.

I get the couple of museums.

I get the London.

Review of books, which comes out twice a month and I get the lemon diplomatic,

which is once a month.

And the key there is that they're slow.

They did like, there's no like quick refresh.

There's no today.

It's a month old.

So the articles are quite lump lemon diplomatic in French.

It takes me ages to read as well because I have to,

you know,

I have to actually think about it,

but the,

the articles are in depth.

They keep you,

they keep you up to date,

but you're not on the hook for the dopamine hits and the whatnot.

And we were talking at the beginning of the episode about being

sustainable.

And you know,

your projects,

whether it be running a podcast or an open source project or whatever it is

you do will be sustainable in your news consumption too,

because it is,

it strikes a cost upon you.

And if you are hooked onto the machine constantly,

not only are they driving the narrative,

you know,

what they choose to highlight and what they don't,

but you're paying that with your energy and your life force.

So the end,

it's not necessarily,

you know,

get lemon diplomatic or the London review books.

Don't do it's get something that's more considered,

and step back and,

you know,

it gives you,

give you,

take the time to read it,

but in a more controlled and sustainable way.

That's all.

that's one of the benefits in my life,

Carlton,

when you came to visit me in the U S a number of years ago,

you were reading the London review books on the plane and,

and chortling away about stuff,

which I won't repeat why.

And I was like,

what is this paper?

I'd never heard of it.

And now I've been reading it for three,

four years as well.

And I can strongly recommend it.

It's my slow quest to convert people to London,

review books,

one reader at a time.

Yeah.

We,

we got a couple of people,

um,

George Curtin,

who's old family friend online.

And yeah,

there's a couple of people.

So get them slowly.

that was my recommendation is read the newspaper,

but not,

not the dailies.

anything,

Adam,

you want to mention or that we failed to ask you about?

No,

I think we covered a lot of stuff.

Uh,

hopefully it was interesting.

Was there one more magic one thing that you might've had?

Cause I know we talked about,

we stopped,

we stopped asking that question.

You know,

Adam,

you might have a magic one too.

Then if you could fix one thing in check,

we've talked about so many things I want to,

I would like to fix,

but if there's nothing left and that's fine.

But if you,

if there's one where you think,

Oh yes,

that,

I mean,

I would,

I would probably just,

you know,

the,

the one thing that I would say,

which is not,

it's not really code related.

It's,

and it's more meta.

Maybe is to make Django sustainable and to figure out,

how to not have a business model.

Cause that makes it sound more like capitalistic,

but more like how do we make sure we have sponsors for Django that we're

getting as many of those as possible and making the Django fellows a long-term

solution.

Because I think a lot of the benefits that I've seen in the past couple of

years are because we pay the Django fellows and they,

they are dedicated to Django and pushing it forward.

And I don't know if we would have had the,

all the improvements over the,

all the improved,

the recent improvements without dedicated people to the project.

Yeah.

I mean,

he's now 10 years old,

right?

The fellowship program.

So,

Oh,

than I thought it was.

Oh,

last thing I'll call out in the Django news newsletter.

I've been mostly trying to link to the Django's fellows,

give a weekly report of what they've been up to.

You can find it,

you can find it in the forum,

but I've been trying to add,

add that as a section.

So you can see,

and there they add a little brief paragraph and you can see all the tickets

and things that they worked on and,

and they do a lot.

Yeah.

That's awesome.

Adam,

thank you for taking the time to come on,

share all your work.

We'll link to everything.

People could also just go to your GitHub repo page and,

and see it,

but we'll link to all the things we mentioned and Django chat.com.

I will see everyone next time.

Bye-bye.

See you next time.

Bye-bye.

This episode was brought to you by button.