Transcript: Being a Productive Developer - Nick Janetakis

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

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hello, Will.

And we're very pleased to have Nick Jantakis join us again to speak about web development,

Django, and other things.

Welcome, Nick.

Hey, thanks a lot for having me.

Yeah, thanks for coming back.

It's fun to be back after, what was it, about two years or so?

Yeah, two years.

So let's see, last time we talked a bit about Docker and Flask, and you're a really interesting

guest because you know Django, but you also work day-to-day now with PHP. You have a lot of

experience with Flask. And so I think maybe we'll talk about more generally web deployment and not

just narrowly Django as we usually do on this show. But maybe what's changed for you in the last

two years since we last spoke? I believe you have a full-time job now.

Yeah. So it's been, let's see now, in September 2021 is when I started a full-time position.

But yeah, I still do the courses and YouTube videos and blog post stuff on the side.

So how do you, here's my immediate question.

How do you have time to do a full-time job and courses in YouTube?

That is a very good question.

And there's a reason why new courses haven't been posted in a while.

Because yeah, I mean, when you're working a full-time job, it's like 40 hours, give

or take a week.

Like, yeah.

And you got to be protective of yourself, just your own time, right?

You don't want to be grinding full-time job and then it's like 10 minutes to eat dinner

and then it's like four hours of doing courses after.

you're going to get burned out doing that all the time. But for me, I've optimized things to

the point now where I make a new YouTube video usually on the weekend, like every Saturday or

Sunday. And honestly, it depends on how long the video is, but it's not too bad of a time

investment. Let's say maybe two hours all in to make like, I don't know, a 15 or 20 minute video.

Okay. That's fantastic. And we may have discussed this before, but what do you use for that? Because

I've got ScreenFlow going and I think, yeah, okay, that's about right. But there's lots of

depth in it and i'm thinking always scared to commit to the technology what what do you recommend

yep uh right now because i am using windows i do use a tool called camtasia okay and i think

there is a port for that to work on mac os as well um yeah it's pretty i don't want to say

bare bones like it has good features but yeah i don't know it's it's whatever you get used to

like i've made like 600 videos now so it's like i'm familiar with all the widgets you're you're

a madman with your productivity i remember when you were still doing the podcast i was like you

know slow down a little there you're making me feel bad because you were just you know week after

week for how many was it that you did was it it wasn't quite a hundred i don't think right it was

like 60 or 70 oh i had quite i had to hit 100 mark it's like i did 102 or something on it it's

definitely 100 plus yes because we had switched to every other week and then we take breaks and

you were just relentless with it maybe um just to go back like what was so this is the running

and production podcast, which is fantastic. Lots of things on Django, but other areas,

what was, you know, with some time away, how do you look back on, you know, what the good,

the bad, like, how do you feel about it now? I mean, you're still doing YouTube videos,

so you're not completely burned out from teaching, but you know, how do you, yeah,

how do you view the podcast experience in hindsight? I would say if there were infinite

time, I would still be doing it for sure. So I don't regret any of it. I don't know. It was

awesome because i kind of kind of got a chance to speak to like 100 different people uh from all

different walks of life right someone who just graduated high school like their first app ever

to like you know billion dollar company type of thing so it was cool yeah just to talk to different

people so i don't like regret the time spent uh but yeah there were certain areas that were just

like major burnout inducing uh things as as you may know from doing your own podcast well i i think

i told you i mean having a co-host keeps it going right i mean just to have someone else to

the ups the downs someone to say hey let's you know let's do more let's do less i think it's

anything solo is really hard especially a podcast given it's so much kind of hidden work right i

mean for an hour-long conversation i think you even said at one point you estimated like six or

seven hours total or what was your calculus for how many you know for a given episode how much

actual time did it take to put it out yeah about six seven hours is a reasonable estimate and

that's everything from like finding the guest and, you know, coordinating some schedule and then

recording the show for an hour, hour and a half, and then doing the editing part, the show notes,

putting it all together and then shipping it out. Yeah. So I think that's the thing is that it's,

it's just all the rest of it, right? It's like the conversation is the fun part, but it is,

it's, is it quite, it's probably a little less for me just because I have Carlton's that helps,

you know, with chatting and stuff, but it's still, it's still probably a good five hours

per episode total and like you know out of 40 hours in a week you know ostensibly that's it's

a chunk i mean it's basically a day like basically you know we're recording on a tuesday i basically

take today to just do all the stuff and try to set up guests and so you know it's 20 of my time

when we do it but we don't do it all the time um yeah well either carlton you have you have

questions i mean what were what were some of the i don't know highlights that from the guests

because I agree. For us, having the podcast, it's amazing. We're speaking to amazing guests in all

realms, walks of the tech world. And it kind of keeps my excitement up instead of just the computer

and reading blog posts. It's like, oh, there's people and they have passions and interests and

they introduce me to things. It kind of keeps it fresh for me, at least. Did you find that to be

the case for you, Nick? Yeah, for sure. Yeah. What about you, Carlton? You're tired of talking

no i i like having the guests like um you know the bit you said nick about um getting to reach

people from the different different walks of life you know seeing different people in the different

areas of the jungle community you know people are using it in their work people are working on the

framework themselves you know everybody in between i think that keeps it fresh and worth doing for us

but yeah i couldn't it's the summer holiday for us it's the big the break at christmas it's the

only doing it once every fortnight that makes it sustainable i think um yeah i think that's a really

good point that's something i didn't do but i've noticed other podcasts uh not companies but like

every guy like you do have like quote unquote seasons right there's a there's like a period

where you take x amount off yeah no and i think it's helpful that i mean maybe if we had advertisers

we feel different because it'd be more of a monetary pressure you know where you know if you

have do it once a week then you're like oh i could go twice a week and make twice the money and

and then then there's the algorithms but for us it's just for fun i mean i think it's a little

bit of marketing but that's not the primary goal so i think if anything we've leaned into that the

last couple years carlton right i mean we want to take time off take time off like it just helps the

burden right because there is this burden when you're putting out content regularly and you feel

like you need to and i think that's sort of like the burnout cycle same thing with work right like

just relentless inbound and you never get a moment to feel like you're in control even if

the inbound doesn't stop and i guess i just follow up with that one is that you've got a schedule

you've got a month you plan your week and you've got all these things on your job list and when

there's something which like takes up oh that's 10 20 percent of the time gone ah and then you

know this is other two or three things on the list and all of a sudden it's like oh i'm actually

under pressure because if you can just sort of pause one of those things all of a sudden there's

so much more space in your life and it's like oh i can breathe i can do i can you know i've got time

to being able to drop the podcast for the summer that's just like okay yeah and we'll join you

again in the autumn and maybe nick maybe you can give carlton tips because it's only been

four or five days since he he stepped down as a django fellow which he'd been doing for five years

um so yeah i guess you went and got a job so there wasn't really like a lot of downtime but um

i don't know there's there's probably some there's some settling when you take something

you've been doing all the time at least for like for me just on the Django board which is a smaller

time commitment I think it took a good two three months to wrap things up that I needed to do but

also just to be like I don't have to check that email every day like like the brain kind of

settles into oh that's not there it's not just an immediate thing like a vacation or something

was that the case for you at all Nick yeah and it's also funny enough like it's somehow almost

works like the opposite too where it's like wait i have all all this free time now and like

suddenly the more free time i have the more unproductive i am like have either of you guys

noticed that as well because actually yeah yeah yeah yeah but it's this this is my take and i

want to hear carlton's but like i like so what is productivity right i feel like there's a built-up

kind of stress pressure and most of the we feel like productive is when we're like grinding

through podcasts or doing things we know how to do that take time and energy but really it's when

you have a moment to be bored or a moment to reflect or a moment to sit around that you kind

of actually are creative and actually are truly productive and there's these blips but at least

for me it feels uncomfortable to find the space because it's so hard to block off the space but

it's like it's only when i'm like you know like like yesterday i i was i sent carlton a picture

like i got the harry potter video game and like i have no time to play video games i've got kids

and stuff. But still, if I find half an hour, an hour, I'm convinced that's when I'm going to have

an insight because it's like my brain is focused somewhere else. Anyway, so I'm very kind with the

idea that I don't need to be constantly going to be productive. It feels productive, but I feel

like it's actually probably not productive in my line of, in what I do anyways. Sorry, that's a

long tangent. I want to hear what your thoughts are on it. Yeah. Carlton, you want to chime in?

okay so i'm still and carlton influenced me on this right he's the one who's like kids are good

because you're playing with the kids you're thinking about something else like it's all

it all counts no like you've got to distract the left brain right so the right brain can get on

and do its thing otherwise the left brain is just like yeah we're gonna focus on words and things

and logic and space and the right brain is like no i want a bit more freedom to do so put on some

music play with the kids do something different that's important that's where the insight comes

that's why it's in the shower your left brain's like i mean i'm busy washing the right one it's

like haha here's your genius idea for the day like that happens for me personally i'm still going

through this kind of um process of clearing the the covid backlog the the you know we had that

year of lockdown and then we had illnesses and then a massive stress and i got to the point

last year where i literally had to put a pause on almost everything and just take on one thing

at a time get the next janga release out okay that was out get the channels update out okay

do the conference or you know just get through to the end of the year and managed to do all of that

and then just as i was sort of um reaching an even keel my daughter had an accident she was

you know ill that was pretty serious and then my son's now ill and it's like okay right just take

it one step at a time and so to for me it's like okay finishing the fellow role got to the end of

march got you know said i was going to stop at new year three months to wind up and you know

give time for finding a new fellow and all those sorts of things okay fine now breathe what's next

on the list well for me it's button which is my simple deployment story for dango that's been on

the back burner for two years and i just really haven't had any chance to work on it well okay

that's what i'm going to work on now and for me it's like productivity 101 if you've got too much

on your plate too many balls in the air put them down get one ball get rid of that then that's one

ball less get the next ball process that get rid of that one ball less then all of a sudden it's

like oh do you know what actually i've got an empty job list and i know that's really basic

but when you're when you're stressed when you're when it gets too much you've got to take those

kind of emergency steps to just focus on what's important that's my tech that's that's how i've

got through the last two years and that's how i plan to continue yeah that's very insightful and

was there a special like moment in your brain when you knew like i had to make the change to

reduce the list yeah when like yeah i was it was um the start of uh so what is it now it's 2023 now

so start of 2022 i was just going for a walk and i had a um a phone call from the neighbors of my

my parents and my mother had been taken ill and was in hospital and it was like ah and it was like

i've just won too many things and i had to at that point i was like i have to i just i gotta take

remedial measures now it's it's the my life's on fire so okay how do we stop this well okay we

pause we focus put that to the side you know just and it really is productivity 101 you read any

productivity books project project management for dummies it's like well take if you've got too many

projects pick the one that's most valuable do that first and okay fine so at that point i had to deal

with family and then you know they've had the the big janga release i was release manager for and

then you know so on and there was just a list that got that went on and around october time

around jangok on us last year i thought yeah i've cleared the covid backlog it's great i'm you know

on the head and then my daughter had our accident and then life said no you haven't no you haven't

so it carries on and now it's like okay i finished felloing

button and then the summer and then you know we'll see what comes next yeah yeah the idea of just

like identifying maybe not so much burnout but just knowing when you have too much on your plate

yeah i think that's a really important skill that i know you need the time to just introspect on

yourself yeah and it's like yeah it wasn't necessarily burnout but it was like if this

isn't this isn't now sustainable it's burning the fuel too quickly and you've got to if you

can identify that and take measures before burnout then that's that's helpful i think

yeah and i also like what will said before just around like you need that time just to let your

mind wander like for me i still do like walking or jogging time for me is non-optional like at

least an hour and a half a day and two times a day maybe not like three hours total but you know

like 45 minutes per time super important like and i don't know like the shower thought thing is like

the most realist thing ever like almost every programming problem i ever have it's like either

in the shower on a walk or like eight seconds before i fall asleep that's when it gets fixed

yeah yeah no entirely there's nothing like banging away at the debugger and then i can't i'm not

making progress i'm going to go and cook dinner and then halfway through cooking dinner it's like

ah yes of course colon it's also challenging when i think for all of us we've have done and do

consulting too so it's easy to think when you're feeling not bored but you're like oh i'm not quite

sure it's like oh gee i could be doing something that makes money like that sounds good that feels

good to be productive so it's it's even harder when it's like oh like instead of going for a walk

You know, it's like that could be, you know, X amount of dollars and that would feel nice. I don't know why, but like that, you know, it also takes a while to kind of get over that to be like, yes, I do want to do consulting and it's valuable, but also, you know, not just fill the void with paid things, which, you know, sometimes obviously you have to, but it sort of gets this feeling of, I think, enough, you know, enough in terms of work, in terms of money and valuing that time of like not doing all these other things.

there's always some like mental visualization that i have in my mind like have you ever been

on a plane i'm probably i'm assuming you guys have been and uh the flight attendant is always

like you know if something goes crazy you have to put your mask on before you can put the mask

on of your children or family members or whoever might need it because without you being okay like

they can't be okay so like that analogy in my mind i always think about that in terms of myself like

you know like trading time for money as doing consulting work or whatever it's like wait you

gotta step back and like make sure you're okay before you can do the other stuff yeah no entirely

absolutely 100 and that applies to everything in life like parenting like you know if you if you're

not emotionally well in yourself you can't help your children to be emotionally balanced it's

well you can you can justify it you can say now they're seeing that even parents get stressed

but yes that's that's the exercise i do i go through well you're seeing daddy's not perfect

it's how you handle being not perfect you're welcome yeah well not that there's any worry

about that but but you know it's it can lead a conversation of like you know uh you know i'm

sorry i raised my voice at that time but like you know parents have feelings too and we get

frustrated and you get frustrated and you know yeah da da da da hey um so angle we should cut

you're headed off to florence oh i was gonna say we should cut back to nick nick here because so

So Nick, you were saying you were doing lots of work, the podcast, you dropped the podcast.

So how is it you came to seek full-time employment or seek a gig or seek a job instead of that?

Yep.

So that one was kind of interesting.

So prior to the full-time gig, like even when I was doing the courses, podcasts, et cetera,

no, I was still spending a majority of my time doing contract work.

And there was a company where, I don't know, the last, like since the end of 2018, I was

doing contract work for them.

Like I started off helping them get their apps running in Docker on AWS.

And like, you know, I had consistent work with them, maybe sometimes five to 20 hours a week.

And I just continuously did that with them.

And eventually, you know, they were asking if I can join full time.

And I said, no, thank you.

And then they asked again.

And I said, no, thank you.

And then they asked again.

And then like, you know, nine months later, I decided to join them full time.

Okay.

And so tell us about your role.

What are they?

You're still there. You're doing, I think you said before, focusing on deployments stuff, right?

Yeah. So I've been there now for about 18 months, a year and a half. And my role is kind of

interesting. It's sort of kind of all over the place-ish, but it is focused on just, I guess,

deployments is the core critical component of it. So I'm dealing with Docker and Kubernetes and just

AWS and Terraform, Ansible, a lot of shell scripting, basically developer tooling. So

like trying to help build tools to make the developers more productive.

I'm just going over like CI CD processes or generally like dealing with releases.

Like how can we make that more efficient?

Even if that spans beyond just like writing code, you know, it's just

like, how do we take an idea from like concept to rolling it out to production?

Yeah.

It's kind of all over the place, but it's nice because I feel like I

have basically almost full autonomy.

So, you know, I still report to somebody.

Uh, the person that I report to is the person I worked with directly when I

was doing contract work so it was a really nice fit there um but yeah we just like bounce ideas

off each other every week and just you know work on doing things uh that take priority and i guess

priority is an interesting word because yeah it's like you can't there's so many good things to do

like how do you pick one yeah okay so you the list of tools you ran through there was basically like

everything in the sort of devox candy store like you know ansible terraform AWS docker gubernator

like what's your favorite what are your favorite bits of the stack and you know what's your what

lights you up about all of that man that's a that's a fun question so for the longest time

i i avoided kubernetes for for years and and i kind of hopped on board with the meme wagon where

it's oh it's so complex like no one's ever like why would you ever use that thing and the more

that i use it now the more that i actually like it and just for context like the place that i'm

working at we're not at like crazy mega like insane scale where we're spinning up thousands

and containers with like hundreds of developers. No, like the dev team, there's 11 developers,

we've got eight services. And it got to the point where Kubernetes started to make sense for us,

because we were spinning up individual EC2 instances or servers for each service. And

there was a lot of duplication there. So we converged on one cluster. And now, I don't know,

I'm liking Kubernetes actually a lot, especially with another tool called Argo CD. I don't know

if you've heard about this one. But yeah, it follows this philosophy of like GitOps, where

right now like instead of pushing uh code to the cluster with um maybe doing i don't know some well

first of all before we get into great details have you ever worked with kubernetes a bit or no

i've worked locally but i haven't used it as like a tool in production because i haven't been in the

position of deploying the multiple services where you need all those and that's the the bit for me

where i'm like i don't want to deploy it for my i don't want to use the extra complicated tooling

for one service or one service in a worker, you know, it just doesn't make any sense.

Right. So like the 30 second, okay. 30 second elevator pitch on Argo CD is like, you know,

you can kind of have your Kubernetes config files in a get repo somewhere. And like, it will just

check your get repo on a specific branch every three minutes. And it will just converge the

state of what's in that get repo to the actual cluster. So like, I don't need to like push

deployments. It's more like pull based. So we just modify the config files to be like, Hey,

here's the new docker you know tag version for the image it picks it up it rolls it out you know

it handles basically the you know cd part like continuous deployment yeah and it's kind of like

um declarative rather than imperative yeah exactly i feel like i'll just sit back for the next 40

minutes because i mean carlton has been doing with button you know devops stuff and i'm it's not

really my wheelhouse but i mean okay so the the you you you just used the magic word there will

you said devops so i mean devops a thing or a practice or what what's your view on

i mean would you describe yourself as doing devops nick is that i don't know like i don't even know

what my official title is but it doesn't have devops in it but like i feel like to me like

just informally to me devops is it's more of a mindset it's like an orchestration of things

it's not necessarily like what you do you know it's not like it's not comparable to kubernetes

or something it's more just like a workflow of things that you do to make everything better and

not necessarily just like the tech part right like it's not a ci cd system it's like well how do we

have this idea right that can go from development to production and in the most efficient way

possible balancing with developers and like product teams and everything and when i started

there was like this uncrossable divide between the developers and then the sys admins and you'd

kind of sort of as a developer you get your your app ready to go and then you'd sort of have to

throw it across the divide to the sysadmins on the other side and they weren't really that

interested in catching it and if it fell into the chasm well oh well not a problem or if they

dropped it and it smashed oh well not a problem they're just stroking their neck beards and it's

gilfoyle and in it was kind of like that and the thing i sort of like about the devops approach or

the philosophy or whatever is i think is that it's supposed to bring the developers closer to

to actually being able to get their code across that divide if that divide still exists would

does that yeah fully agreed so like specifics about our dev team setup you know we've got

10 or so devs a couple different teams like let's say three devs on each team

and they can take their whole idea from concept to production on their own now i help set up like

a CI CD pipeline for them so they can deploy things. But from their perspective, all they

need to do is, you know, make the pull request like they normally do. It gets peer reviewed by

someone on their team. And then the quote unquote release manager is really just, you know, the

engineering manager has to say, okay, to have the release, but him is just like literally merging

that pull request is the release. And that's it. Like, as soon as that happens, things get kicked

off and get auto-deployed. So they don't need to worry about like, what is Kubernetes or Argo CD

or any of these other tools but and then it's on them to yeah just make sure it's running well so

like i've set up datadog stuff like logging and metrics and they can see the insights on their app

like i help them you know debug and profile things but you know they've got all the tools they need

without necessarily needing to be you know crazy deep in the woods with the the great details okay

that's good so can i ask if so that's quite a big team and i think that's you know as you describe

it's a lovely setup you've got something where the developers are freed to just sort of push to

their code and it's all ready to go almost like a platform as a service but for a smaller team

like at what point because i very much like a small you know one to five where you haven't

really got the specialist ops operation keep it simple you know spin up the single ec2 run it on

there scale that up for a bit i kind of think that that that's that small scale works much better

but what what point can you what point do you think you grow you grow out of that or that

it makes more sense to move to um something like the script the setup you've described

yeah i think it really depends there's like a multiple different components that you can scale

off of when you need to do that like for example number of developers on your team versus also like

number of services you might have there's still technically i guess value in kubernetes a little

bit like even if you had one big monolith or something just because you know it abstracts

away some of the details that are hard to do yourself like just doing rolling updates like

zero downtime deploy like keep this one version running put up the new one and then get rid of

the old one in the load balancer that type of stuff i'm curious carlton did you end up rolling

some of that stuff you're basically on your own yeah well just using systemd is the um bottom line

with a socket agent and then you just um a socket unit and just so that the daemon runs the socket

unit which loads the service and then you just get the next that so the socket unit plate pointing to

a different service file and then um reload the daemon and it will refresh the put to point to

the new service without um without loss of connection because it keeps the socket open

it works very well for you know again a small deploy um how big do you want to push that you

know you're running multiple services on a single instance no because they get in the way of each

other and you you just don't want to do that um and it's what's interesting for me is the point

at which you grow out of that you know that's the bit where i'm you know that's not really where i'm

targeting with button i'm targeting very much the simple setup you know you've got an app you want

to get it online what's the what's the story that saves me having to take a week of learning you

know tools which are perhaps too powerful but i also want to have a story for okay at this point

You need to start considering, you know, EKS or whatever the other options are that are a bit more powerful.

Yeah, no, I really like that approach.

And honestly, for my own stuff, too, like if I were to, you know, put together my own software as a service, you know, like some like real thing that customers will be paying for.

I'm going to be deploying that to one server, probably using Docker Compose, maybe using Carlton service, depending on if, you know, when it's available.

Yeah, no, I mean, go on, carry on.

No, but that was it. Basically, I'm a big fan of using what works right now, reacting to that later if I need to, and then like transitioning to that when I have to, because there's a very good chance maybe I don't have to, because I'm sure as you discovered, right, like you can really put together a serious app, you know, hundreds of thousands of monthly visitors on a $40 a month DigitalOcean server. And guess what? You're good to go.

Yeah. No, I mean, that was, that was exactly what, so I, you know, I've been putting stuff on servers for 20 years since I was at university and I've worked on some quite big things and never have I worked on a thing which actually couldn't just scale, you know, one or two boxes with a little load balancer in front of.

you handle the handling the traffic isn't the question like what's the question i think is

handling the dependencies between the various bits you're deploying or if you know if you've got

an add-on which suddenly needs some old version of python or some you know then that's no use a

container then because what you don't want to do is try and manage these multiple versions of python

on the same box and this one needs that version of this and this one needs that and dependency

hell and all those things.

Yeah.

And if you do need some special use case where everything works fine on one server, but maybe

you have some really heavy Celery background workers running, there's no harm in just putting

that Celery process on its own server, like just a second server, like it's just going

to pull things off a Redis queue and that's it.

Yeah, exactly.

Exactly.

And the motive, what got me started in all this, and what I'm bringing to completion

now was the frustration of seeing um beginners you know they've actually used will's book

you know got their first app online and then getting sucked into a kind of pro level ops

game which was totally inappropriate for them um and that's what i'm trying to avoid but what are

you building what are you deploying so you're deploying these eight services are you building

with django and python or a different stack so there are two python services that are using flask

sorry in advance by the way because that's okay no no no it's compatriots not competitors there

we go yes we're all like on the same team but yeah the other ones are more just really large

php applications that i am not so much involved with in the day-to-day but they are being deployed

are they using laravel or symphony or they are using code igniter okay so because it's been

around for a long time you know we're talking like 12 years of development on the apps okay

fantastic not fantastic no no but ah well there's my view see people apologize for code i've got

this old this view that any running software is just amazing it's like a miracle of you know

a miracle of life and something that's been in production for 12 years that's you know that's

that's a massive achievement and it's never going to be the case that's going to be using all the

latest this or the latest that. It's never going to be perfectly clear, clean code. It's never

going to be, there's going to be horrible bits about it, but you kept it going for 12 years and

you built, you know, code with it. That's an achievement. I think, you know, not you, but the

team and the company. I think that's a, I think, you know, I just don't think we should apologize

for old code. Yeah. And I think that's an, that's an awesome takeaway too, right? Because it's like

your customers don't necessarily care that much about your tech stack. As long as you provide a

valuable service to them that they like using and it runs reasonably fast and like user experience

is good etc etc yeah it all works in the end okay so nick i have a question for you so you're

you're a teacher how do you explain this i'm thinking of this because i have the 4.2 update

to my books about to come out hopefully by the time this podcast comes out and i've been adding

a lot more of the um the the how not just the why that was one of the early criticisms of my books

I sort of showed how to do things, but I didn't dive into the weeds because I didn't want to

overwhelm people. And I've added a lot more in subsequent additions and visualizations,

but there's this big jump from local to production, right? And how do you, like,

it's hard to explain to someone who's learning code, like, yeah, all three of us could build

Twitter in a weekend, but we couldn't build it at scale. Like, so like, why is it so hard? Like,

so how do you explain to people, like the difference between like a thousand users and

like a million right because that's where you get into load balancers and servers and devops

um but it's hard for people to feel that and because they can't just you know like we can

just build a clone of something and feel it but you can't mimic the the scale and size and even

if you could it's expensive so you wouldn't you kind of have to be thrown into the fire

um i'm curious how you approach that question because i constantly think of how to explain it

in real terms not just abstractly being like yeah like there's two real engineers and there's like

10 DevOps for anything at scale and they do a lot of stuff and it's complicated and you don't

want to deal with that. Use a platform as a service. Like that's kind of my like my glib

answer to beginners. Anyways, so what do you what do you say when someone asks you that as an expert

teacher? Yeah, that's a good question for sure. And, you know, I think Heroku kind of did an OK

job at this one. How long ago? Like, do you remember this 12 factor application? Like it's

a methodology they put together. And what I found, at least like even doing some contract work and

everything is that oftentimes the scaling part, it's not so much the details of the scaling. I

mean, that is a hard thing to cover for sure, but it's like, yeah, just getting your application

ready to scale is a whole completely separate topic. And it's like a precursor to being able

to scale. Like for example, you know, let's say that you have some user authentication and your

session backend is just running in memory, right? Not using Redis or anything like that. And now

it's like, well, now you have to go to two servers, but now you've got two copies of your

application running user hits server a they're logged in user hits server b they're not logged

in because it's in in-process memory uh that's a problem uh other problems are like file uploads

right you upload your avatar but it only goes to one server not the other suddenly someone gets on

server b and avatar is not there anymore so it's like you've got all these dependencies that you

need to like handle or precursors to to scaling out yeah so i think it starts there in my opinion

i'd agree with that when one of the first um gigs i ever had there was uh you know slime was from

somebody there was like the hardest thing you do is move to two servers like from one to two

servers that's the hardest jump and then you know three well you've already done everything you need

to do to get to two so three is not too bad yeah so the takeaway there is like figure out what you

can do to stay with one so you never have to do the hard stuff but right yeah i mean i think it's

so yeah i think many of the um the stack for me the apps you're working with is php i don't know

If you use, is it LaraForge or whatever the hosting thing is there, but you know, that's

a multimillion dollar business and he's written publicly, I think it's on two, three like

servers, the entire thing for like hosting thousands, however many PHP apps, you know,

he just like, it's a good example of like, you don't need to, if you don't need to do

all this stuff, don't do it and try really hard not to do it.

Like seems to be maybe the takeaway for listeners.

Yeah.

I mean, except, yeah, it's a bit like third party, you know, on a local level for someone who's newer, I think it's a little bit like third party packages in that when you're starting out, it's like, oh, great.

It's like superpower.

Just toss them all in and they all do stuff.

And I don't know why, but boom, there's my authentication.

There's this and that.

But then it's the update hell and you don't really understand it.

And it does come back to bite you to the point where, like, now I don't use third-party packages unless I really, really, really need to.

And I kind of know they're really, really good because I'm just like, it's like a parachute, every additional thing, right?

Because the updates is always, it's always the packages.

But actually, that leads into a thing you mentioned before you came on air.

You just updated to Django 4.2, even though it came out yesterday.

Yeah, yesterday, Carlton.

Yeah, yeah.

can you how how was that how was that update process then carlton can tell us about all the

blood sweat and tears to um get that release out i know marius was a release manager but

before nick answers about updating his package i'm gonna say

there was no blood sweat and tears at all because i wasn't doing it

marriage well four four one four one then you're walking on bodies

marriage was doing it all by himself and poor fella uh he managed to get it out the door

all totally smoothly so well done if go nick tell us about your starter project

right so i do have a django starter project that is using docker docker compose like it is

optimized for that one server deployment type of thing but also good for dev and yeah so i updated

to django 4.2 like i don't know an hour before this podcast call now and that was a very very

very painless update. So one thing that I do is when I jump between Django versions like 4.1 to

4.2, like minor versions or a major one, what I like to do since I'm, you know, I have a starter

project. I like to generate a new project using 4.1, generate a new project using 4.2, and then

I'll do a directory diff on that to see what changed, like the project generators for creating

a new project or apps or whatever. And in that case, there was like basically no changes at all.

I mean, a lot of it was just updating the 4.1 link to 4.2, like, you know, Django in the settings

file it they give you good links to like here's how you know do database configuration so it was

that there was like one string and one doc string that changed but it was super painless i also

updated uh psycho pg2 to using what is it now psycho pg there's not like a three you know but

it does install version three it is version three it's the new so that's yeah we can talk about that

if you like there's um uh so it's the new back end it's a new version of psycho pg um and it's

got asynchronous drivers and it's quite exciting so it's going to be the future um and there are a

few little niggles like if you you know things with tuples and whatnot that you need to watch

out for a couple of gotchas on on whether it's strictly backward incompatible but it's

you know if you just install the new package Django will just use it and for most

use cases it you know it's totally transparent um but what i think it for me the exciting thing at

least is that um it gives us the opportunity to have the asynchronous client so um 4.2 we've

introduced um support for streaming async streaming responses so you can feed you can return

a streaming response with an async generator and if you're running under ascii it will stream it

out asynchronously without blocking your worker without blocking a thread like it would under

um whiskey and you can generate you know use good for service and events or long polling or the

these kind of long live request examples and so with an asynchronous um postgres connection or

postgres client we could in principle use listen notify to you know do an update have something

trigger in the database which then notifies the client you know some kind of real-time goodness

and it's you know over the next you know year two years or so those patterns will become

codified and blogged about and you know maybe there'll be third-party packages wrapping up

exactly the best patterns for doing that that's an exciting and fertile terrain that we're in now

that's it's like okay these are new um new usage patterns for django that haven't been available

before and you know there's you could have done similar channels or whatever but to have

the asynchronous database driver there as well it's like the full stack it's like okay

there's some opportunities here for things which weren't previously possible so that's what i'm

excited about yeah i like that you use the term like the full stack there because i guess to get

the full advantage of async you do need your database later to have it and your view later

to have it and you know these things need to work together if you want the full experience

and i think there is also there is like um an async test client as well right yeah yeah yeah

so you can i mean the test so there's two bits that like this um the the sync client will do

will test async view so you can have an async def view and it'll you know you can make an http

request to it with the sync client and it will test it will run your async code and return it

and so you don't need to necessarily write a sync test case but say for instance you're writing a

say a middleware an async middleware and you want to test its async behavior sort of outside the

full django stack the full request response cycle well then you would use the async client because

you could write an async def test and you can get the you know you can do all these kind of things

you don't necessarily need to use the async test client for your kind of standard view test you

know did this view return this response it can be an async def view but you can still use the

sync client for perhaps simpler testing so okay so just to rewind back to what it was like yeah

update to 4.2 super easy on my end like the starter project it's not like building out a lot

of business logic so there i didn't have to go back and modify a whole bunch of different queries

just because it's all set up and ready to go like you're you know as the application developer would

be using the starter project to build your own app but carl turner will i'm curious like what

was it have either of you updated like an actual application to 4.2 yet and like what was that

experience like i have to admit i haven't it's only been out since yesterday um but i'm on 4.1

point whatever the the latest is and it will be totally seamless um i think the biggest thing is

the storages change um so storages have become a dictionary now um for you so you can define

multiple storages um and the old settings have been uh deprecated and for the new one but adam

johnson has his django upgrade project which has got an updater for that which you can use so

There's two or three small settings updates like that,

which I'll be running Django update to use.

I'm quite excited about Django update.

I think it'd be really nice if every single release

we can ship a set of, you know, to run this updater

and it will automatically go through your code

and make the necessary changes so that, you know,

you don't have to worry about those.

Nice. Does that, I haven't used that updater yet

or upgrader yet does that run something like like black where it will like go through everything

kind of look at things and either warn it or you know warn you or do it yeah it's based on like um

the same idea as pi upgrade so pi upgrade you run it say upgrade to you know 3.10 syntax and it will

go through and look for all the the cases where you know the new syntax is this and you should

be using that or you know this import moved um and they it's done with the ast module so like

you know how black takes construct your ast and then rewrites it rewrites the code exactly how

it's meant to be well django upgrade does the same thing but looking for you know have you

defined this setting okay though this setting should be rewritten like this um in this case

it's a great it's a really interesting project because um one thing we want to do for say django

5.0 is modernize the request object we want to add so j a request.data um property which would

handle for instance json content um you know how you get form data passed in request.post

well you know if you've got json instead of having to manually pass the body you could just

you could get that pass automatically and then give that pluggable passes maybe but while we're

at it there's a proposal to modernize the request so instead of request.get have with capital letters

screaming from you know and it was basically copied from php back in the old days to have

request.query params which is a more you know pythonic style lowercase um snake case um in a

bit more modern and the worry with doing that has always been that we've got so many deployments

that people are like please don't break our code please don't break our code but if we can have

a project like django update that will automatic that's a scriptable to automatically rewrite your

code it makes that transition um less jarring for people and then it makes it more realistic that

we can do big upgrades you know big changes that other have previously perhaps been a bit like

we can't do that because we'll upset too many people or you know it's not worth it yeah yeah

i love that idea will can i can i ask did you run um deprecation warnings when you were um on the new

version like add the flags on run server do you know about do you know about these

so the starter project that i have at least it doesn't use the run server it uses unicorn

both in development and production and i guess just to segue back to what carlton was saying

around like you know what are some things you can do to prepare your app to scale or whatever

i guess this is not necessarily really scaling but i do like to keep my development set up as

close as possible to production within reason like i would always use postgres if i'm using

postgres and prod i'd use it in dev etc but likewise with unicorn i do the same and oh man

i remember it was a django 4.1 i think it was there was some change to how it deals with um

the template loaders so when i was using g unicorn in development like the default loader no longer

does like i don't know enables caching by default so like i was updating my html templates and it

reload my templates in development and i was like what the heck is going on and then someone

replied to a twitter question i had within honestly like 15 minutes of me asking the question

and they're like yeah you need to explicitly you know not use the cache loader in development but

that was super easy to fix like yeah another like random question thing like just knowing the problem

sometimes is super helpful okay so there's a good question nick so you'd like the 12 you mentioned

the 12 factor um uh 12 factor idea where you move methodology yeah methodology thank you where you

move um configuration values into the environment variables is basically the one of the key

approaches but something like um a template config which is quite an elaborate dictionary

how how would you handle that would you handle that because i'd handle that with separate setting

files i you know i'm happy to move things like secret keys out of setting files so i don't

commit them to git but i still have you know here's my dev settings here's my production

settings here's my thing because for instance if i've got a different a templates config that's

a whole dictionary or databases config that's a whole dictionary i don't want to be mapping those

for environment variables i find that quite tricky i'm wondering how you how you'd handle

that exact case of um needing to change the caching behavior for the templates config

in development versus okay doing this from memory because it was like months ago yeah sure so in

this settings file for django there is a templates dictionary or maybe it's an array of of dictionaries

and it's got things like where you configure the back end the record directories options things

like that and what i ended up doing where there was i defined a new variable called default loaders

and this included what did it include the file system loader app directories loader and then i

made another variable called cache loaders and that one would take the default loaders and also

append to that list the cache loader and then inside the dictionary the templates dictionary

you've got this loaders property and there i just dropped in a one line if condition that said if

debug use the uh default loaders else use the cache loaders so there was no new environment

variables that had to even be created but if debug is enabled then you get the good experience in dev

and if not then you get the cached one in prod or any non-development environment right so you have

a single you still keep a single settings file but you've got this kind of multiple you've got

the various options defined in the one file then you branch right which was just two separate like

local uh variables default loaders and cache loaders and that was it and then it was like a

one-liner if condition in the actual template dictionary list whatever good that's all good

that's exactly makes so that's a lot of details to like narrate over audio but like if you drop

it into the show notes i have a link to the commit that did that oh good yeah we'll do that

on your starter project yeah yep okay all right i'll put that in there i'll find it yeah well

labeled it's not gonna be like update update update now everyone's gonna be looking at your

commits um so i find that if you're just i guess using run server with the flags uh i i feel like

most people have no idea that the deprecation flags are there and there's all this work that

people put in so for example like with forms um there's changes and in 5.0 they're going to be

made permanent and you would see that if you ran you ran with the the flags but you otherwise

wouldn't and you know it's a bit of like okay it's in the release notes people talk about it but

you know in the real world people like don't know right like until someone tells you um so i guess

did you see anything on forums are you aware i mean you don't need to be because it's not a it's

a 5-0 thing but like there's some changes to how forums are processed in django coming i don't mean

to put you on the spot but i'm just i'm just wondering if so doing the upgrade process you

probably wouldn't see it unless you'd like deeply read the release notes and decide to act on it and

had run it with flags um but as someone who uses django but like is a jobbing developer lots of

other things like it probably didn't come up for you right because it's not it's not going to break

things yet right yeah i'll be complete last i didn't even know django 5 has been started to

be created but like generally speaking yeah that type of thing i don't think i would have caught

that one i mean i go through the changelog specifically like the release notes and look

at everything and i know that you guys do a great job updating those things but i wonder

what let me ask this has there ever been a case where you release a new version of django like

a big minor or major update and something didn't make its way into the release notes and like

someone found it out after the fact and had to open up like a pr yeah yeah i mean that happens

quite regularly is that not major things but like you know there'll be like a consequence of a

change which is kind of backwardly incompatible in a weird way and it's like okay actually we're

not going to revert the change i mean occasionally it's been like no actually this is a this is this

is something that we actually have to revert and that's more happens in the pre-release phase way

and this is why we have the long pre-release phases for people to test the pre-release versions

i can't remember the particular example off the top of my head but i remember one a few

releases ago which it was quite moderate change and it went through and it was like no actually

the release candidate face we have to revert this because it's too disruptive to the ecosystem and

you know so we roll that back but quite often they'll be like look let's add a release note

clarifying exactly you know if you're in this circumstance what the change in behavior is or

you know that that happens quite a lot um fortunately we have a you know an active

community to help join the pre-release phase and in those three months i think in order to

catch bugs catch regressions um you know catch visual the things in the admin whenever we make

change in the admin is always visual regressions because you know css being what it is and we're

not you know we're not front-end developers by sort of calling um but you know they'll get spotted

they'll get fixed and there are you know normally we'll be able to do something i mean there's a

good example came up this release cycle of um module loading so the the manner the cached

manifest storage which takes your your js files and your css files and it creates a manifest of

them and get like gives you a like a long hash file name so that you can put far far future

expires headers on and when you update them the hash changes and you don't have to clear your

caches and people get the latest javascript or latest css but they get it from their browser

cache where possible turns out this doesn't there was a fix to to make this work with module imports

you know latest javascript syntax but it only captured some cases and there were some weird

regressions and we spent quite a lot of time during the pre-release phase trying to get that

as good as we can and in the end there's a warning in the in the notes saying look this may not work

for all cases and you may have to manually get rid of import statements in comments like they're

they're commented they're not real but they they've got the same syntax as import statements

um and these come up in source maps and things like that but to work through all of that and

get that working properly was you know and what's the best option are we going to have to revert

this well this is you know it's a good feature we want it ah there's quite a lot of work that

goes into getting it just so yeah i think there's uh a cool takeaway from that too is just that

what is that one quote from a famous like computer science book or something like with enough eyes

or with enough eyeballs all bugs are shallow so it's like yeah no matter how much like

predetermining you think you can do to prepare something as soon as it goes out there in the

wild someone's going to find something oh yeah absolutely and so like quite often we'll be there

we're looking at pi it's you know we think it's okay well we just sort of have to merge it because

we either have to merge it or not merge it it's okay let's merge it and we know that we've got

the testing coming up and people people will find the the problems but will you know earlier you

mentioned about those deprecation warnings with the run server i feel like i'm missing out a lot

like if i'm using g-unicorn in development is there any way that i can get like a g-unicorn

hook to get that no it's not g-unicorn it's python so you run python with the dub with the w flag the

capital w flag which is for warnings and then you run it with with all warnings and then you get

um deprecation warnings which are noisy by default but also pending deprecation warning so the

the ones that will be removed to out you'll get a you'll get those show up in your console or in

your logs and then you can you can fix it okay well yeah i should do a blog post on this because

i've i like i was using django for years before i even knew about these and i feel like nobody

knows about them but there's all this work that's being done to say you know we don't we're going

to remove something it's two versions out and you know in some ways it's like the first place you

should look if you're updating and just okay everything works i'm going to move on with my

life um i should yeah that'd be good yeah i'll do that i'll do a little post because you know

adam's tool django upgrade like there's a couple things that people should know about if they don't

just to when when you update your code um i think how to do it as well for a like yeah yeah sorry

thank you for saying that if you're looking for ways to contribute i think it's a a great way so

when the new version of django comes out run your your package with um you know python warnings all

and see what errors you get from your third-party package so there'll be one from your django

compressor or one from all or the one from django filter or one from you know whatever package you're

using and you'll be like oh there's the with django 4.1 this use this raises that and that's

an opportunity to contribute to those packages because the maintainer will be grateful to take

the pr fixing that warning because they know they're going to have to do it before the final

release and you know it's a good way of getting in and finding something that's concrete and

probably quite small to work on yeah it's great advice and also is this one of those cases too

where like if you have really good test coverage in your app like as soon as you run your test

suite what these warnings enabled you should see them right then and there right yeah yeah and it

is like you know you can set them to to error you can have warnings as error and then the test will

fail but you know even if you just have them output it's to you know stand it out as long as

you're not outputting lots and lots of text so that they get lost. You see them very quickly.

Yeah. It's a great like dry run of just what you need to do before you actually do the update.

And funny enough, like, you know, if DevOps stuff is on topic, maybe for this call, like,

you know, this happens a lot. Like if you're adding a firewall in front of your service,

you know, example.com or something, you may want to enable your custom rules in count mode instead

of actually blocking. So you can see in the logs, like, Hey, did this rule work the way I wanted it

to? And then you can like change it to block later, you know? So you kind of get the insight

of what's going to happen before making a dangerous change.

Yeah, yeah, yeah. Put your ACL rule to block

this IP and it turns out you get no more traffic

ever.

Well, so, we'll put a link,

but it turns out, you know, the

Django upgrade version, which is

buried in the docs, does have, boom,

resolving deprecation warnings.

But again, it's priorities, right?

Now that Carlton and I are on the sidelines

with Django, we can both

make some of these things happen that we talk about.

Like, let's make the

docs. You know, let's have someone come in with a clean slate and organize things because they are

a bit of a mess because nobody's really done that over the years. I mean, everything, literally

everything you need to know is in there. I mean, and it has got how to upgrade and how to run with

warnings and, but it takes a while to find all of that, right? I did want to, since we're talking

about deployment, to give a shout out to this project, Django Simple Deploy, which you may not

have seen Nick, but Eric Mathis has been working on this. He gave a talk at DjangoCon on this.

this is a really exciting, like in terms of, I think of like, what does Django need?

Like big picture. I mean, it needs, so async, which is happening, probably needs a way to

bring serialization, um, instead of using Django REST framework at some point, some version of

that needs to come into Django itself and then a better upgrade story. To me, those are kind of

the big three. And so Eric's been working a lot on this. He's, he's the author of Python Crash

Course. Uh, and it currently works with Heroku, Platformer and Fly, but it's exciting. I hope it

its legs in terms of being an option that's a platform agnostic that kind of tees up a standard

vanilla application that makes it deployment worthy so that's just something to mention

regularly to people that it's kind of a cool project i hope he i hope he continues with it

and gets get some help but it's kind of exciting there's two things about simple deploy that i i

think i think one is um it should be used for the django girls tutorial i think because it gives

like they've been using the python anywhere um setup which is great but it it's it's kind of

very python anywhere specific whereas if they had simple deploy then it would be you know actually

we're going to use fly today or we're going to use platform.shel today or we're going to use

you know another um back end for it but it it does this thing that nick talks about where you can

you've got your project then you can run simple deploy and then you've got a diff to your to your

project that you can look at and see oh these are the changes it had to make to deploy for fly or

deploy the platform.share or whatever so i think that's i think it's super i'm really excited by

that project yeah were you gonna say something nick no it's okay i was gonna say i have not

heard about that project yet but i am going to check it out after this after this chat yeah and

his talk did a good job um uh from the most recent most recent django con us um it's it's sort of

strange times with platforms as a service. And again, the reason why my books have been delayed

and being updated is moving off of Heroku because they've had various problems. But it kind of makes

me really appreciate what Heroku has done. And it still does. It's still there. It's paid. But

Heroku is pretty stable, maybe neglected in a couple areas. But it's kind of amazing all the

stuff they've done and still do. And then you see there's real growing pains with all these next

generation platforms of the service. So specifically Fly, I wrote the Django docs for them. I'm using

them in my book. They're updating twice a week, their command line tool. And there's all these

little subtle things that keep changing. All these platforms are having growing pains. So

they're not quite Heroku. I mean, they haven't been killing your database and being completely

off but i i kind of wish i could fast forward to two years from now where you know one or two

have won out and they've figured out a lot of these you know jango specific issues that they're

all kind of having because there's all these cobwebs and stuff under the covers um you know

as they're finding so it's a little you know as a book writer it's a little frustrating because i

have to update things all the time but i think it's overall good but it's like oh man heroku

like why couldn't you just why couldn't you just stay heroku i don't want to write about

deployment i want to write about django like now i have to yeah right why change okay but i think i

even said something to carlton about this and he was like you're turning into a conservative

i was like there you go there you go but why not use simple deploying the book will

and then punt the question to that i might well for future updates yeah um i just have been focused

on doing it raw per se but um i'd love i'd love to off to put it to something else i mean the thing

with the book is I've constantly removed third-party packages over the years. Like I've

had stuff on Stripe and I've, I had a bunch of third-party packages and now I'm really, really,

really reticent to add any, cause I've just been caught by changes with them. And then people

saying, oh, this thing is broken. And you know, it's, it's like hard enough to make Django work,

but it's all the other stuff. It's always the deployment and third-party package things that,

you know, make the book not work. So like to the point where in the book, what am I using now

for the beginner's book i'm only using django all off crispy forms it's like one or two other ones

but i'm like really pulled back on what i use just because i don't it's yeah the dependencies

dependencies are what gets you um so what do you what do you do on the front end stuff like

bootstrap or tailwind or do you use es build or webpack or nothing uh yeah yeah so i'm still on

bootstrap just because i i would use to i would use tailwind i will use tailwind that's all um

but it looks fine you know i mean and i do um i have to go through bootstrap every time because

every year or so there's a new thing and something breaks but i'm still using bootstrap i mean

ultimately it's not a book on layout but yeah i would i would use tailwind and um and the

professionals book too that's the one that's sort of tricky for me because that's when i feel like

i would optimize it and do kind of all these things but i have to kind of take it to a point

where it's maintainable and kind of universal rather than getting into the specifics of fully

you know i i have stuff on caching i don't think i cover template caching just because it would be

a thousand page book and i already can barely update them but um i don't maybe maybe i can

have specific courses on these things because i do think there's a need for it it's just very hard

to stay up to date on all of it i mean even for me just on updating my other question was people

do you think it would make sense to make the professionals book say five four point x five

point x um because i understand for the beginners book you want it to be you know the the version

because it matters what's in the shell and that things have changed slightly but the professional

stuff is at a slightly higher level and django doesn't change very quickly what do you think

yeah i'm gonna have to so i don't go nuts um the problem and nick you can relate to this the problem

is that i pin all the versions everything works like it works it works i test it i test it but

then people just, you know, install the latest version of Django and say, hey, all these things

are broken. Like, I don't, you know, they're just going to do what they're going to do, even though

I have a whole thing on how you do it. And I don't blame them for it, you know, like, fine. So

I'm going to need to try to do something like that with the other two books, because they're

a lot harder to maintain. And yeah, I've still resisted doing the .x thing on it, even though

in practice, like I missed the 401 update. So yeah, there's a main, there's a maintenance thing.

I think probably the biggest thing is, you know, shake my head. I think the biggest thing is maybe

not making the, both those books, um, not making a professional's book, one big project, because

I've used this analogy. It's just like a Django puzzle and just one thing breaks and I have to

redo everything. And it's, it's hard to maintain. I would rather have it be concise areas, a little

bit more like, um, two scoops of Django, except that's very abstract. They don't actually show

you how to code things so but like you know kind of like here's caching and let me go into all the

things like that would make it a little more maintainable for me um i don't know nick you've

had this problem too right because you have you have video too you have full courses and video

like the maintenance thing is is tricky to figure out yeah i like how you use the word had as if i

don't still have this problem like i still have this problem how do you keep yeah like you i pin

i do pin everything to their exact like patch release and then yeah at the end of the course

I have incremental updates to be like, Oh, we're going to update from this to that. Here's how you

would do it. But then it gets to the point where like, you have so many updates at the end where

it's like, you just got to rerecord everything from scratch because so much has changed over

the last like two years or three years or whatever it happens to be. But I do like what Carlton

mentioned too, like, you know, just having like the X variant, like instead of maybe doing those

incremental updates live in the book, like literally a chapter for each individual one,

maybe you can like bring it up to more of a higher level to be like, you know, here's what I would do

when it comes to updating to a new version of Django.

Like here's a checklist of stuff that I would tackle

where you're not going into every specific step,

but like you more generalize it.

That would probably be a pretty good conclusion

before the conclusion chapter on updating.

Yeah, I'm gonna, I mean, I'm a broken record on what I,

I thought for 401s, I would have this

and maybe for 50, I'll have this.

But yeah, I don't, Django, Django isn't the problem.

Django is not what changes.

It's deployment or third-party things,

but, um, Oh yeah, for sure. Especially like when was it like two years ago, whenever like the M1

Mac started to come out, there were a lot of packages that just didn't support that. And

then it's like, I try to do the thing that doesn't work. Like what's wrong? Like it's broken. You

know, like these are the types of bug reports that you get when people take your courses or

go through books. Yeah. I mean, I need to check if it's still there. I have a couple of places

where I'm like, if you're on an Apple thing with the M1, then you need to do this. And if you're

not, you need to use that. And again, it's just like everything again, Carlton's been a fellow

for five years so this is all just like ripples on the oceans of stuff he deals with but it's just

like these little things it's like ah dealt i just want to focus on the big dealt with yeah past

tense i'm retired yeah well yeah well so so nick we're we're kind of at time i always we recently

we've been uh ending with what would you like to see if you could wave a wand changed in django

and i kind of gave you my top three so i hope that doesn't prejudice you but you know as someone who

uses Django, but it's not your main thing and has experience with other web frameworks. Is there

some gaping holes that, you know, other frameworks and languages do well that Django could improve?

Yeah, that's a really good question. And like, I do like your idea of just generally, I mean,

this wasn't like your takeaway thing, but like just the idea of minimizing dependencies is kind

of nice. But I guess like what that really means is like more batteries included potentially with

Strango. And I know it's already batteries included, but like there are at least like I

have worked with Rails before too. And, you know, I don't know a lot about Laravel, but like I sort

of just briefly glimpsed what's going on in all these communities just for the sake of curiosity.

And like, no, they've got this like built-in functionality to deal with like notifications,

you know, like do I want to send an email out or an SNS message or maybe over a WebSocket

connection so the user can get a little, you know, a red dot next to their bell or something like

that um i feel like other opinionated frameworks have solutions for that one i may be speaking

dumbly here because maybe django does have a solution for that i just don't know but is it

more like third party or kind of just like not quite yeah i mean mail doing it like called up

mail is could we just remove that and then there must i'm sure there's a package out there that

handles i know there's packages i think any mail any mail i think any mail is the there are third

But party packages, which just do it much better, and they plug into, you know, SendGrid and Simple Email Service and all these ones that you really want to be using.

Oh, my God, SendGrid.

This is another dependency hell.

Because I haven't been able to remove it from the books, even though I'd want to.

Like, they're constantly changing everything, and then Twilio bought them, and they're changing their auth.

You know, so I have a chapter on email, and, like, three-quarters of it is, like, navigating SendGrid.

Yeah.

Okay.

I like your answer there, Nick, because I did a missive recently about why I'd like

more batteries in Python.

And the answer from the sort of Python team is, oh, it's about maintenance.

And as someone on the Django team, when you say more batteries, I'm like, oh, it's about

maintenance.

So it's kind of like, yeah, I totally feel where you're coming from.

But also it's like, well, what is maintainable?

I think there are so many good packages out there.

And what I think we're missing from the ecosystem still, even with Django packages and the great

work that will and jeff do with the django newsletter is some kind of map of the django

ecosystem where it's still not easy to find the solution for what you want that's already out

there and actually well maintained and it's it's easy to use isn't there's no you know i don't know

what the solution is here i uh it's just well i'm i'm i'm like raising my hand you know metaphorically

So there is the awesome Django repo Jeff and I maintain that's trying to do this.

So it's ostensibly a curated list.

So if you look for email, it'll show you.

We don't say, you know, it's not chat GPT.

We don't say this is the one to use.

That'd be nice.

But there is, you know, somewhere between Django packages, which Jeff maintains now, which is all the packages, the awesome Django repo is designed to be like, you know, we're very strict on what's in there.

But, of course, people don't want to have, like, oh, here's the top three and, like, choose your own adventure.

They want someone who's an expert to just say, use this one right now.

I mean, I do have, yeah.

I mean, it's just, it's hard to be subjective.

It's hard to be curated and subjective.

I mean, it's, like, because you kind of put yourself up for flack, you know.

Instead of saying it depends, it would be nice.

But I agree, like, maybe, like, the common question.

I mean, I have a top 10 Django packages list that's just by downloads, which is imperfect

from PyPI, which kind of gives you a sense.

So it's like Django, Django as framework, Django cores.

It would be, yeah, maybe it's worth sticking your neck out a little bit on that.

I mean, we had a guest, Carlton, I forget who it was, who made the point that, who also

has experience in other frameworks, who made the point that Django has a lot of batteries,

but less magic than Rails.

Because I think I was saying something like, it would be nice if we just had a solution for all these things with these other ones.

And he's like, no, no, no, hold on.

Like Django has a lot built in under the covers.

It just is explicit and it's not as magical because, of course, you know, oh, the email works until it doesn't work.

You know, Django is down the slope a little bit where it's a little more challenging as a beginner.

But then when you want to customize it, which you will, it's easier to do than I'll pick on Rails, you know, one that's a little more magical.

But, you know, like the auth system and stuff has so much built into it in Django, perhaps even more than other frameworks.

But, you know.

Yeah, those are all great points.

Okay, well, we're over time, but we have a great guest that happens.

Do you have your courses?

Do you want to give a plug to your courses or anything before we depart, Nick?

Sure.

Well, I'll do one quick hot pick just on the topic of email with everything.

have either of you quickly heard about a service or tool called a mail catcher it's something you

run locally on your dev box and it sets up a local smtp server and you can configure your

django settings or whatever to just send mail to it and you don't need to contact the third

party service it's not meant for production but it's great for just local testing so if you wanted

a quick thing to do it's got a docker image that you can run um yeah i've been using it now for a

couple of months i like it okay super i'm gonna check that out simplify sending email and development

and test huh yeah it looks like it's it's been out for quite a while too so um yeah yeah that's

one of the yeah it's funny things right it's like it's been around since like 1837 but like i just

learned that that's where that's what you know how the awesome jenga repo started like in the

newsletter we're i'm always like we're never going to fill it with projects and invariably we find

at least two or three valid interesting projects to add every time um but it sort of leads to like

the cruft of you know we sort of maybe i should put a forum question be like what are the common

questions that you have about what third-party package does what and make like a top 10 15 list

and just say here you go like check these out because i think there are there are some answers

right like with authentication it's all off you know there are some answers and where it's not

there's like maybe two competing ones like there's not that many out there i would say i think it's

i think the list is doable yeah and then of course that'll be out of date in a year or two and people

be like why is it out of date and you'll be like no but it wouldn't be you're welcome the packaging

doesn't change that no i know you know the ones that have django's so mature now that those

packages there are new new new packages that come out all the time but the sort of core ones that

have been around for a decade they they're not going anywhere they'll still be here in another

decade well and i should i should plug i have a django forum post on asking people what are your

top five, 10 packages that you install, which I think was fantastic. There's a lot of responses.

So maybe it's worthy of just, you know, linking, you know, just, this is the problem, Nick, right?

Like you have the content, it's more or less up to date, but like, you're still doing stuff and

people's questions are the same, but your mental space has moved on. And you're like, do I just

repeat myself all the time? Like on the video and then on the podcast and then the book and then in

person. And yes, you do, right? Because it's new to them. Just because it's a little rote to you,

um, you know, you just gotta like, it's like a wind me up doll, right? It's like,

it's like academics, Carlton, right? You in another life, like stand up before class and be

like, I'm gonna tell you what I'm gonna tell you. I'm gonna tell you it. And I'll tell you what I

told you. Or you can read my book. I don't care. Or like, um, you know, musicians, the Rolling

Stones, they go to a gig, they play the same tracks. Yeah. 50 years running. They make a

little more quid than we do. Yeah. Well, sure. But they're the Rolling Stones. So fair play.

Uh, did you, so you, um, courses, Nick, do you want to just quickly highlight the courses

that you have that you still maintain as you said?

Sure.

Yep.

There's a dive into Docker, which is dive into docker.com.

That's more like a ground zero getting started with Docker.

Um, I have another, like build a SaaS app with flask.com that's using flask just to

build all sorts of different, you know, SaaS apps that you may want to build that use a

Stripe, et cetera, et cetera.

But yeah, all the details about everything could be on my main site, which is nickgenitakis.com.

now n-i-c-k-j-a-n-e-t-a-k-i-s.com perfect not an easy one seems like you've had to spell spell it

before in your life yeah a few times super nice great well nick thank you for coming on again

it's always great to to catch up i really enjoyed it thank you um yeah thanks a lot guys this was

really fun hopefully uh in two years or less uh maybe i'll come on again super you're always

welcome sounds good well we are at jango chat.com and we'll see everyone next time bye-bye