Transcript: PyCharm's Year of Django - Paul Everitt

hi welcome to django chat i'm will vincent joined as ever by carlton gibson hi carlton

and we're joined again by paul everett who's a python advocate at jetbrains welcome back paul

hi will hi carlton hello paul thank you for having me so it's always a pleasure to talk with you

because you've been in the community for a long time and there's really interesting things

happening at JetBrains, especially around PyCharm and Django. Maybe I'll give that to you. You were

just telling us before we started recording, there's some exciting stuff happening related to

Django. Sure. And I'll give the standard caveat that I am with JetBrains. On the other hand,

JetBrains is so cool. I joke that I should be paying them, not them paying me, but don't tell

than i said that um we are uh we've been around a while as python ide django ide in fact i believe

the original tagline for pycharm 15 decades ago was python and django ide so we're pretty good at

analyzing the magic strings and django the magic structure and all that and putting it into

machinery the IDE can use. We are starting a year's worth of a lot of things going for Django.

We've been doing a lot of things in different directions over the past few years, past API and

things like that. We're getting back to Django and a lot of cool stuff coming down the pike

in the product itself, but also things that we want to talk about and show and teach and patterns

and this whole idea of

what does professional development look like for Django?

And it's a bit of an open question.

I mean, that's partly why we have this podcast

is because unless you're doing the hallway track

or work at a company with people,

you know, doing interesting things with it,

there's no easy way to keep up with it all

besides the different forums and mailing lists.

So well said.

Just follow Carlton on Mastodon.

I mean, that dude just can't stop typing.

Well, definitely I don't know about that,

But in between when my tests are on, I've got to throw some rubbish out there.

So I wanted to hit you up, Paul, because this week, over the summer, I've been using VS Code for whatever reasons.

And literally this week, I switched back to PyCharm and I pulled it out.

And I've been having any number of squiggly lines all over the place.

And that was going on with VS Code.

And I switched over to PyCharm and I had exactly the same squiggly lines.

It's all about the typing.

It's like the, you know, because the static analysis doesn't, you know, pick up that you've overridden the manager or something like that.

And then I went into the PyCharm settings and I hit the Django integration box.

And it just, all those wiggly lines went away and it picked up the reverse managers and, you know, just everything.

And it's that depth of understanding of Django, which I think is PyCharm's real strength.

Indeed. And we need to make it clear that button you clicked is the I'm paying for PyCharm button.

Yeah, yeah, yeah. No, that's in the professional edition.

And that is the first thing that people encounter when they take a look at us is, hey, we operate under this mode of you are our customer and we will support you.

And this is a normal kind of software relationship.

So PineTron Professional has Django integration. You got it exactly right. When you say this is a Django project, then lots of things start to surface for assistance.

Well, and that's, we'll refer back to the, we had Alexi on with you two years ago to talk about some of that work and I know it's ongoing.

So I'm curious just internally. So what besides you advocating for it, like how do the powers that be decide that this is the year of Django? Like what what's the forces that come together to make that? Is it just every year is a different major framework? Are there particular, you know, we were talking again offline about changes in terms of JavaScript and server side rendering. Like how does that all come together where you can publicly say like this is our this is the focus for the next year or so?

It's a good point.

In the past number of years, we with PyTorch, we got such a big scope.

The surface area is huge.

Surface area of Python is now huge.

Python isn't a market anymore.

Python is a collection of markets.

And products can get into a mode of, I'm going to do a little bit of everything.

And then they go through a mode of, I'm going to do a lot of something.

And so we're just kind of decided that Django is a really good affinity for us in a number of ways.

We have a long and great relationship with Django.

That's probably the best part of the prime part of it is that there is a relationship here.

Second, Django is for professionals and professionals who have a tendency to do larger projects.

where an IDE helps you in teams where an IDE helps you people who have a psychographic profile

where they value tooling like testing where IDEs help you and I'm saying ID intentionally because

the emergence of VS Code and PyCharm in the Python world over the last five years Python

A little bit behind JavaScript, but similarly is starting to value tooling.

Type hinting as an example.

Raise your hand if you would have expected JavaScript to be the one to get to really adopt casual typing.

You know, who's who's, you know, who's on the board of the JavaScript Foundation, you know?

So that's right. Yeah, that's true. And it's not, you know, not saying that is a bad thing, but, you know, it goes where things are. I mean, that's, you know, Carlton's often talked about being a fellow and less so on the board, but just balancing that tension of like the people when you're in it, you're working with or have the more complicated advanced use cases, but you still want to try to maintain friendliness to newcomers.

And I'm sure, you know, with PyCharm as well, right?

Like you can't, you don't want it to necessarily turn into AWS.

Like you want it to still be usable.

Well said.

And in your point, if you extrapolate it past something like JavaScript into the web and web browsers, there's a lot of different agendas at that level as well.

So for us and our kind of year of Django that we're doing, some really innovative product stuff that we're working on that we intend to roll out in the coming releases, content that we're working on, teaching, and relationships with folks like you.

And ongoing relationships.

I mean, is it five, six years, the annual partnership with the Django Software Foundation and PyCharm?

I mean, and that's, you know, that's a sizable portion of the Django budget.

Django really relies on that.

It's a third to a quarter.

I think Frank at a Django con I was at said it's 25% of the DSF budget comes from the JetBrains fundraiser.

Well, so I was treasurer for three years, and I guess I didn't do a good enough job of sharing the details.

But it would vary, but it would be, sometimes it would be a little bit more, but it would be around 25%.

Okay.

the dsf could be a little more open with our finances like there's nothing hidden like there's

spreadsheets forever on the board but yeah i mean you know psf puts out an annual report but again

they have a lot more staff than you know pete it's the people running it's not that it's secret it's

just that it's not been put on the web page right yeah well no i mean because a lot of the work i

did was you know trying to with katherine holmes was to standardize it but then i was at jangle

on, I guess it was just last year, and talking with Simon Wilson, Jacob Kaplan Moss, and sort

of being like, here's the nature of our finances, which are fine, but could be better. And they were

shocked. And I was like, wow, it really is hitting home. Like, how could they know, right? They're

not at the top. Jacob's now on the board, but he wasn't on the board. So yeah, there's value in

letting people know all that. Anyways, yes, Carlton, you had a question.

Well, the other thing that pops to mind is JetBrains, of course, is helping with, again,

with the 2023 Django developers survey which is on route I don't know if it's going to be on it's

on as we record I don't know if it's still going to be open when this episode goes out but if it

is still open folks go and fill in the survey because we need those it's people's it's people's

one chance to give us some feedback right I mean I give the classic example is we asked

what people were doing for caching and they're and like 90% were like oh we use Redis and so

We were like, should we have a Redis back-ending core

rather than a third-party package?

And so the Redis back-ending core directly came out

of the survey from 2021 or 2022.

I think so.

2021.

Yeah, it's been a huge...

I think there was one that Tim did.

There was a survey way back in the day,

but when I joined the board,

that was one of the things I wanted to bring back.

And so the first one was just a Google sheet

that I put together.

And then from there, JetBrains has really helped

both standardize it

and now they do the translations

because they're already doing it

with the Python Software Foundation.

So I'm very,

I feel like a grandparent.

I'm like, I feel happy that that's,

you know, I saw it come out this year

and I didn't have to like do it all myself.

Yes, Carlton.

What I really like is the sort of meta-analysis.

So JetMain's not only help us put it together,

but then they format it

and they do this nice infographic at the end.

But there's some nice little,

they look for correlations in the data.

I think there's one that was something,

it wasn't exactly this,

but something along those lines.

Older developers are more likely to use VMs, and younger developers will use containers or something like that.

I can't remember the exact thing, but it was like, yeah, that's brilliant.

It spoke to you.

Yeah.

Yeah, it did.

It really did.

And I guess I should say, if anybody out there has a question we should have asked, or if some of the choices of existing questions are dead projects and we didn't notice, let us know.

Yeah, I mean, it's difficult to update between years, right?

Because it's just one person's like, ah, I've got to put the survey together.

We need a way of researching.

Initially, Carlton, I believe, you know, I threw something together and basically relied on you and Jeff Triplett mainly.

I think we asked Adam Johnson and maybe a couple other people, but it was just like, well.

And then from there, it's, you know, gotten hopefully revised and gotten better each time.

But, yeah, it's a big bit of work.

If it is still open when this episode goes out, go and fill it in quickly, folks, because we need those.

And something else that will arrive when this episode comes out most likely is as part of the actually very intentionally as part of the year of Django campaign, we went through kind of a systematic effort at hiring a Python advocate at JetBrains on my team for Django, focused on Django, Django community for her own benefit.

of it. I will not say the name yet until she joins, but we are so wildly happy to have her

November 1st timeframe. And we will pick up the pace of things like the Django survey.

No, that's super, super. That's like an actual, you know, representative that we can harass

because, because you're all busy with the, you know, the pie cons.

Well, it's a good choice. I think I, I think I emailed you when I found out separately,

just saying here's my two thumbs up excellent uh she's wonderful well so so what will you know

what will be new now that there'll be a full-time person will that be the the point person for jango

things i know there's like what's yeah what is what's what's what's the in a year you look back

and say this is what we wanted that role to achieve what's the mixture of stuff good question

because it's you know multiple infinities of things that could be done right um the art is in

what you want to what instead of what you will do uh i believe in storytelling over a period of

time and knowing what effect you want to accomplish at the end and so if if she already has a strong

narrative of what she's about and what she wants to accomplish and then we can support making that

happen in the community and then we'll get you know the company will get its benefit along the

way but for the most part just support and stay out of the way equally someone really close to

the product a lot closer to the product than i am who can to jango who can then inform the product

pie charm about its jango support i was just before we started i was like carlton what do

you think about because he knows a lot more about jango than i do um and can inform the steering of

a product especially something we were talking about this kind of junior professionals that are

starting their career journey and that psychographic profile is really important to me well you were

just talking about we were talking just about the perhaps at the beginning now about ide's and why

you use the word ide and the contrast is well i've got my text editor and i've got my my terminal

shell and you know i i know all the you know i know every and like as a as a veteran it's hard

to it's not hard the tooling's lovely and the tool it's nice and smooth it makes it but it's like oh

i could i could live without that no problem but if you're a junior or an advanced beginner and

you're just sort of stepping up to that next level to have the tooling to guide you and to put the

rails down and to to show you the way it's like the good example i'm constantly using a git gui

because you know i can use the git command line but i'll tell you what a gui doesn't off make life

much easier but it's that same thing you know if i've got a tech you know if i've got the text

the test runner showing all my tests i can see which ones failed i can click through i can

you know jump straight to the source code that kind of thing that tooling it really helps me

do my job more effectively you know regardless of whether it's pie charm or you know some other

option indeed and i'll i'll use the same framing you finished with regardless of what tool it is

that level of tooling is a way of development that in the world of python we don't promote enough

python is really simple you can just engage python is you don't need a compiler like

java or dot net or whatever so there's a temptation i could just use them

yeah but you know a lot of these projects are pretty big and some people could use the rails

that you described i mean because if you come from c++ or whatever or you know c sharp even

you've you know you've got the whole microsoft stack and all the tooling there then you just

crack open your text editor it's it's a different world right but it is i i still remember i think

it was five years ago now when i was visiting a local university that was teaching my book and

they were asking me all these questions and then i didn't understand them until i realized they

were all using PyCharm, the education version.

And I was like, oh, okay.

That makes more sense because

it's just powerful.

I think it would start up

I don't know. It was doing some stuff that I wasn't

familiar with using a text editor

as opposed to an IDE.

Which leads me into a question of

So there's a big educational licenses, I believe, are free.

Is that right, with PyCharm?

Yeah, and open source.

So that's a big – so then how does the company think about that leap from, okay, I used it for four years, and now that I have a job, there's the professional version.

I would imagine that leap is a big one, right?

Because you don't want to lose them, but all of a sudden they're like, wait, I have to pay for it.

Though, of course, they just paid a lot of money for college.

What is that? How do you view that funnel?

What's the value proposition? That's what you're describing.

What justifies paying for this? Is that kind of where you're going?

I guess it's just, it seems very smart because they're used to a powerful IDE.

And then compared to that, everything else feels like a text editor.

If a company tried to tell me what to use, I would be out the door quicker than you could say it.

But I'm an old, I'm an old crusty hat.

I mean, I don't know what junior, you know, do juniors turn up?

Here's your laptop.

Here's your thing.

Right.

Is it, is it typically like for these advanced beginners or junior developers, is it a company

account where they, they buy a bunch of PyCharm licenses and give them to their employees?

Or do they let like these days employees make decisions and charge it back to the company?

Or is it just all over the place?

First, for the record, Carlton is a young hack compared to me.

Well, he's an old hack compared to me, so everything's relative.

All right.

Not that much older.

We've got the hacking order straight here.

Okay.

Going over.

You're both right that most companies these days have adopted a policy of letting their highly paid developers choose their environments.

because developers can choose their employers yeah the good ones yeah going maybe maybe that's

a little less true in the recent round of layoffs but uh you want a you want a developer to be the

most productive they can as quickly as possible and so they probably have a couple of options

for what their internal it department supports uh for something like us we feel pretty traditional

for them for other kinds of software companies there's an internal license server that you can

use when once you reach a certain number of licenses and there's a pool and you can administer

the purchasing and make it available to people and stuff like that and that's an area that we

have been going more into supporting with some of our tools like toolbox to helping companies

administer tooling now back to your other question or kind of meta question about the

value of tooling i've got opinions on this so for a lot of these shops developers are pretty

important wouldn't you say software is kind of important these days right if you look at like

the median salary of a developer the cost of like pie charm is their first minute and 20 seconds of

their work day so all we got to do is make them more productive than a minute 20 seconds you almost

like maybe you have this somewhere just like a side by side of like you know django hello world

with like a text editor in quotes and then pie charm and just show like the speed difference

yeah because part of his part of the challenge right is that people don't know what they're

missing they don't know what they're missing right unless and you get locked into a pattern

and that's i don't know i find like for tooling like the only way i besides just chatting with

people is like when i see people doing you know occasionally things on youtube and like oh that's

sort of interesting like and i either like or dislike what they do but it's i feel like for

beginners there's a huge leap to like if i showed how i was doing something or any of us like we

have git aliases we have all these things that you know the speed at which we go is different

no one's going to catch up with that per se and takes a lot of work to be like to make a course

out of here's how i got to that level of productivity without um you know i can speak

from personal experience it's a lot of work to put those together um so i just yeah just wondering

how you you know i know you do a lot of youtube tutorials um as well like how to like guide

someone up that ramp? Because I would imagine sometimes it's hard to get across how much more

effective you can be with these tools than just doing it your old way. How do you tell someone

they're being slow, basically? There's a book inside JetBrains advocacy that we really believe

in. It's called Badass, Making Users Awesome, I think, by Kathy Sierra. And in there, she talks

about the suck zone and she also talks about um like with photography people want to mac master

taking photos not master the camera so so make them good at photography don't make them good

at cameras and we we as advocates tend to get really jacked up about our ide and let me show

you what the ide can do and we need to be better at showing you how you can be better at django

so we really got to think about that and keep our eye on the ball when it comes to what you just

described someone that's just trying to get their job done carlton you want to add to that well no

i was just nodding because i'm like if i think about the best demos i've seen it's it's not a

demo of the tool it's just a demo that happens to be using the tool if that makes sense and it's

like oh what did he do there what did she do there that was kind of cool and then like you find you

learn a little thing but they weren't talking about that at all they just did it you are spot

on and we need to be better at like leading with it and we say this all the time leave with the

technology slip the ide in the back door yeah exactly um in fact the perfect perfect demo is

one where you never say pie charm but somebody pulls their hair out what tool are they using

show me how to be like that um and so that that's an area that we got to get better at

speaking of things people pull their hair out around django i mean deployment um i was just

curious what's the the latest story and path um i mean not that there's a silver bullet for it but

i imagine you you all have thoughts on that sure that is a place that's getting a lot of attention

at jet brains we actually have a pretty good angle here because uh we're independent of all

the cloud providers right which is which is rare yeah yeah yeah yeah so we we don't necessarily

have an agenda we we we are not some cost center that is trying to it seems like every startup

i'm sure you're gonna laugh as soon as i say this it's like every startup they get some vc funding

when they talk about the monetization strategy well we're gonna have a cloud we're gonna you

know we're gonna have an edge service that we're gonna charge for using our open source tooling

okay um we try to take a a direction that is somewhat independent we are the lens that people

look at their code through

and people trust us for that.

We've got to maintain that trust

so that people don't feel like

we're going to steer them

to our deployment strategy

or something like that.

Now, that's also a tough one

because there's a lot of deployment strategies.

And so keeping up with all of them is a challenge.

Acquire Button and offer a turnkey solution

for all the providers.

Button needs more users before it can be acquired.

But I would think on that, you know, from where you sit, Paul, like I agree with that.

On the other hand, I know that if you're using VS Code, they can bundle and say, here's some credits on Azure.

Like when I was at startups with funding, like, yeah, it's like, oh, they would compete to offer you, you know, X amount of dollars worth of credits for stuff, which isn't the same as real money.

But that can sound enticing in a way that, like, with experience, choosing what you want to use and having control, you kind of have to get burned a bit to value that.

But at the same time, people should just understand and be cool with that arrangement, because that is the thing funding a massive amount of engineering work, giving them a valuable tool at a cost of zero.

their data but yeah what's the well what is i mean if you lay if you look at the tool like what

actually do people pay for they pay for deployment they will pay for some sort of performance

security like look at sentry and you know there's a lot of other areas it's just like you're not

going to get blood out of that rock um so but maybe carlton i interrupted you before though

you had a point no well the the other thing i wanted to ask about was um so um jet brains have

got these nice little letters called fleet um which is that's still in preview is it that's

looking a lightweight i quite enjoy playing with that and one thing i've just wondered is if say i

had pycharm installed if it could somehow hook into the django integration in pygram so it could

be because it hasn't got that and i was just wondering if there's any possibility of that ever

just ask you about the status of fleet sure uh so just to explain fleet is like jetbrains next

generation ide it has a different ui different ui stack it's intended to be polyglot from the start

its big feature is it's distributed from the start uh the front end and the back end are

separated and can be in different processes even in different locations even in multiple

locations multiple back ends and you can kind of attach on a remote container that's right

Indeed. Indeed. A remote container. The back ends contain the brains of our current IDE. So we're not starting over from scratch. Mostly. There's still some wiring up, as you discovered with the Django integration, still some wiring up to kind of close the loop on it.

But when that arrives, it will be a different IDE experience that will be a great fit for mobile users, distributed users, IT companies that want to provision a back end, make it available.

It's always warm.

It's always indexed, all those kinds of things.

Okay, cool.

Interesting.

So, were we going to talk about testing a bit?

Sure.

uh the kind of the biggest one is stuff that we already have available and we want to polish and

do a better job of telling a story about first of all we mentioned before about the the django survey

i remember the first time i saw a pie test overtake the django test runner i was shocked

that it's do you trust those results i think probably i do trust them um i mean you know

I'm an old stick in the mud, so I'm still using, you know, the Django test runner.

I'm still very happy with it.

But, you know, quite often when I'm working with client projects, it will be like, you know, PyTest, PyTest, PyTest.

No problem.

But yes, I think it's...

Same.

I sort of have an old-fashioned...

I don't always use PyTest.

I still kind of old-fashioned that way.

But everyone else that I hear just immediately goes to PyTest.

Let me question the questioners then.

Second question.

stick my fellow sticks in the mud class-based views or function-based views

well it depends

so i i use class-based views almost um almost universally it's for me it's um my views always

get gnarly they always get whatever and i i like the namespace that a class gives you to

to break them up um but i tend not to use to what i don't do is with django's generic class-based

views is get into massive overriding of the mix-ins and all the rest because i think in the

django community there's this constant debate and it's often um conflates class-based views as a

general thing with the specific implementation of class-based views of generic class-based views

that come with django and no question those are super complicated and the inheritance structure

is um you know it's too complex it's there's too many mix-ins too much superclassing overlapping

with fat models versus skinny models um a little maybe um putting too much in

how is it like so i write when i write a class-based view it's like class and then

the get handler and it reads like a function-based view but it's indented one level and you've got

the namespace to break up you know the various bits and that's that's it whereas if you if you

and the class but the generic class-based views are great if you don't need to override specific

methods or work out what the call order was but otherwise you're digging into

classy class-based views and it's like ah what's the method and where is it yeah and it's just no

So I understand all the people who love function-based views,

but the answer to your question is I use class-based views every single time.

Will, how about you?

What stick do you have and which mud?

I mean, Carlton articulated it better than I can.

I would say I try to – I go down, so I start with generic class-based views.

I don't mind overriding one or two methods,

but at some point you just need to go, as he said,

just define your get method and use the namespace.

I don't, you know, honestly, in my day-to-day, I'm always trying to find the simple, elegant way to do it.

So I really, I probably overemphasize using generic class-based views, definitely class-based views, just from a teaching standpoint that's a lot simpler.

There are a handful of occasions where you need a function-based view.

But, you know, it's like there's a reason why class-based views are used.

There's a reason why the code base is in that.

Like, I'm not going to, it's a religious debate in a way.

But if someone asks me, it's like, I'll take generic class-based view, class-based view,

function-based view in that order of preference.

But I totally, I also understand though, I mean, one of the things I'm adding to the

5.0 edition of my beginner's book is I'm adding more function-based view things because

I think it's probably an easier way to think about how the request response cycle in a

way that if I just jump to like template view, list view, detail view, people are going to

missed that so i'm adding a lot more of showing both i always i i didn't want to for a long time

because i was like this is going to totally overwhelm people and i think it will a little bit

but yeah i think it's from a teaching perspective it's helpful whenever this topic comes up people

always mention luke plant's essay um jango views the right way or function-based views the right

way i can't remember exactly the type but it's a polemic and he says at the beginning like this is

polemic. Don't take it too seriously, but he means it. The sort of big challenge he

puts to class-based views is, well, where's the view gone? The view is a function which

takes a request and it turns it into a response, right? That's the web problem. Take requests

and turn them into responses. A function-based view wears that on its sleeve, whereas a

class-based views when you just see you know list view model is this and it's like where's the view

where's it gone um and so i think you know to if from a teaching perspective to teach people that

is dead right yeah because you show them the the request goes in there and the response comes out

there and then when you switch when you move to class-based views i think it's really important

to show them the actual handler look there's the handler on the class-based view and it takes the

request there's a response and it's just the generics you know they've abstracted all the way

you don't write that bit yourself and you just declare these forms and you know these fields and

magic is done i think it's also me becoming what i didn't want to be when i wrote the book which was

that you know most engineering books well i was always i was always a purist carlton don't worry

about that but like you know most engineering books or are bottom up right it's like well i

don't want to just give you the answer. I want you to like work hard to get there so you understand

the answer. But you know, when you're trying to build a website, sometimes you just want to build

a website and then backfill a little bit. And so certainly the early, earlier versions of the book

were more show than tell. Um, and I just keep adding in tell, but I think I just need to make

clear to people like this is tell, but you don't have to know this right now. I'm just putting it

there for like, I want to have both. I'm trying to have my cake and eat it too. Cause I value the,

the telling more and more as i get into it and as i deal with people but i also understand

they need to just like get a hello world working deploy a site like they don't want 400 pages to

put up a site when i can just show it to them in three pages and then be like let me explain how

that actually worked i think there's room at sort of the end of your beginners like you did but i

agree with you 100 for the beginning you just get get them to the success point quickly without all

the backstory but then somebody who's going to perhaps in your professionals book i don't know

But somebody who's going to go off and build web applications, there's going to be the point where they're like, do you know what, the generic stuff just doesn't do what I want. And I need to, I need to just turn a request into a response and understand being 100% clear on that request response cycle on the web problem. Yeah, you know, that's, that's equipping them for a career.

Yeah. Well, this, I mean, Paul, you know, you educate people like this is the challenge when you sit down with someone, you can tailor it. But when you're doing a video or a book or an article, you have to kind of guess and pick a layer of like, what are they going to, what are they going to ask next? So that's, yeah.

How did we get from testing to this?

That was going to be my segue.

You caught me monologuing.

I prefer class-based views for a number of reasons.

One, the IDE can give you more assistance on that.

And second, well, I'll go off on a little bit of a detour of an anti-pattern.

In the world of Python web frameworks, for a period,

and, oh my God, for damn sure in JavaScript frameworks,

there's this race of, well, my hello world is only five lines.

So it's way better than your framework's seven lines.

And everyone rushes to adopt the five-line web framework.

It's okay to write a little bit of code.

You know, we've got smart tools.

We've got VS Code.

We've got PyCharm.

They'll generate a lot of this for you.

And just because you have a great first five minutes

in a miserable next five years make better decisions people so um okay that's interesting

yeah it was old well that's that's um i was just last week talking with someone carlton has a talk

on this you know django can be a micro framework and there's a repo i just will put a link in from

four years ago which makes me feel old showing how quickly you can get to hello world with django

So, and it's like 10 lines maybe.

And, you know, even Flask, if we're just going to, the obvious comparison, like they show Hello World, but that's not how you build Hello World with Flask.

So I think they've solved that marketing problem better than we have.

Yeah.

And Pyramid came out.

I'm one of the Pyramid guys.

I was Zope before that.

And Pyramid suffered greatly when like six months later, Flask comes out with its five line Hello World.

everybody thinks it's just the magic whereas pyramid oh my gosh the conveniences it gives

you over the next five years are amazing but people just don't see that during the first five

minutes so back to class-based views and testing i like this pattern of being able to instantiate

the thing that's about to be rendered and then test that thing that was instantiated

and to move some of the stuff out to make it easier to test,

like properties on the class that's the class-based view or something like that.

And I just find that to be on the way towards my theory of testing,

which is testing ain't about eating your vegetables.

It's about joy.

And what is the more joyful way to develop?

What isn't joyful for me is I've got my editor,

I've got my terminal where my test runner runs

or my dev server runs.

I've got my Chrome browser over here

and I'm always going back and forth

between all these different things,

contact switch, contact switch, et cetera.

And wouldn't it be great if I had like one environment

I could sit in it and I could run my tests,

execute that view under the freaking debugger.

And whenever I have a question, I just set a breakpoint, run my test.

I stop right there.

I can poke around.

I can see the entire universe at that point of execution.

I don't have to do print statements or in JavaScript console logs and all this other crap.

I don't have to go over to 50 different tools to find out the universe.

I'm right in my editor.

right where i'm typing is where i'm executing and is where i'm digging yeah no i mean a debugger is

an amazing thing and it's an amazing thing it ain't just the bugs no but a graphical debugger

as well like ah here's my favorite um trick trick is the favorite cheat is um i'll go halfway through

a test i'm like what's this uh i don't know what this is but i can put a break point in the test

and then i can find out what he said especially i mean let's face it in the world of python it's so

dynamic that stuff just pops into scope oh my god if you ever try to answer the question of where

did sphinx get that pixel from good luck you can't know the answer unless you set a break point you'll

never find the answer by looking around on disk and so what you just said is exactly right you

just set a break point, run your test. Life is so good. Why don't people want this? Will,

what's wrong with these people? Well, I was just telling you, I have a future course planned. I

mean, people Google Django testing tutorial. I think I'm near the top of results. I think the

problem is at what point do people say, read the manual. I just want the docs. And that happens at

some point um but you know docs are i like to say now docs are designed for if you already know what

you're doing and you just need like oh what's that thing called whereas a tutorial teaches you so the

docs are not going to teach you how to do a thing they won't tell you the why oh yeah what but not

the why yeah well i think maybe django docs are pretty good at the why but they don't give you

the context i mean compared to other docs well yeah okay but like they exist for a start so no

but like there's a so to take this exact example there's a section in the advanced testing tutorial

which is testing class-based views but it's it fits on like one screen it's two kind of examples

and if you like it shows you how to instantiate an instance of a class-based view and then you

can call individual methods on it right but that could be like two chapters in a book you know

really showing you how you leverage that and how you know how that enables you to test the methods

in isolation and how you build up you know a really good testing but the django docs haven't

got that they've got these two examples which kind of if if you just need a reminder they're perfect

but if you're learning that for the first time you need you need somebody alongside you to say

hey look at this and this is how we could use this and this is the patterns it unlocks well i'm gonna

i'm gonna do it i mean there's also at the higher end there's like adam johnson has his speed up

your django test book which is amazing resource and that's probably smarter because that's like

okay you value tests but let me show you how to make them better um but how do you yeah how do

you lead a fish to water how do you tell them what life is like without tests if they don't know i

mean one way in a way unless you work with other people like like working on another project

reinforces that for beginners so if you airdrop into a project and you write some code you're

like well that worked why is things breaking it's like oh because there's other you know whereas i

think there's a sense that you can have everything in your head a little bit when you are doing

everything so that would be pedagogically that'd be interesting to like airdrop you into a project

and be like just do this simple thing oh and run the test suite and then just a million things break

sure because you don't know what's going on yeah and i i hope you're right and i hope that i get

to march in your army as you help convince people with your book about this um and i think there are

things that can be done like have ai write your test based on your last test so really lower the

the friction lower the barrier get tests to be closer to the code like a companion to the code

but there's also something i don't know have either of you heard about in the world of

javascript something called storybook storybook is the thing storybook is portuguese portuguese

is the language if i think i know what it is but i don't it's portuguese storybook is the thing that

i think i know what that is but not really no i've seen i've seen the name a couple of times but no

i've not it's a way of development of component driven development using stories and you write

a story which is kind of like the setup for the variations of that component and then you go over

and run this tool and in the browser you see a listing of all your components and click on it

you see that component rendered and it re-renders as you type and it renders all the variations of

your component based on inputs and the paths and all of that and that's the story that you write

it's like a catalog of your project but guess what you can feed those stories to your tests

so you don't think you're writing tests maybe there's a way we can trick people into doing

things that can be tested because those are the things they want to do they want to see the

rendering of their snippet like test book or something yeah test book yeah i think i actually

have a package on pipe yeah i called story time where where i'm trying to do it but it's it's part

of a different effort um but maybe just at a large sense there's a way to get something like testing

into the workflow they want

instead of eat your vegetables.

Yeah, it shouldn't be a burden.

Part of the teaching thing is I think

there's a number of,

there's a couple of resources

that are test-driven development.

So testdriven.io,

Michael has some,

Obey the Testing Goat.

I think those are-

What a great website.

Which one?

Testdriven.io.

Yeah, it's a very good one.

Yeah.

But I think that that's off-putting to beginners.

I think I'm not against, well, I don't do test-driven.

I think most people don't do test-driven.

I think the problem is if you hit someone with testing is test-driven, they just go like, well, I don't even know how to build this, let alone test it.

So I think that's part of the problem with testing is that it's not done that way.

But it's unfortunate.

Carl and I were talking about it a few minutes ago.

There is this way of development where you just sit, you stay in the flow, stay close to your editor.

Everything is brought to you, and you can set this debug breakpoint.

I will also say, when it comes to testing and debugging and running of code,

boy, is JavaScript kicking Python's butt.

Tell me the hot reloader for PyTest.

Oh, it doesn't exist.

But hot reloading in Python is just a horrible and difficult problem.

It's not really solved, is it?

Yeah, Relodium has taken a good stab at it, but it's just not culturally there.

Can we, I don't know if we can shift gears, and we were talking about HTMX and JavaScript.

Yeah.

So you had, there were some toots, tweets about things recently.

Do you care to share that story?

Sure.

I think all three of us are, but particularly Carlton, since he's put a lot of work into this.

We're big fans of HTMX.

yes it's just super yes which is a project to bring back server rendering of html because

that's the web that's the way the web's supposed to be um and htmx lets you get some of the benefits

people have moved to spas for you can keep your existing stack you can keep your non-javascript

programming language you can stay with python and get some of these benefits carlton would you agree

with this yeah no i mean absolutely like so you know i've been working on an application for the

last six months and like it's we're six months in going really well and i've got four endpoints i

use json response four times so it's not just a it's no longer api first it's api maybe like maybe

there's a rich component that needs some json so i you know there's four related to one bundle of

views there's four uses of json response and that's it the rest is just html thank you very

much and it's it's lovely using a set of technologies you already know and trust

and not just know and trust that have got like 20 years worth of development behind them it's not

you know, this week's framework or, you know, some new tech that's experimental and won't be

around in six months. It's the oldest stuff in the book. And it's like, I was writing stuff like

this in 2005 and I'm writing it again in 2023. And it is wonderful, just wonderful.

So I'll transition that to the rest of the story. Half of what Carlton is saying is I already know

Django and Django can render HTML. I don't have to send it to the browser to render

JavaScript to HTML.

So it isn't just Django rendering the HTML

that we already know and love.

It's HTML rendered by the browser

that we already know and love.

The web has a platform.

It is super good at this.

We don't need to put the HTML and the CSS

into JavaScript.

Carlton?

Well, I just had a moment of joy

as I remembered what I was doing today.

So I've got a detail.

view and that has a nested um or a bit a section of data which is quite computationally expensive

and it's a bit slow to to render and so to make it fast i just literally um load that separately

so i just have a little hx get on load you know a thing and it pulls it in in afterwards so it

loads the main page and the page is instantly responsive instantly rendered and then the little

bit of um of the little bit in the section the table of data which is a little bit expensive

to generate that comes in maybe a second later but it's not the page isn't stuck there waiting

for it you know and it's just like how joyful is that and the you know the people looking at

they're like oh this is great this is really and it's just like but it's the oldest rope in the

box you know it's really we just need to call it full stack and be done with it be like we get your

full stack right here no but okay again we talked about um money being tight now and you know um

we talked about in the current climate um it's it it enables me to build an application single-handed

in a way that i literally wouldn't have been able to build for the last decade like perfectly said

but there are other business reasons that's a great business reason right there bringing

the artisan back the way it was 10-15 years ago there are other business reasons what about blind

people a lot of these these spa front ends could care less about that what about a 3g low-powered

phone in a remote part of the world a lot of them have a really bad story on time to first

content paint which then impacts their seo score you'll get a bad seo score google might index your

spa once a month and they may give you a bad core web vital score on it so all these are making

people rethink the spa front end react front end of vacation of everything but a large part of it

carl is what you said carlton it's exactly right i can't do all of that can i use a technology that

just works can we go back to that and make it better and so um carson the creator of htmx put

out a post talking about the loss of view source in what google's uh search page looked like in

2003 versus the indecipherable optimized mess it looks like now and one of the things we might

of lost is being able to look at the web and so i made a counterpoint to that and strangely enough

the creator of javascript replied to my tweet saying that if we want to get back into that game

there was a time when html wasn't abandoned where we didn't have to do everything in javascript it

was the time of html5 with the what working group where people in the community came together

kind of in opposition to the browser vendors and one instead of a world of xhtml2

we have the world of html5 and so he was encouraging us to stop complaining and say

hey html is good enough let's make it better let's not make it he was responding to me saying

that the web shouldn't be a big javascript runtime i mean and the the the um the htmx sort of um

sales pitch for one of a better word is it's just adding attributes to you know it's just making

html more powerful okay it uses javascript to do that but it's in a very controlled and small way

you know like why is it that every element isn't clickable or can't send events why is it you know

So do you think we can get browser vendors to implement this stuff?

I mean...

It's an interesting point.

Five years ago, would you have predicted that CSS would have a renaissance?

No.

CSS in the last few years, even Safari.

I'm a big fan of Safari.

That's my browser thing.

Last couple of years, it's just really come on.

It has really come on.

A's are a thing in Safari now.

And Chrome with its security stuff just constantly, like, every profile you have to, like, change this, you know.

This is also, like, this is a philosophical thing.

Like, why do we have to, like, opt in to, like, security and all our stuff, like, instead of the opposite?

Like, we're, you know, the onus is on us to say, no, don't sell all my data.

Well said.

And Google Chrome recently getting pretty shifty.

Yeah, I mean, maybe. Yeah, exactly. I mean, but all this, all this is, again, it's the needs of solo developers or small developers and also big corporations in that if you go online and look at how is like every, every week, if not almost every day, I get someone saying, shouldn't I use like, you know, Vue or React and all this stuff for my solo project that I'm building, like on the side?

And I'm like, no, no, no, no, no. But everything that they read online is here's how to do full stack because, you know, who's writing it, who's employed people at larger companies. And it is true that if you work at a company over 10, 20 developers, there's probably a dedicated front end and back end, you know, and you're probably only writing a, you know, so how do you, you know, it's part of it is I try to tell people like, that's just how it is out there. It's not nefarious.

totally right you know who's there is a counterinsurgency now there are important voices

pushing back on the people use react because people use react it has become that way that's

the reason people use react yeah how do the three of us fix everything make django great man

well it is it is great yeah we just got to talk about it more story uh give that guy working on

htmx snippets for django give him some money keep them happy django forever yeah so okay so we want

to get django partials or at least the tooling for that into django i don't you know so um 5.0

has just done the feature freeze so now okay 5.1 need to make some changes to the template django

template parser which i've kind of just done horrible things in django template partials as

a proof of concept so we get an official api there that can use and then whether or not janga

partials template partials itself becomes part of janga i don't know but improving the template

language there there's there's a renewed discussion about like a kind of um capturing tag so you know

say you've got a pagination um thing and you would want to render that twice on the page once at the

top once at the bottom it's quite a heavyweight component so you want to render it capture the

html into the context and then just output that same html again when you render it later rather

than render it twice because it's expensive that was there was a ticket for that number 6 000 and

something closed 10 years ago it's like okay as a oh where do we need this who knows somebody maybe

i don't know but you know it's discussion to reopen that there's this you know there's things

like um template tags rediscovering those and how to use them and what the patterns around those are

and super powerful big you know i got um i want to pass a model object into a template but i need

some i don't really want to pass the whole model object i want to do some transforms on it and you

know fit some related properties and what so what i really want to pass is what's called a view model

it's like a it's like a special object which gives the template exactly what it needs and no more

just simple attributes so i can calculate that in my view and pass that in but you can use template

tags to kind of do that view model type thing and then that's all in python and it's all testable

and then you've got a really simple bit of html which is a template and the two just go together

in a beautiful way and you're what you're not doing is got these gnarly templates with ifs and

loops and you know function calls in and all the rest of it which is totally unmaintainable and

not really editable because you like you're describing something that's consumed the last

four years of my life including this weekend bringing component driven development to python

and in fact for 3.13 jim baker of jython fame and guido are working on tagged template strings tag

strings a pep already have an implementation i'm helping write the pep on it and it's a way to do

basically app strings that can run through a function and then jim has an html templating

language built around that which is just so interesting yeah no i mean there's we need a

renaissance into thinking of python templating yeah it's not asp from 2000 anymore that's not

the way people develop anymore people think in terms of components call the pep off the top of

head so we can link to it for people to uh we have not published the pep yet oh okay it's over there

on my hard drive you can come over i'll show it to you oh that's kind of exciting so you're big on

you you're bullish on hdm expo you're completely bullish on it i think it represents a set of ideas

that i would like to be actually foundational whatever it is i wind up doing and hopefully

this Django work that you're talking about, maybe they'll actually converge. Who knows?

It would be great if it was re-imagined in the context of partials, components, small pieces,

not rendering the entire thing. Just at the most fundamental level, you don't even have to think

about it. It's baked in, which is the direction I think you want to go. You've been working on.

Yeah. And what you were talking about 20 minutes ago about testing and like pulling out the individual bits and making those testable. And then I guess that would feed into the UI work as well that you.

my interest has been in reinventing sphinx uh sphenix is what i call it and so i have a view

layer for sphinx and i um have kind of reimagined the templating it doesn't use genja and the idea

is an ecosystem of reusable components i could write a component it would work in sphinx or

pyramid or django because it is insulated from its outside world and it's able to it it's able

to get stuff from the outside world it's able to be given stuff and you see this a good bit in the

world of javascript yeah and in principle that's the idea of web components as well indeed exactly

I mean, framework-less components.

It does also, this HTMX and all these things speaks to either the wisdom or the good luck of Django always having a separate templating language and not doing anything about it.

Even though, you know, 10 years ago, there's a lot big push to like, well, Django, you know, why didn't they do more?

Why don't they bundle more in?

And now it provides the flexibility to be open to these new technologies and where the pendulum swings in a way.

Because when you put something in, you can never take it out.

Well, it's batteries versus magic.

I forget which of our guests made that point.

And I really like that, that Django is batteries, less magic.

Because magic is maybe more like Rails, where it's just like, boom, zero to 60.

But then what if I want something different?

What if the ecosystem changes?

Sure.

Yeah, you're stuck with it.

Whereas batteries, a little more work to put them together, but they're there for you if

you need them or don't use them.

That is wisdom.

Carlton, you agree?

Yeah, I'm just thinking, like, I'm desperately trying to not ask Paul about docutools.

I've got an idea.

I'm sure you have, but that's a whole different road.

But, yeah, no, I mean, again, just thinking what you're talking about, the Django template language there.

And, like, the way it makes you write these template tags to encapsulate your logic rather than letting you put logic in the template.

you know i grew up writing php and you know i've always liked the dangle dangle template language

for that but coming back to it after all these years of doing json endpoints left right and

center it's like oh yeah actually this is a really powerful pattern and it's it's dead right and it

enables you to do the the transformation logic in python and then if you know if it's rendered as a

list or a table or a thing that's just a little html change and that even that can be a parameter

And it's really flexible.

It's just lovely.

This is, you know, this is Carlton post-fellowship where he's, you know, it's like he can do all the things he wanted to do.

He can poke holes, come in from the outside.

He's like red team.

You know, he's like, where are the weaknesses?

We should have a post-fellowship program, right?

Neapolitan is my crowd views.

I take on crowd views.

When I put that together, I put it together in like, you know, an afternoon sort of thing.

the first sort of you know take of it i i looked up when i first thought of that and the note that

i first thought of it was eight years ago it's like that's been on my background for eight years

i could have done that eight years ago but well but could you yeah could you i didn't have any

time and i didn't have the capacity i wasn't sat there building a fresh project having to the

prospect of writing all these crud views and writing a list view and no i'm just i'm writing

the class i always wanted to write because i'm not doing that 58 times for this whole life of

this project that's how crowdview came about well we're gonna have links to all this stuff paul is

there anything else as we wrap up that you wanted to mention or that we didn't cover it's time for

us to all have more fun um it's time to have fun with python and web frameworks it's time to have

fun with django and new ideas um new patterns in testing new patterns in htmx and uh i'm i'm in the

joy business these days and we should all remember how awesome it is that we have it we should help

the next generation of people take over get them in place let's have the new heroes replace the old

heroes and um let's spark some innovation let's have python not ship its a its ui layer to

javascript there it is yep boom mic drop

well i'm sure we'll we'll need to have you on again shortly especially with this this year

jango and hearing about all the work that will happen so look forward to that links to everything

in the show notes um carlton you take us out yeah thanks thanks so much for coming on paul um really

enjoyed the chat um so we're jango chats with jango chat and mastodon and mastodon yep chat

dangle.com see you next time if i may steal the mic before going yeah do do do both of you for

everything you've done you've got to be in podcast number 5000 territory uh community is lucky to

have the two of you will i look forward to marching in your army on uh getting people to

work better um and hopefully i come back on in a year and we we look back on this and reflect on

what's all transpired since then yeah amen sounds perfect all right everyone we will see you next

time. Bye-bye.