Transcript: Django the Good Parts - James Bennett

Hi, welcome to another episode of Django Chat, a fortnightly podcast on the Django Web Framework.

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

Hi, Carlton.

Hello, Will. And this week we've got with us James Bennett, who's a long-time Django

contributor, been on the Django board and, well, you know, all-round hero of mine. James,

thank you for coming on. It's really...

Oh, thanks for having me on.

massive honor to have you um we always talk about um to start off with like people's backstory and

how they how they got into programming how they got into django and all the rest but

am i right in thinking that you did philosophy because i did philosophy yes but you bailed you

didn't get a phd like carlton you so you quit early i i was trying to um i was a terrible student

so i did not get into a phd program oh i didn't know that so i was growing up my family didn't

have a lot i didn't actually have a computer at all um like i had a little bit of experience with

an apple 2 at school okay but it wasn't until i went off to college that i had reliable access

to a computer and to the internet i didn't have my own computer until my second year

and i was taking courses with a small college and so it was a department not just of philosophy but

a combined department of religion philosophy theology okay i was taking a course on ancient

hellenistic religions nice no i never did that professor yeah the professor was kind of a kind

of a geek and at the end of the course gave us an option you could either write a 15 page research

paper on an assigned topic or produce a website with five pages that's easy and i was a lazy

good programmer so i learned a little bit of html made a website

and kind of was interested, decided to start learning a little more,

learned some HTML, some CSS, some JavaScript.

I was working as sort of a department assistant.

I was the guy who would go, like, when they needed something from the library,

I would go pick it up for them or they needed copies made of things.

And my advisor found out that I had learned how to do this and was like,

hey, our department's website could use a little refresh.

would you like to do that? And we'll pay you for it. And so I did. And then I did his personal

faculty page for him. Um, and that was kind of the start. I spent a summer when I was supposed

to be doing much more research than I actually did, uh, learning PHP and a couple other things,

uh, build my own like personal blog engine. And then I graduated, applied to some PhD programs,

didn't get into any, got kind of a boring job at an insurance company and saved up a little money

and then went into business with a friend of mine who was a designer. Because you could do that.

This was like 2004, 2005. You could do that back then. You could just say, I'm going to go into

web stuff and it would work. And started doing contract work, mostly PHP and Perl. And I was

learning ruby and rails shortly after that came out i'd bought the rails book

um i had learned python from reading dive into python by mark pilgrim but at the time

python web development was basically zope right yeah and where i was living i was living in

virginia there were people around me like there were user groups that i could go to for tech stuff

that, uh, some of them did Python, but they all did government contracting. So like us federal

government websites with Zope and like hugely complex requirements and everything.

And then one day this thing called Django came out. Um, and I read about it. I decided to play

with it and I really liked it. And I remember I wrote something on my blog, not the one that I

have now but an older one that thankfully is gone about how i really like really like this

django thing and i really wish one of my clients would let me use it and i kind of joked about

maybe i should go on strike until somebody says i can use django and a little while after that i

got a message from jacob kaplan moss saying hey the journal world is hiring would you like to apply

Fantastic.

And so I did.

Flew out to Kansas, interviewed with them.

They decided to hire me.

And so I moved out there and that started my proper Django career.

So that's right in the crucible.

That's like, you know, you're there.

Yeah.

So one fun thing, that little website that I did for that course,

thankfully that also is not online anymore.

But for a long time it was, and because it was on a .edu domain, I kept getting email from people assuming I was an academic expert on the topic and being like, I've been reading this.

Can you offer any follow-ups, anything else that I should study?

Because you were like the webmaster dressed at the bottom.

Yeah, I was not a professor when I did that.

I never am going to be.

I was a student who was lazy and trying to avoid writing a 15-page paper.

So is it fair to say that programming seemed to fit your mind, though? I mean, I don't hear quite the same struggle that other people seem to have, like learning multiple languages. It seems like, you know, you obviously had to do the work, but it made a sense to your mind how programming works.

python did python has always fit my brain um php and pearl i had to put in some work javascript i

had to put in some work html kind of clicked easily but that was the age of view source

learn how to do that anymore um i mean it's also that i just had thankfully because i was doing it

over a summer when i had not many other responsibilities i had the time to just

bang my head against it like my first little php blogging application was not good but i was very

proud of it yeah well that's always how it is right i mean any even i was telling someone the

other day like you look at code from a year ago that you know someone else wrote let alone you

wrote and generally you're like yeah i mean it's just how it goes yeah and and yeah like i said

Python kind of fit my brain like PHP I give a lot of credit to PHP for making web programming

so accessible to so many people like at that point in history because up to then it was basically you

had to learn CGI which is kind of a complex and tricky programming model and probably had to do

pearl which has its own quirks and is kind of complex to learn at first and php made that so

much easier because it was just write this and you know you can you can intersperse a little logic

with some html and just upload it and it works yeah yeah i mean that there's that quote um about

make solve the web problem quickly that was its kind of goal yeah and i still hold that in my

mind you know there's you know whenever i'm thinking about django and what's good about

django and what the strong points can try and hold that you know python still hasn't got the

deployment story of just stick it up there and it'll work but yeah that solved the web problem

quickly i you know i i kind of think that that's something that django has going for it as well we

never had the kind of like mod php of just upload some files in a directory and your web server will

run them for you no we didn't but the that general goal i'm still i still hold it and you know when

you say you give credit to php it's exactly right it's like you know how did i get in i picked up

the php and mysql programming book yeah and if php had not made it that easy i don't know if i'd be

here yeah one of the things i've always been impressed by james that you've stayed so involved

in Django itself, both on the technical side and also the community side. I mean, this is true. I

mean, when I joined the Django Software Foundation, you were on there. You were also actively involved

with the technical things. And you actually drove the development, I believe, of the technical board

in part because you were, I think, the person, you had your hands in everything.

So the technical board was Jacob and Adrian, and I want to pause and give them a ton of credit because they set a really great example and they did some great things for Django.

I mean, from the very beginning with opening up to other people, being given commit access to then stepping back, like one of the biggest milestones and potential problems for a project or a community like Django is whether it can survive the loss or the moving on of its founders.

Yeah.

And they set it up to succeed at that.

And then they stepped back and they said, we don't need to run this for the rest of our lives.

And then we got the technical board.

You know, we still had at that point the technical board and the committers, the core team as the decision makers.

But they deserve a lot of credit for that because they set Django up to succeed and be hopefully sustainable in the long term.

There are other projects that never really get over like their founder or their kind of like old guard team and just kind of cling to that for as long as they can.

Part of that is being, I guess, being open to, yes, I mean, I remember when they stepped back and it was, you know, BDFL, but BDFL until we stepped down and then, ah, what's going to happen now?

But Django had quite a big contributor base and was historically open to new contributors.

Is that cultural or is that?

I think they did a lot to encourage that.

They were very open to feedback.

I mean, even before Django was publicly released, they were kind of showing it around to people and asking opinions.

You can hear stories of like Ian Bicking being asked about the thing that became Django and offering his opinions on it and kind of the ORM used to be a code generator and there was feedback to, yeah, maybe don't do that.

Yeah, I think they really set the tone for that by being open to feedback to other people jumping in and helping out and being willing to not be gatekeepers of Django forever, but saying, oh, this person's doing good work. Let's give them a commitment.

Yeah. And one, one thing I've always liked is the, um, the, the approach for consensus, looking for consensus in that, you know, it's like, well, you know, actually there's, there's not a consensus for agreement. So we'll just hold off here or we'll, we'll carry on the discussion to until we see if we can find that. I think that, you know, it's a real strength. Um, it's not just one person going, no, I think.

I know people get frustrated because it seems like it can take forever to get something done in Django, but I do feel like Django's kind of slow and steady approach to, we want that, but we'd rather have the right version of it than have a version of it right now.

Yeah, no, I mean, it's the other day I was commenting on the channels repo about, you know, the development slow and it's been slow the last couple of years, but it's inexorable, you know, year after year, it slowly moves forward.

And, you know, one way to speed it up is, you know, I'd say one way to speed it up is to join in.

But, you know, the reality is that Django's a slow-moving beast, you know.

Yeah.

And I think it's also been a benefit in a way because Django has maintained a lot of integrity of what Django feels like.

Despite all the changes that have happened.

When I did my ORM tutorials at DjangoCon, I mentioned this.

I would take the actual blog model that's used on the Django project weblog

and go through different stages in its history and be like,

doesn't this look awfully familiar every single time?

Yeah. Okay. Nice.

And I think that's contributed a lot.

The kind of pace and the kind of, well, let's do it right,

even if it takes a little bit longer, has helped Django maintain that integrity over time of

this feels like Django, even as new features get added, even as things get rewritten.

Well, that's even, I was thinking about that today because Black, the Python formatter,

just got out of beta and DEP 8 has been around and approved so that, you know,

once that milestone was reached. So you could say, well, another framework could have thrown

black in earlier but you know there was a process there were all these extra steps people committed

to that process and it will be in there and when it's done it's done the right way people can see

the discussion you know so i think as you said taking a little bit longer having a process

wins out in the end even and people can always just use it themselves too i mean that's the

thing with the ecosystem and third-party packages channels yeah there's there's like an off-ramp for

i really want to do this um and frustration has an avenue yeah jango has always kind of encouraged

doing things third party to begin with and building consensus in the community around

yeah this is a good implementation this is a good way to do it and then bring it into jango

so that happened with migrations that happened with channels you know yeah that's key stuff

yeah yeah i mean and even the sorry go ahead you will well i want to hear you two talk about the

technical part i was going to say even just the the community part that the dsf you know that we

had anna on recently last week um who's the current president and she's been on the board for five

years and i've been on now three years and there's a natural cycling of people on the board but there

is the sort of passion and knowledge hopefully gets passed along. I mean, you were secretary,

James. You can't assume that someone is going to volunteer for 10 years on the board or as a core

committer, though you've managed to do it a long time, James. So there's a healthiness in terms of

having that model and do what you can. When you have to step away, you can. And that keeps the

goodwill in the community. I mean, I know for you, you had a whole spike of work stuff on top of all

the Django things you were doing a couple years back which made you need to step away but you

know you're still here you are right you haven't rage quit hopefully so well I've reduced my

involvement a lot um yeah I used to be on the DSF board I served some terms on the technical board

I used to be a lot more active on the developers list um these days the only thing I really do in

the Django project is

I'm still on the security team

and

not super active

there but every once in a while I'll jump in

to a discussion

review something

Timely imported call it

I hope so

I think that

again that's kind of the project

and the community are healthy enough

at the moment and i think again that goes back to like jacob and adrian setting things up that way

but they're healthy enough at the moment that people can step back and other people are stepping

up to do things i mean we've got to hope that you can step back because like you know i mean

open source and burnout go hand to hand like you know yeah coffee i wasn't quite intending to have

like the the mic drop of the new governance and then all right i'm out but so you mentioned the

government so that that was the um the abolition of the old um django core and then yeah um moving

the the man the sort of uh the governance of the framework to the dsf membership um and yeah but

the the the um the rebranding of roles so there's mergers and committers mergers and releases and

roles like this and then the technical board taking that role that was depth depth 10 right

yeah one one thing that i was worried about and you know i've got you here was that the the kind

of knowledge base the sort of old knowledge the old you know the established knowledge to sort of

just disappearing as you know you know i looked at i looked through the old list of the core

committers and they were all like all the people that built all the features and if they're not

there anymore i was just worried that we'd lose that that kind of tribal knowledge slightly

i don't know what you think now i feel like i feel like people are still willing to

to like answer questions um i've joked with uh russell keith mcgee a couple times that

my role in django now is to be a grumpy old man who remembers what happened yeah yeah why is this

it that way um and yeah every once in a while just jump in and but at the same time there are

plenty of other people filling that role like i saw um you know tim just recently uh in tim graham

yeah in thread about email configuration jumped in with well here's this old ticket and it never

really got anywhere and here here's some thoughts from when that happened so yeah there are other

people stepping up and like carlton you know you've been around long enough that you are

you have a lot of that context now i said the the last few years doing the fellow role like so

basically live in track that's that's where i've you know deepened my knowledge massively so okay

i was working on rest framework and then but to come in and and have to go through track and when

an issue report comes in and i have to find the history and exactly why it was and yeah you know

you do that for a while it's okay yeah i can i can my not tim's knowledge of the issues is amazing

it's just impossible now but i used to like 10 10 years ago or more i used to every once in a while

just go through every open ticket in in django's track and read all of them see if any of them

could be closed see if any of them needed to be bumped like is there anything like any easy like

documentation tickets or things that can be promoted as let's get this one done for the next

release yeah we can't really do that anymore but you still yeah you develop that feel for what's

out there what's open it's like oh yeah i remember there was a ticket about that yeah and you could

try and find it and that that works and then you you know and but uh just the other day claude

there was a discussion on about um what was it i can't remember the exact details but claude was

like are you talking about this ticket and there's you know 10 year old ticket i'm like yes claude

thank you that was the exact ticket i was i need to find so yeah i mean so i guess the history is

still there and what's it you know what's interesting you talk about um jacob and adrian

you see a 10 year old discussion or a 12 year old discussion or 15 year old discussion where they're

you know, handling it in a very gracious and open way.

And it's exactly right.

Super.

James, another thing I want to ask you about is you have given a lot of conference talks

over the years that, I mean, that's how I first knew about you is seeing these talks.

And I wonder if I could ask you about, so this was from PyCon 2014, Django the good parts.

I don't know if you recall your thoughts there, but I thought that was a really interesting one.

Yeah. But that idea, I mean, there was, you know, Java, I guess that was when, what's his name? There was JavaScript, the good parts, right? That was the thing. But it is, one of my favorite talks is Jacob's from, I think, PyCon 2017, which is a three hour build your own web framework, where he basically goes through, these are the decisions you make. And, you know, do you write your own templating language? Do you use something else? And what do you use for the web server?

and it sort of distills uh a top architect level view of of these things and anyways if you recall

that you know you're the good parts talk i i watched that a couple years ago and it might

be interesting to see if it still holds up uh eight years later so let's see i have we'll put

the slides in the notes if they're i'm sure they're up somewhere yeah they're somewhere

I'm sure they're online.

So let's see, what did I suggest?

HTTP abstractions, the request response cycle,

the slow and steady approach to features and apps

as the good parts of Django.

I'm sure there are more good parts.

Those are just kind of the ones that I focused on.

I think that still holds up.

I think Django's request-response cycle

and HTTP abstractions are still quite good,

especially, and this was in comparison

to doing your own raw WSGI-type programming.

And for people who've never done that,

WSGI is kind of CGI-adapted to be a Python thing.

It is literally the CGI programming model,

just kind of lately adapted for Python.

so there's all this like the way for people who've never done cgi the way that it worked

was you would have your script and the server would put information about the incoming request

into environment variables and the body of the request into the standard input stream because

it was a unix programming model and then start your script and then you would do your processing

and send your response headers and response body out on the standard output stream.

And so you had to do all of that processing in the script

of knowing which magic environment variables have which things

and how am I supposed to parse them and how am I supposed to handle them.

And WSGI is similar in that it passes you a dictionary of the environment

and the keys, in fact, in that dictionary match up to the traditional CGI.

variable names. And then you return. And WSGI is a little more composable that every single step,

like if you have one WSGI app wrapping another, both of them have to parse that environment

dictionary. Like the response API is kind of complicated because you have like this

thing that you call to start the response and then you return the response.

And so it's, I really do think that Django's abstractions are, are pretty good.

I think there's evidence for that with the move to ASCII as well, because it was, Andrew did an amazing job and he was just able to, not just able, I don't know just about it.

He was able to bring in an ASCII request that maps kind of parallel to the WSGI request.

And inside of that, beyond that request object, kind of the insides of Django were like, yeah, I don't even notice.

It's, you know, so we've been able to put in a totally different request handling sort of application layer.

And Django's untouched virtually.

Well, we had Carl Mayer on from Instagram on the podcast, and I think he said pretty much the only part that hasn't been rewritten by Meta, Facebook, is that very part of Django.

And he thought they would never probably swap that out because they didn't need to, whereas they changed the ORM and everything else.

But that bit was pretty rock solid.

I mean, there definitely are other libraries and frameworks that provide the request-response abstraction as objects in a similar way.

I just think that Django, that's one of the things that Django got right.

And I'm sure there are other good implementations, but I think Django's is really good too.

We talked about the slow approach to features, so I think that still holds up.

Apps. Absolutely. I've been a fan of Django apps. I gave a talk at the very first DjangoCon, which was 2008 and hosted at Google, about designing what I thought were good Django apps.

And I've talked about that a lot before and since that the app abstraction of you can build sort of a self-contained unit of functionality and then compose and reuse.

So things like you can build a contact form, you can build a blog, you can build like all of these different types of features and functionality and compose them together to build a Django site.

And I think that's really, really crucial because just providing that abstraction at the level of not like a database model or a view, but at the level of a whole interconnected unit of functionality for a website has been really, really crucial to Django's success.

Because it gives you that level to think about. And it gives you the ability to package those things up and distribute them. Or even if they're internal, you know, reuse them across different projects and saves you a lot of time, makes it a lot easier to reason about these things. And so I've always felt like apps were kind of like the secret weapon that made Django so good.

I should mention you have a Django contact form app among several others that folks should check out.

I need to do the Django 4.0 updates and I got a, I think it was Marius pinged me to point out that the new form rendering is actually going to require me to do some work with the contact form.

Because the contact form already had a method that uses the same name as what was added for the new form rendering.

Carlton, I know you had a question, but I just wanted to...

Go on, Kevin.

Well, I just wanted to say something quick, which is that apps, when I...

People who are new to Django, especially people coming from another framework, apps is actually something that trips them up or they're a little...

Not angry about, but they're kind of like, this is stupid.

Why does Django have apps?

I want it to be a certain way.

And I see this various discussions.

It's like, well, you can, the whole point is you can do it however you want.

You can have one app for your entire site or you can rely on abstraction and then you

can also rely on these third parties.

But that concept, maybe it's coming from different frameworks, but that's something that someone

coming from another web framework, I find trips them up initially because there's confusion

over what it means.

Yeah.

It is a thing that I've had to like, I've had to teach and I've had to explain like

at a few different companies with people coming from other stacks and and their assumption is oh

the app is the thing you deploy and projects versus apps explaining you know like the the

project is the minimum deployable unit of django but you know the app is kind of the atomic unit

of functionality the question is well where do you draw the line it's like well well there's

guidelines but that's so i think that's you know that's the piece that is unsettling to to those

folks it's like okay but but how yes and um yeah and and it is it can be tricky and like i'm not

going to say that i always do it right it's not something that there is a single rule you can

follow that always gives you the right answer right well that's kind of what i tell these

people is say well yeah maybe it's an extra step or thing to think about but django on that balance

of customizable django is actually quite customizable considering it has guardrails

and that comes at the cost of the apps and some other configs where it could be rails it could

just go boom one way but it makes it easier to be malleable within the construct it lets you

it lets you turn things on and off it lets you have you know different configurations of features

that you can kind of toggle um i think it also helps that django it that django itself has that

approach so like the apps in django contrib uh yeah it was like the admin and sessions that

you can see that you are composing these things together right just one more right yeah

carlton what were you gonna say i'll follow on from that just one more comment is that people

get kind of addicted and what i've seen as a working django programmer for many years is you

could go to a company and they're stuck on the the old lts and it's just about to go end of life and

they're struggling to update because they've got you know 30 third-party apps and 29 of them aren't

really um aren't really maintained properly and then they're in a kind of bind and so over the

years i kind of developed a kind of um very conservative approach to taking on a new app

you've got to be you know you must be cautious here you mustn't you must check it's properly

maintained you must that's the counter that's the counterpoint i guess is that you can

third-party app you mean carl yeah third but yeah the third party app if you're going to

take on a dependency like and then you find yourself kind of stuck so i i tend not to use

the lts myself but i asked on twitter recently why you know if you use the lts why why do you use it

and the one of the biggest responses was well you know by the time our third-party apps are

updated to be compatible you know we go lts to lts and that can serve us better than

you know trying to i think like the the api compatibility promises that we have now

make it a little more make it a little nicer for a lot of places to go lts to lts because

you know django itself kind of makes the promise that if you're running on

this lts and you have no deprecation warnings you can safely upgrade to the next lts

yeah yeah uh without having to change your code now you know you would want to test any third

party stuff you're using but that gives a very nice upgrade path and and i've dealt with setting

up dependency management workflows at several companies and and how to how to keep things up

to date and that is a perennial issue yeah and i recently updated a project on 111 and it was

remarkably smooth to get it to 2.2 and then 3.2 and it was just like you know and i didn't bother

with the intermediate ones because i you know run with warnings clear those up and it was it was

that was lovely to be honest much yeah better than the old days but it does it does get complex

when you've got i mean even if you're not using that many like django apps you're probably using

some number of third-party python libraries and things off you know pi pi and you need to keep

those up to date, even if you're not upgrading Django.

Yeah, so that's a fun thing to do.

Well, so I wanted to ask you, you wrote a post on how I'm testing now from 2020, which is related to this that I thought was pretty interesting.

And testing is something we love to ask practitioners about since there's quite a variety of ways it's done in the wild.

So we will link to that article.

But I wonder just, again, you've worked at a number of companies using Django.

How do you think about, you know, practically speaking, proper testing?

You know, what are the tools you like to use in terms of the hierarchy of priorities that you like to see in a code base?

I like to see tests.

Like, any tests are better than no tests.

I'm not particularly like a test-driven development person.

i'm kind of i'm skeptical on most like capital letter methodologies for building and managing

software projects like full stack developer so i may write something about this in the future like

you know i i understand that a lot of these methodologies there there's some essential

insight that somebody

caught once and then

tried to propagate that

but it's the everything else that grows

up around it and kind of all the

rituals

and practices that

because so often

like the things that make a project

successful or not are not

really you can't replicate

them to the next team the next

project the next thing like it's

nobody's figured out how to do that yet

in software

so um but yeah i do like tests um i for my own personal stuff i write

tests i use talks as my test runner because typically i'm um like i'm testing against a

bunch of versions of python and django for like django apps and sounds like carlton yeah talks

makes it very easy to manage that matrix of things and keep them running um i use i prefer

the python standard libraries unit test module over pi test um the last two places that's

interesting have been pi test shops but i i prefer unit test module um can i ask what it is

like what is because pi test is very popular now and you know we still use unit tests for

for django's own test suite but what are your own reasons for favoring that um

so i mentioned this a little bit in the blog post uh that i understand or at least i think

i understand what pi test is trying to do with separation of concerns in testing

and how it wants that.

I'm not the biggest fan of dependency injection in Python.

And the particular way PyTest does it,

I just feel like at least I kind of struggle with it

because I feel like fixtures can be getting injected

and found and loaded from so many different places

that it's hard for me to know what's available,

where did that one come from what does that one do it just i have a harder time reasoning about

everything that's going on versus like a unit test style uh where everything is right there

on that class and i can see all the things it's doing or if it's from a parent class i can see

what it inherited from and i can follow the import chain it's a bit like function-based

views versus class-based views like carlton i saw there's you know you were waiting to twitter

someone had oh i foolishly got on that and i foolishly got i i i saw i glanced from a distance

and said braver than i am it's just i like last eight years um yeah i think i think jango's built

in ones could have been done differently but i understand why they were done the way they were

but in general i'm a fan yeah i mean my the the claim i made was that they give you um

a namespace to break your logic up in and i think the issue is that we don't teach we teach here's

one line and you've got a list view and that's kind of deeply mysterious whereas if we taught

you know a class with a get handler and then you declare your view then it's just it's exactly the

same as a function-based view at that point but it's just got a bit more structure if you need

to break your you know you need to break it up and i think well yeah that was my point is that

hang on what are we what are we arguing about here are we comparing function-based views to

django's generic classmates views or are we comparing and i also i mean i feel like i lived

through the entire era of generic function-based views and of that being function-based views being

the way you did things in Django.

And I remember how much more difficult it was

to like add functionality and say,

okay, now I need another keyword argument

and I need another conditional in the body of the function

to handle that keyword argument

and I need to account for it everywhere.

And if you ever go back and look,

like maybe link one of the old Django documentation versions

with like the argument signatures

of the old generic views back when they were functions.

Like it's a gigantic list of stuff.

See, this is that grumpy old man wisdom

that we need on the young folks, Carlton, right?

Yeah, exactly.

And yeah, like the class-based,

like the generic views in Django right now

that are class-based are the way they are

because they tried to replicate exactly

what the old function-based views could do.

Like we wanted the functionality before and after

to be the same.

And so that's why they were written the way they were. That's why, you know, if you wonder about like choices that seem weird in terms of what's broken out into a mix in and what's inherited into the it's because there was a deliberate attempt to preserve exactly the set of options you had with the old ones so that you could just go straight from one to the other.

Well, Carlton, you've mentioned many times, I mean, Tom Christie has Django vanilla views, which is perhaps a clean approach at doing it without trying to mimic the old function basis.

yeah i mean the vanilla views they're sort of they don't handle all the the they do the basic

create views and um you know the form handling views and then the list in detail and for those

they're kind of you know 1.8 time they were sort of feature equivalent but they're just a more

direct style without the mix-ins and so i always recommend people because there's only like four

files in that package i always recommend people to go and read the source code of jango vanilla

of views because it kind of it it it's really eye-opening it's like oh yeah actually what's

going on here is just turning requests into responses and you know there's not too much

to it and then you go back to classy class-based views and the django ones yeah i see the same

thing's happening and that's a nice learning at any point could django simplify the ones we have

or i mean i feel like there's too much of a compatibility issue yeah no not now no i mean

our our usp is we don't break stuff right yeah like and we can't we can't change the

generic class-based views that we ship i'd like you know maybe but no if you want i mean

i remember when when the old form system or the the manipulator system as it used to be called

um and and then there was django.newforms which became django.forms years later so you know

django.newgeneric yeah oh

there we go carl then okay if you write the depth i'll i'll plus one it how's that

okay i think i think you're right there's just too much

backwards compatibility and it's too important a feature to to rip out and replace like that

and it's not it's not that it's bad code it's great code it's great code it's well documented

it's well tested it's got everything going about it it's just there's a learning curve and it's not

perhaps as clear as we'd lay out if we started fresh but and at this point it's not clear to

people why that learning curve exists because that complexity is entirely as you mentioned due to

the desire to maintain exact compatibility with what the old function-based views did

yeah yeah i think yeah i mean i think you mentioned that really if you're honest

but that's okay you mentioned you know we don't we don't break compatibility as a policy that

you know when the class-based generic views were introduced they had to be

exactly equivalent feature set yeah okay interesting so gone well did you want to

yeah i just can ask about service layers but well okay because there's a big elephant in the room

which is the orm right so yeah and just to wrap up like the original question about testing like

it's not that it's not that i think pi test is bad like it's it's really good it's really well

written and i do appreciate what it tries to do with separation of concerns it's just

for, for me personally, it doesn't quite fit my brain and I find it a little harder to reason

about. Like that's why I prefer the unit test style. Okay. Service layers ORM, pick one.

Well, let's talk about your, you've taught the ORM, you've, um, you know, contributed to the

ORM. How did, here's a question I'd like to ask ORM contributors. How do we make, how, if you're,

if you've got a young contributor wants to come along and they want to get into contributing to

the ORM how do they approach that how what's the the routine to grokking the ORM because it's it's

big and scary and multifaceted um even Tim said so yeah

yeah he said that was the one area I was like where are you not rock solid and he's like well

we've mostly we've mostly relied on like every once in a while so like I'm sure you've heard

Russell tell the story of when she first started contributing and picked this really

deep, gnarly ORM ticket to do that when she submitted the patch, it took Russell and someone

else a couple hours with a whiteboard figuring out what was going on and that, yeah, this

is the right solution.

She just tossed that off in the course of a sprint.

always kind of relied on the the kind of genius level i don't i don't know how she understands

the orm that well um like walking in late to class and you know solving the proof that's

never been solved yeah at the mit yeah so jango has been very lucky to have people like ola who

just show up every once in a while and can do that um we we need to do better with that like

the ORM, I would say first try to understand the different abstractions. Start with models and

managers and query sets, and then maybe look a little bit at query, look at database backends,

look at the query object, look at the SQL compiler, learn to think of query. I actually think a good

analogy is to learn how the template system works and learn how the template system parses into a

tree of nodes and then walks through rendering all of them. Because what the ORM does effectively is

build a tree of expressions and walk through with a SQL compiler, turning them into SQL.

And kind of understanding that pattern and what the major abstractions are.

and then you can start reading like some of the scary source code in you know query logic and

i haven't looked at that in a while but it is so it all comes back to compilers right that

reminds me we we had carson gross who who wrote htmx and uh he's a big fan of writing uh programming

language from scratch and teaches them now and he was he had some line he's like oh yeah you know i

just wrote a programming language for this problem it's easier than you think i was like for you

i've actually i've been thinking about maybe doing a series of blog posts on like let's build the

jango template language okay and just go through like okay here we're gonna parse it because

the jango template language is incredibly simple and the implementation is not that hard

And like if you have – if you're really motivated, you can probably read through it and work it out yourself.

And if not, like a little bit of guidance I think will get you there.

Like just introducing the concepts and what's going on.

And then when it all kind of fits together in your head and you understand, oh, that's how it does that.

And now you're ready to learn how to do that.

Plus one to writing that.

No, I'd read that thread.

Yeah, I've got some things I want to write.

i need to decide i've thought about turning that orm tutorial into a book but i don't know

if i'm ever going to get around to it carlton loves when we talk about when i talk about books

with potential guests well you wrote a book you wrote a i have your you wrote yeah i have that

that was you built a blog in it i believe right yeah there's a blog and i think something else

that was built in that one yeah that was i don't know a copy of it somewhere og carlton as they'd

say yeah oh jc don't taunt me don't taunt me there's a whole well there's just a twitter

thread you know just my children are like dad you have to play more fortnite because i don't know

any slang or any of these street abbreviations am i am i missing out on uh what's going on on

twitter or am i not missing out by no you're not you're not missing out it's will's just teasing me

know okay so following it okay so learn the abstractions to get into the ORM and then

recently there was a gone it was recently you wrote there was a few articles on using Django

or the ORM versus service layers and I think that's really interesting because like why Django

why the ORM like versus other approaches that's I think that's a massively interesting topic we

can link to those blog posts but it'd be nice to we talked about with some guests back when you

wrote it james actually we okay looked at those so right here's an expert here's an og expert out

in the wilderness saying giving opinion on django that i mean you want to toss in the orm more than

anything is kind of the the scenic one on of django at this point it's the thing that if you're not

using it, why are you using Django at all? Um, like the, the request response abstractions are

nice, but there are other libraries that will give you request response abstractions in Python.

So basically it's, if you're not using the ORM, why Django at all is kind of the question.

And I'm not sure the answer at that point is to use Django. Um, like maybe you want some of the

abstractions. You want

the concept of apps, but you

want to use another ORM with it, or you're

not using a database at all.

That can make sense. You can do the kind of

minimal Django.

I think some people have even put together examples

of how to do a very minimal Django.

There might be a talk on

but as far as the ORM itself like like putting service layers in front of the ORM like

the reasons people give for wanting to do this are always you're going to end up reinventing

the ORM or you're going to end up introducing a lot of complexity to make something like

sometimes people do it for testability so they can swap out a fake database and run

at during test runs um some people want to like hide the data access logic and you know have

separate representations of like business objects and business logic and there are design patterns

for that like i mentioned in the blog post several times like if you really want that if you really

believe you want you know data objects and business objects and explicit logic mapping

between them you want the data mapper pattern and you want to use sql alchemy

and you want to use a data mapper ORM, but Django is not a data mapper ORM. It's an active record

ORM. And you're trying to take this design pattern that works fundamentally very differently

from how Django's ORM works and push it onto Django, and that's not going to go well.

And you're going to end up having to rewrite large chunks of the ORM to simulate ORM functionality in your service layer and introduce a whole bunch of complexity.

Like, I think in a lot of cases, the problem is, and I touched on this, I think, in the first blog post on that, is people trying to untangle interdependent code, like these really complex code bases where it's like everything does everything.

I have worked on codebases where there were some models that had a policy that you always had to do save with explicit field list because you didn't know what else might be modifying that model at the same time.

And so make sure to only actually save the fields you're changing to the database.

And I tried to give what I think are some good guidelines for how to have models as the API of your app and what kind of access from other apps and other code into a set of models to allow.

And basically, like, things like you shouldn't ever reach into another app's model and start tweaking its fields directly and saving it.

Like, don't do that.

Instead, you expose logical methods like the joke that I've used a few times that I've always heard is, you know, if you want to walk the dog, you don't reach down and pick up its leg and put it down and pick up the next leg and put it down.

You ask the dog to walk because the dog knows how to walk and building models that know how to do things rather than having to reach in and grab this field and set it to this and grab this field and set it to this.

Minimizing the amount of internal structural knowledge you need about those models because their public API, their list of methods that they expose gives you the operations you need.

And then at the table level, you might put that on a manager rather than the model itself sort of thing.

Yeah, like row-level operations on the model, table-level operations on the manager class, alternate constructors on the manager class.

But yeah, I think that it's hard to do.

I've advocated for it.

I've never seen it completely pulled off successfully.

I don't know that I've ever personally managed to completely pull it off successfully.

But at least putting in the effort and trying to do it gets you a little better results.

And then the rest of it was kind of like, well, what do I do with these really complex things?

Like, you know, somebody is canceling their subscription and there's like six different models that need to be updated when they cancel their subscription.

And it's like, well, if you put that in a service layer, like saying, well, it doesn't make sense for this thing to be on one model.

well it also doesn't make sense for it to be in one service method because it's doing all these

different things like that that's moving it around while keeping it that complex doesn't actually

help um so that that's the other kind of issue there and there are patterns for that but that's

just a matter of like familiarity and experience and sometimes going and looking things up

and being like how do people do this there there are i think brandon rhodes has been trying to do

like design patterns for python they use python patterns repository i don't know if he covers

like anything other than like the the original design patterns book but there's a lot of stuff

out there on how to like how to handle these kinds of like complex cross-cutting concerns in

code and how to break it down so that you don't end up with like the one method that does everything

and touches everything i had one sort of larger question is there any more specific ones you had

carlton just james yeah i mean just on that i think you know that the whole point you we made

right at the beginning about you know doing the web problem quickly and like the orm fits that

for me the rm fits that niche really really well and most times if you're trying to do the web

problem quickly you don't need these extra complex constructions around it you just need to make sure

that as you grow you maintain hygiene because yeah it will get gnarly it will get intertwined

it will get difficult but that happens to every project no matter what architecture you use

So my concluding question is open-ended, which is, so as we record, you're not currently working for a company.

I've been unemployed for just about a week and a half at this point.

Oh, wow.

Okay.

Is that home-baked bread behind you, I see?

Yes.

Yeah.

I didn't make it.

Right.

Okay.

So win-win.

It is brioche that was homemade.

But I was not the one that made it.

but I have been enjoying it.

Yeah, nice.

So my question to you is,

what kind of opportunity,

given your experience,

is interesting?

Like you've worked at small companies,

large companies,

you've tackled all sorts of web,

Django problems.

What, you know, where you're at now,

what kind of things would be interesting?

I don't know.

Have you managed teams?

I feel like you've been more on the code side,

but I don't know.

So anyways, what are you looking for?

What's interesting now to you?

I've never been a manager. I don't really have interest in being a manager.

I've been sort of climbing the individual contributor ladder.

My last job, my official job title was staff software engineer.

I put up a blog post about it where I said that I like working someplace where I can use my Django experience and be a resource to a team that perhaps is using Django and Python, but not being defined by it.

um being able to do more than just be the django guy at a particular company and it's like

it doesn't have to be any single particular thing but just getting to branch out getting to learn

stuff like i spent the last year i didn't set out saying i really want to get good at docker

and i'm not really good at docker but i i ended up doing a project that involved learning you know

quite a bit about docker how to do docker files docker compose orchestrate you know docker based

projects and that was really interesting and because they were django services that were

being dockerized like there was opportunity to use the django specific knowledge but it wasn't

just oh we've got a django person let's have him go do django things i would love to see a blog

post on that by the way because that's a perennial issue is well i don't know that i docker approach

for jango i don't know that sometimes it's your kubernetes and it's like i i did i i did not much

out there i thought was okay at the time and other people are going to pick up and iterate on now

that i'm gone yeah it's that that that's the kind of thing that i look for is i don't necessarily

know what's going to be interesting to learn but having the opportunity to branch out and learn

other things and do other things that aren't just being defined by django because it is important

to me that like django is important to me and the things i've done with django are important to me

but it's also important that i'm to me that i'm not one-dimensional that's not the only thing i

can do that's not the only thing i know it's not the only thing i can learn and do you think that's

the ic issue because the tech industry isn't great around ice you know individual contributors

there's there's a sense that trees only grow so high yeah you know i mean like other other fields

don't have that but in tech there is a little bit of that yeah like once once you specialize

in something it can be hard to be like you know people talk about you know wanting like the kind

of t-shape of like you know really deep knowledge in one thing and you know then kind of okay

knowledge and a bunch of other things um but i don't know how many companies actually succeed

at that and how many teams actually succeed at wanting that because getting getting to a level

of of specialization with something you can like it but that doesn't necessarily mean you want it

to be the only thing you do for the rest of your career so so you're switching to front-end

javascript development only right is that what you're so is that what we're hearing here story

actually when i was back in 2006 i believe i was officially hired to be their javascript guy

um you could see how well that worked out

um like at the time i was like i knew python but most of what i did professionally

was like a little bit of backend work and then like front end, like HTML, CSS, JavaScript,

translating, you know, ideas and designs into actual implementation. And, you know, 2005,

2006 era front end was a whole different thing. But well, like, would it be more interesting to

be the fifth employee on something with traction where you need to rewrite everything to make it

performant? Or would it be more interesting to be the 50th and have to specialize a bit more?

I'm sorry, curious, you know, where you're at now, which which of those two problems would be more interesting?

I don't know. I actually did talk to a company that was hiring for their fourth person and first dedicated back end person.

And that sounded really interesting, like the chance to kind of like start from scratch and have a hand in building everything.

we're programmers we always love the idea of just starting with that clean sheet of paper

and saying we're going to do it right this time this time is different yeah um but i've also been

talking to places that are that are much larger and are looking for like someone who can come in

and be like a resource and a mentor on django stuff but also do other things and then that's

That seems like that seems really good to me. That seems like where I want to be. Like maybe one day I'll do the, you know, first back end person process and start everything from scratch. But I don't think it's going to be this time around.

You could also just consult for equity, you know, with the smaller one, right? Because I feel like a lot of it is somebody who doesn't have the wisdom who might say, this is how we're thinking about doing it. And in a couple hours, you can save them so much time, but you don't necessarily have to do it yourself.

I don't know. I've done contracting. Contracting is expensive. It's expensive to be a contractor in the US, at least.

Expensive for you or for them?

Expensive for the contractor was my experience of doing it.

Because there's so much overhead that people don't think about from being full-time contracting.

Like healthcare.

Yeah, like healthcare, under your own retirement, you pay more taxes.

You pay an extra 15% tax for being a contractor.

I'm self-employed.

Yeah, so you know this.

So it can be...

Carlton too.

yeah it can be tricky oh you said one you said one thing so i'm gonna you said mention mentoring

so i have one more question i'd like to ask you and then okay we'll let you go but what what do

you think it's something that i'm always thinking about what does it take to mentor somebody well

do you think that the challenge i find is people come they say oh we want to mentor but they don't

bring anything to the table and how do you how do you find that balance i don't know that i have a

great answer. Um, in, in my professional career, like working for companies, I've had a little bit

of success getting people from kind of like post beginner intermediate into like advanced

intermediate to senior. Um, like working with people who already had some basics under their

belt and getting them kind of to the next level there. I've had some success with that. Um,

i have never felt particularly great about my ability to start someone like from scratch and

get them you know zero to at least kind of like a reasonable like beginner junior

you know first job level of knowledge so i don't know exactly um how to answer that like the

the things that i've been successful with have mostly been like

pointing people at resources that are kind of interesting and kind of showing

like here's a pattern that you might not have run into but we can do that for

this thing like not necessarily telling them oh do it this way just kind of

showing them what options are out there yeah and letting them build because I

think that is the kind of that's one of those things that as far as technical

knowledge as you grow is kind of your mental library of patterns and possibilities and options

that you at least know are out there even if you don't consider all of them for every single thing

you're going to do and so i've had some success with that but i i don't know i i don't know how

to replicate that necessarily and i i don't feel like i've had great success with um with people

just starting out okay the one time i did google google summer of code um i was probably a terrible

mentor and i was very lucky because my assigned student was janice yeah so i got the easy mode

yeah yeah janice being like jango's second biggest contributor of all time so yeah yeah and and like

so many other things yeah we used to joke that everything you use has has been written by him

at some point more or less yes super okay let's let's call it there because we run up to time

james thank you so much for coming on and sure sure you know sharing your opinion thank you

yeah so we have links to everything uh in the notes check out james's talks if folks haven't

seen them already and we are at Django chat chat Django on Twitter and we'll see everyone next time