Transcript: Django for Professionals - Book Release

Hi and welcome to another episode of Django Chat. I'm Carlton Gibson. I'm joined as ever

by Will Vincent. Hi Will. Hi Carlton. Hello. How are you doing? I'm good. So today's special

episode week for me, I just released my new book, Django for Professionals, which I've

been working on for over a year. And so I thought in this episode, we're going to talk

about what makes a website production ready in Django and what's that leap from, you know,

the defaults you have when you spin up Django with SQLite

and all these other nice things to, like, a real website

you would deploy to thousands or millions of people.

Because this is the step you're covering in the book, right?

Your first two books, Django for Beginners, Django for APIs.

Yeah, so it's sort of like beginner, intermediate, advanced.

This is, like, modern, up-to-date, very cutting-edge techniques

that Django developers are using on the biggest sites in the world

and sharing it with everyone.

That sounds very exciting.

Yeah, I mean, it's the book I would...

All three books I wish existed when I was learning Django.

And I especially wish this book existed because having done this for several years now and

talking to lots of developers, there's just a huge gap between, as I said, you know, spinning

up a simple blog and something that you would do in a professional setting.

And there's just no good resources out there.

And having spent a year banging my head on this, I kind of understand why that's a challenge.

But we can talk through, you know, what those things are that make something production

ready and kind of where, I mean, because you can go up to certain things and say, okay,

this everyone agrees that these are steps you should take and then it goes into the realm of

purely subjective and hyper complex and so in the book i go right up to that point and then i discuss

options but i don't you know there are some things that are sort of philosophical debates around

web design in general and you know django itself can't solve those right and different deployment

plans you might take one you might take another it's not necessarily right it's right for you

in the book we deploy with containers which is very new and sexy uh in part because i wanted

to show it in part because it's easier but also i talk a lot about deployment but it's not a book

on deployment i mean you could have you could have a 500 page book on just you know deployment for

one platform provider let alone the dozens that are out there so i had to draw the line in some

places you've got the amazon docs you've got the microsoft azure docs it's like you know they're

big um anyway well yeah and and one of the one of the things i mean so in the book we you build

you use docker you build an online bookstore with payments and a whole bunch of other goodies we'll

we'll go through but we deploy with heroku partly because i think it's one of the easiest ones out

there but even heroku i mean it took me quite a while to sort out the docs on containers we use

stripe we use sendgrid and you know these third-party platforms it's hard to figure out

how to use them i don't quite understand why they can't have a basic guide for all the you know five

six major web frameworks out there but for whatever reasons they can't but is that because they're

pushing forward and like so the docker deployments are some uh somewhat new and so they just haven't

had the time to backfill the documentation i don't i'm not sure i mean so let me let me pick

on stripes light because i love stripe as a company i think it's the best payment processor

out there but so stripe is rolling out a brand new um so we use checkout in the book they're

rolling out a brand new api which is not fully documented yet and i know this because um i have

some friends who work on checkout there who i complain to saying hey i'm having trouble with

this. And I've written official Stripe tutorials for Meteor and for other platforms. So I mean,

I know how Stripe works. And I'm struggling with this. And I keep saying, like, you should just

have a basic guide that's up to date, pick one engineer, like, you know, one hour a week,

and just go Rails, Django, Express, I don't know, PHP flavor. And even if it's and just show how to

do a basic implementation. And I think it's a combination of Yeah, they're pushing forward,

constantly changing things i think they feel if they do an official guide there's just too many

layers of i think bureaucracy honestly um but is it i don't know but it's an opportunity for me as

a teacher to to wade through it but it is one of the challenges of this book is that a modern

django stack has a lot more than django in it and so i found myself repeatedly fighting with non

django things um docker would be an example and i want to use it and show how to do it but it's

not a book on these other things. So I think when people read the book, it will probably seem like,

well, what's the big deal with Docker? Because I, for example, like or Stripe, like I make it

as simple as can be and yet accurate. But it took me a ton of work to figure out how to do that

because these are kind of untested things in a way. I mean, Stripe is literally changing its API.

I mean, Docker, there's so many different ways that experts do it. So ultimately, I had to pick

one and then really understand how it all fits together to try to make it simple because it's

not a book on docker it's a book on django and but docker is always constantly evolving still

it's still quite yeah it's a million lines you know so i learned it and then a year later i come

back and it's like all the all the the the command invocations i learned for mounting volumes they've

all changed now it's not volumes it's mounts it's because you carlton yeah you know that yeah i mean

it's not as bad as like react or something but it's uh yeah it's ever-changing and i mean the

big issue with docker i mean so we use docker in the book because you can have a containers which

I speak about. So you can have an isolated operating environment. And that is good for

your development. That's good if you're working on teams. That's good for pushing to production.

I think this is a new thing that will become more and more common where the containers that you use

locally, you push those up into production. That actually makes it easier to switch platforms if

need be. You don't get locked into a certain platform provider. But it's all new. And

And specifically with Django, there's issues around when you're working with software packages,

if you use pip or pipenv.

So we use pipenv in the book and you have lock files.

And you basically have this tension between, am I working locally or within Docker?

And anyways, in the book, I'm very pleased with how it turned out.

But it was probably a solid four months journey for me to iron out the Docker parts.

But it's important because that's what most developers are using these days.

They are using Docker, but they're doing it in, not everyone is doing it this way.

Many are, but it's not a, there isn't a canonical guide to it.

So I sort of had to wade through that river myself.

You're kind of documenting the landscape beyond the bleeding edge, right?

You're right there.

Well, because if you ever look at, you know,

there are some open source Django projects out there that use Docker

and it's like being dropped into like a hundred year war.

There's just like so much code and so many decisions.

And, you know, I find it overwhelming.

So in this book, we just go step by step and we build up all the things that you need.

and that's a lot of work to do. And I think also a lot of people don't do that because most people

don't have the luxury of starting a big project from scratch. Maybe if you're a consultancy,

even then I think it's rare. So most people aren't, you know, user registration, for example,

like I spend a lot of time on this because I do build a lot of new projects, but most people

don't. You know, you airdrop into a project, you start something and barrel through, and then you

kind of are in the mud and mire. But if you had a clean slate, how would you do that? So that's

example, one of the chapters we talk about using custom user models, but we also talk about abstract

user, abstract base user, customizing all the templates using Django AllAuth. So the first half

of the book is really standard steps that you would use in any new project. So configuring static

files, environment variables, that's basically going to be the same in any project. And then the

second half, we focus on the bookstore. But again, we focus on things that are meant to be universal.

so we talk about permissions we talk about search payments file image uploads security performance

testing and these are all the hard bits right these go beyond the tutorials these go beyond

you got to create these stuff yourself so that's kind of cool yeah and i mean you know we joke that

the tagline for this podcast should be it depends because i think we both find it frustrating when

someone says it depends you know especially engineers and you know so in this book i really

didn't want to just throw my hands up and say it depends i really wanted to take an opinionated

make opinionated choices, but back them up and say, you know, I feel confident saying this is

something that this is a Django best practice. And then if we get to a certain point, say, OK,

now here's where there's a diversity of opinions. Here's what they are. I'm going to give you mine

and show you that. But trying to draw that line of, you know, where where is it more my opinion

versus the community's opinion? Yeah. And showing showing a way of doing it whilst acknowledging

it's not the one true way it's it's perfectly reasonable right right right so yeah so that

was some of the challenges of this book i mean the first couple books the first couple

two books didn't take this long to write but um i'll probably write a blog post on things i've

learned when i've had a couple weeks to settle on this but i think yeah writing an advanced book is

a lot a lot harder because it's you know more figuring out the technology and also just more

and more you're bumping against these um debates within the community on how to do things so it's

not settled i mean one of the the i call it a meme i don't know if it's a meme um but one of

these ideas that comes back again and again is that you need to use um concert you need to be

somewhat conservative in your technology choices because otherwise you're spending too much time

thrashing about what's on you but deployment is still an unsettled project and all the practices

about how you get your static files in the right place and exactly how you serve them um what did

you choose there by the way for deployment yeah no no for static files just what it's in my head

because there are a few different well so we so we we configure it properly which you know creating

the directories. We configure media files. We use white noise. But yeah, that's another example of

we're just jumping all over the place, but that's fine. So let's say you've used Docker,

you set things up, then within Docker, you can create a separate production environment within

Docker, which you need to if you go through Django has this fantastic deployment checklist.

So even if you're using a production database like Postgres, beyond debug, there's a whole

list of things you need to fiddle with to be secure when you go online. I mean, we've talked

about this in some of the other podcasts. We need to harden the admin. Set the security headers,

which we talked about. We talked about on a previous episode. Yep. HTTP strict transport

security, secure cookies, forcing SSL, click jacking. There's a whole list of things that

if you haven't done before, you really should do. But again, there's an 80-20 on everything,

especially with deployments and security. I mean, you can spend all your time on this stuff. And

at some point you have diminishing returns and yet there is like some bare minimum things you

absolutely should do you know allowed hosts for example so so we cover the 80 20 and then i talk

about and here's where you can go nuts on it but uh there's always more to do and so i tried to

pass along at least what i think is good judgment and how you spend your time and how do you

get as what the bare minimum and then be aware of here are the next steps to take there is a

a minimum as well though because um there are automated um bots automated scripts out there

that are checking every every available port on every ip they can find on the internet for known

weaknesses so if you don't get over the baseline it's not a question that of if your application

is hacked it's just when it's hacked so there is a minimum bar you have to get that far and then

you know depending on your threat model you might need to go further right i mean and i would say

you got to turn the bug off. You got to have SSL. You should change your admin URL. That's

the top three, if I would say. But there's a bunch more. And again, Django has this deployment

checklist. But I think the challenge is actually more configuring how you have two different local

environments. So this is where environment variables come in, which we use. Because

before Docker, it was a lot harder to test your production environment, not in production.

like there's jokes about like, yeah, I'll just toss it on production and do it, you know, do it

live. Docker makes that a lot easier where you can actually, within a container, have these production

settings, run these things, check them. You know, you could do it on a staging server. You probably

should as well. But to be able to do it locally, it's just fantastic, actually, that you can use

a Docker. So we go through that in the book. But it's a lot to keep in your head. You know,

you have local databases, production databases, you have local environments, production environments,

And that goes across the board with all these settings.

You know, you want different things locally because you want to be fast

and you don't want to have all this security stuff.

But in production, you do want to switch things around.

I mean, the server, right?

The default Django server, you don't want to deploy with that.

You want to use Unicorn or UWSGI.

Yeah, so what did you choose there?

You've chosen Green Unicorn, Gunnicorn, whichever.

Yeah, am I saying Gunnicorn?

I never know how you say any of these things.

I heard it called Green Unicorn at DjangoCon Europe.

And I was like, Green Unicorn?

And I try to explain this sometimes.

I'll casually mention it to my wife or someone non-technical.

And they're like, what?

I'm like, Django Ponies and G-Unicorn.

And they're like, what are you doing?

So, yeah.

So you choose.

I use G-Unicorn just because.

Well, actually, no, I gave thought to this.

I've used it myself in projects.

And also, it is a little bit simpler to set up.

U-Whiskey has more configuration options.

So I think if you need it, you might want U-Whiskey.

but as a default and certainly as a teaching tool,

G-Unicorn is the approach I chose.

Yeah, and as well, like there's something in,

I heard, so talking about naming,

I heard U-Whiskey, I've always called it U-Whiskey.

I heard someone call it Micro-Whiskey,

the general economy of Europe as well.

Oh, is that a different thing?

Well, it could be like the Greek letter there,

whichever one that is.

I never know these things.

I thought you were the classics major, Carl.

Yeah, no, philosophy.

I sort of do classics on the part-time.

That's my sort of hobby.

I'm learning ancient Greek

so it can be an old man and replay to in the original but um that's a that's for another

podcast um what was i going to say i was going to say something really great there oh yeah so in the

uh you whiskey docs it says this is great if you're building a whole like a hosting platform

or something right it's deliberately more complicated because it's for you know if you

want to be able to provide a hosted environment for people to put their django apps in then you

know you whiskey perfect but if you're deploying your own app you don't need any of that so gone

becomes a lot simpler, as you say. Right. And that, you know, that's just one example of many,

which I think, again, is why, because I sometimes think, why did it take me so long to write this

book? Because I'm a pretty fast writer. I know what I'm doing, largely speaking, with Django.

And I think it was because there's so many decisions just like that. I mean, dozens and

dozens of micro decisions where I have to think about it and then explain it. And I, you know,

I usually I pick one and I explain the differences because I want to be, you know, in some ways I was

trying to cram everything into this book. And it's a long book. I mean, it's almost 400 pages.

but it's still, there's a lot I just took out eventually

because I just couldn't fit it all in

and, you know, I'll get to it in other ways.

I mean, one of the sections I'm most pleased with

actually is the permissions area

because permissions is, I think the ORM and permissions

are, I would say, the two things that advanced developers

or professional developers spend a ton of time on,

but there's not, especially permissions,

there's not a lot of good educational resources,

really any, that I've seen out there.

And yet the ability to create groups, to set permissions on a form or on an action.

So in the book, we set permissions for people who can see all the books and you could change

this to be individual books.

And then when a payment goes through, we put in the view, I was really pleased with how

elegant I made this code.

As part of that action of the payment, you flip the permission on the user.

And so I spent a lot of time trying to figure out how to make that clean.

And I haven't seen it done before.

Yeah, no, I think you're right that there aren't guides.

I mean, people, quite often there are issues on the developer mailing list or on the track about confusions around the permission system.

And, you know, it's quite powerful.

With all this, I think, again, yeah, people get dropped into these code bases.

And you don't have the chance or the opportunity to learn or to build it up.

So we build it up and we talk about when do groups make sense, you know, how you handle permissions, because at a minimum on most sites, you're going to have some at least three levels.

Probably you're going to have your admin, your super users.

You're going to have, you know, in a newspaper example, the editor who can do more things and then maybe a writer.

So at least three permissions.

You know, another example would be like if you had a university, you'd have teachers and students.

They'd have different permissions.

but this crops up right away and is very yeah it's hard to hard to think about and if you

are architecting and building this out and you get it wrong it's a lot more work to backfill it than

to get it right the first time yeah and again like this that's exactly right when you're talking

about anything security related it's it's it's very important to just take the extra time to

measure twice and cut once because you can't afford a mistake you like right but how do you

And how do you learn that you know, this book I think will really help people really you

learn it through pain and making the mistake.

on the job and that's um you know embeds the learning but is not not the best way to do it

um i'm trying no but to do it in a sandbox environment is perfectly good and safe and

it's a good learning experience but to do it on a production environment it's like wow hang on that

was my that was my business yeah and i mean and again this is maybe it's top of mind because i've

gotten a number of emails just this week from people who who read my books and have said hey

i have a new job and i'm in this new code base and ah you know and that's i tell them like that

that's how it is for me too you know i mean it's just that's how it is for anyone and in those

environments you need to well hopefully there's someone there who can tee up some you just how

do you eat an elephant it's like one bite at a time right like find some smaller things like

don't have some big integration you know testing thing that they just toss at you you know find

some small stuff like it's going to take a month at least to wrap your head around it and even then

And, you know, a lot of times on these big sites, you know, there's areas where you just kind of go like, oh, like, I hope I don't have to touch that.

You know, you're not going to you're not going to be responsible for everything.

There's areas like that on every big site.

That's somebody wrote it.

There's some places where I'm like, oh, I don't you know, if you work on it for a year or two, you're like, oh, I just don't want to touch that.

That's why you have confidence.

What else?

Oh, so search.

So this is this is something actually my talk at DjangoCon in September is going to be on search.

So I wanted to include search in the book, but figuring out how to how to do that, because search is infinitely complex.

And most people just jump right to using Elastic or, you know, these solar, these full throttled solutions with no buildup of how do you do it.

And so I'm really pleased with the chapter where we we add search because you want it in almost every site.

We talk about forms, we talk about filtering, and just layering on the complexity, then you can build in Postgres built in support, then you can get to, you know, Elastic, if you need it, you can do hosted solutions. But just doing a step by step solution, because, you know, search to if you're using, you know, let's take Elastic locally, you have to spin up another server or container, like it's very non trivial to get that going. And most people just drop into that they don't have a chance to build it up and think about like, well, how is it

really work and really it's a form and a filter and you're passing the data back and forth and

if you go step by step you know just for me with my understanding i've spent quite a bit of time

with search on various sites but having to go through it to teach it myself really helped me

and i think it'll help others understand what's going on there because it's it gets complicated

fast with like you know weights and you know all these things but fundamentally it's you know user

input and a filter of some kind yeah and like as well that the if you can get away without jumping

all the way to elastic search or whatever it's it's worth doing because there's a maintenance

overhead to that to run an elastic search cluster stably in production is actually difficult that

you know people have a full-time job doing just that teams have full-time jobs doing that yeah

especially on e-commerce sites well and we had uh simon willison was on uh recently and on his

personal site. I mean, he's got a fairly basic implementation and it works just fine. And I

think that's another thing I want to get across is it's okay to have basic implementations if

they work. That's quite elegant. I mean, Jacob Kaplan-Moss gave a talk at PyCon this year on

static files and talking about you don't need to jump right to a CDN right away. You know,

there is value in the basics and getting those right. And yeah, and even with, you know, just

to go back to search, though, I mean, I see I did a bunch of research and it's implemented a lot of

different ways you know you can you can do it as a post request you can do it as a get request

you know you can do it with function-based views that are just 50 lines long you can do it with

a class-based view as i do in the book where it's like three or four lines you just update

and get context data so um i always strive just just in my own code and certainly when i'm teaching

i want to explain it but if there is an elegant accurate way to do something i will go for that

every time yeah and what's nice is if you like the thing with the danger with the class-based

view is you just kind of fill in the the one class attribute that does the magic and you

don't understand exactly what's going on but if you build it up and told the story then that

understanding is great right and that's and that's partly and that is true that is the danger of

class-based views you're just you know turtles stacked on top of themselves and so you if you

just drop in and change one thing it does feel like magic but i do in the especially with the

user registration chapters of the book.

And actually, throughout, I'll say,

if I'm going to do some magic,

I'll say, hey, here's how I figured this out.

So, for example, like updating templates

with, you know, the email that new users get.

You know, I don't just jump to the file.

I say, okay, well, how do I know where this is?

How do I figure it out?

It's like, well, I literally, I copy-paste a part of it

and I go into, you know, the Django source code

and go, well, where is it?

It's like, oh, it's not there.

Oh, because it's part of Django AllAuth

because I'm using Django AllAuth.

yeah right and so now it's in django all off now i can see where it is and now i can see oh there's

a structure and now i can see the other templates and now when i told you how to create the template

directory structure in a certain way because django all off goes uses accounts versus django

uses registration so i actually spend quite a bit of time explaining how you figure this out

because i want to like teach people how to fish not just give it to them because i agree like

that is it doesn't help if i just give it to you with no context right and template loading is

is a moderately complicated topic people get confused about that and then how do i override

a template and how can i extend this template so that i just fill in this one block without having

to you know re-implement the whole thing and like yeah to go through that is actually you know

something that people will learn a lot from i think i think so i hope so it took a lot of time

to write so that's the thing with yeah go on well i was going to say so what about um um performance

are you doing anything there because you go to deployer it's all right you know you're testing

it locally it works to be done anything to when you put it up there you find it your site crashes

why because you've got i know slow queries have you talked about that yeah we do we have a whole

chapter on performance um so there's two ways you can do it so one is you want to you can do things

locally so again with the benefit of docker you can test your production environments locally

so bare minimum things django debug toolbar you need to add i talked through that there's actually

a gotcha with using it in docker that i walked through because you have to find the correct

what is it the correct port there's something a little tricky but I walk you through it but then

yeah so you want to install Django debug toolbar look at your queries and then things like select

related prefetch related these are go-to tools to basically they're complicated topics but basically

if you have a lot of queries often if you can boil it down to one big one that's more performant

but you don't really know until it's a production environment so I talk about things like you will

probably want to implement these. But don't just do it. And don't just do it locally, like put the

site up live, you know, things will appear that need to be addressed. Same with adding indexes

to databases, you may think, oh, I'll just index a whole ton of stuff, you know, the user ID,

but you should hold off and the problems will present themselves. And there is a cost to

indexes, for example. So all these things I, I talked through, you know, compressing your front

and assets caching there's you know django has four different built-in layers per site per view

template and then low-level api so we i talk about how you would do it but then also say

you know don't necessarily just jump into doing it because that's you know premature optimization

is a problem the root of all evil no yeah yeah was it donald newth i think um but yeah because

you're gonna get it wrong you know when you put your site out live don't worry like people are

like what am i gonna work on like things will jump out at you like oh this is on fire that's on fire

that's actually the perfect time to optimize it not just saying oh i'm you know i'm gonna

add redis right off the bat i think you should wait until you need it yeah and also where you

think the performance bottlenecks will be that's not where they'll be they'll be somewhere totally

different and then you'll discover in production where those small number of performance bottlenecks

are you optimize those and all of a sudden your thing is is fast and you haven't actually had to

do too much work right that is another trap is that it's when you wait for the problems to

presents himself and put themselves into a hierarchy,

it's way less time.

But again, how do you know what the problems are?

I mean, you and I have a sense of,

these are the common things,

because we built a bunch of sites,

we're familiar with Django.

haven't done it it's a constant just like oh my god where did that come from so the book sort of

says you know here are the major things here's how you would do it but you know i do give the advice

of wait like that's some pro advice like there wait if you can there are plenty of you know if

you're worried about those things go talk to users don't prematurely optimize your site for a million

users go get a million users and then you can figure it out yeah yeah get 10 and then figure

out yeah but that's yeah that's an engineering trap right it's engineering stuff is fun and

And even on deployment, I talk about how there are deployment engineers for a reason, site

reliability engineers.

In fact, most engineers at a big company are working on deployment performance issues.

And it's really fun to do because it feels like binary.

You can look and see, oh, page load time got better, or our uptime increased.

It feels very satisfying.

But should that time be spent eking out those gains, or should you go talk to users and

make...

I don't know.

Let me pick on Quora.

Maybe I don't have to log in all the time to use it.

Would that be a better thing than, you know, being proud of how fast your site loads?

Probably.

So those are like engineering traps that you get into because you can document and it feels good.

But is that what you should work on?

I mean, generally, you probably want to work on what you don't want to do in a startup setting.

Yeah, I mean, as well, like in a way that it can be a bit like busy work or, you know, it's like, yeah, I feel like I'm doing stuff.

I'm answering emails, but I haven't got anything done at the end of the day.

I spent all day in the inbox.

That's not productivity.

I spent all day improving my deploy, but...

Yeah, you do get something done,

but it's probably not the most important thing.

I mean, that was something, so I started...

Well, it depends on the scale, right?

Depends on who you are.

Depends on the scale.

So I was at Quizlet,

which is now quite a big site very early on,

and I give the founders a lot of credit

that we, about once a week,

several people on the engineering team,

it was a small engineering team,

would go into schools and visit

and just see how it was being used.

And if you think about it, that's a huge cost, right?

Five days a week, that's a tenth of the workday.

And then really the whole rest of the day, we're talking about things that we would learn.

And that was a great way to see how things are actually being used.

You know, things that we didn't think about would come up.

I mean, spending the time with your users is hard to do, but always the best thing to do.

Again, and it doesn't feel as good maybe as these known performance issues that you want to address.

But there you are.

Yeah, I mean, I could go on all day about this.

Let's drop that.

How does that relate to you with being a Django fellow?

Do you see also these sort of 80-20s or these areas where engineers get really excited about working on stuff?

Maybe it's not the most relevant.

Yeah, I mean, the thing that comes up is when people want to propose a feature and they want it to be an exact way so that in their particular code base, they've just got one line of code to write and it all magically does that.

But the cost of that is extra API surface area for the entire user base of Django.

And on balance, it's probably not worth it for the entire user base of Django when what we could see is that this one line for that one person could just be like half a dozen lines overriding one function in a class-based view.

And we'll say, no, look, we're not going to add that extra API service area over the whole API because there's this quick fix available.

And then they get upset about that because they want it to be just so for them.

And you're like, well, you could put that in your own project or you could put that in a third-party app.

and that's right well that's the difficulty is balancing make them feel make them feel your pain

and also convey that you understand their position because everyone is you know everyone views the

world through their own eyes yeah and and so that's the like treading that balance where

django is useful for the majority use case and we include the hard batteries you know the things

that are difficult for a user to implement themselves we will will include but we can't

necessarily include absolutely everything for absolutely every use case because then it becomes

unworkable right it's a similar tension yeah i mean in the in the book too i mean especially

around well there's so many areas where i say you know hey jango's got your back here but let me

explain how they have your back you know security user registration performance i mean there are way

more things built in you don't have to think about versus these toggles that you can customize and

even the ones you can customize i think jango does a fantastic job of sort of being objective

about it you know depending on like caching for example offering okay maybe you hear these

different levels and you know there's always Django always gives you the option to roll up

your sleeves and dive in and get crazy if you want which is fantastic because a bunch of some

frameworks don't you know they're they're really great out of the box but they're hard to customize

Django is a little bit more work but it's eminently customizable across the board

which is its strength yeah okay one thing I like about what you've talked about the way you've

done talked about all the topics around Django that you've experienced in the books it reminds

me of a conversation we had back in episode one or episode two when we were like you know django

is almost a front-end framework and if you look at the whole stack you know it's not front-end

it's not css it's not javascript it's not react it's not whatever but if you look at provisioning

vms or the database servers or docker or any it's kind of a bit front-end and and what it sounds is

like you've placed django inside that wider environment and that kind of sounds really cool

yeah no i've tried to and the thing i like about having these again these three books is i feel

like i've you know it's beginner intermediate advanced and i'm constantly going to be working

on them updating them and both as django evolves and also just it's a chance for me to keep

improving how i explain these topics so um yeah so it's an exciting time and i should mention so

the first so if i want to pick up the book how do i do that yes so you can go to the website

jenga for professionals dot com, which we'll link to in the show notes. And you can read the first

two chapters in the introduction there, which will walk you through Docker and some projects

and talk about what's going to come. It's available as an e-book and it will be on Amazon

print and Kindle by the time this episode comes out. If you have a choice, I would recommend the

e-book because you will get updates. I can't do that on print and Kindle, but if you want a

standalone copy, you should go ahead and get those on Amazon. And if I wanted to get the all the

books, is there a nice little bundle? Yes. So for the ebooks, there are bundles. So if you buy,

so each book is $39. And if you buy two, you get $10 off. If you buy all three, you get $20 off.

There's links on my site, wsvincent.com slash books, which I'll put in there. So yeah, trying

of make it easy for people to understand and get to. And, you know, for me, actually, I've spent

a lot of time, all my time creating, and now I'm switching my brain around to, you know,

the marketing and displaying. I'll probably do a video where I walk through the project

and show, you know, a couple minute video show, hey, here's what we've built. This is actually

something I'd like to add for my first two books is to walk through because the first book goes

through five different projects. And I think people kind of buy it based on trust. I think

like they read other tutorials i have but i can i can and should walk through and show a quick

hey here's what we're going to build kind of video okay even though a lot of it is the plumbing which

is the interesting part and if i wanted to get update on those those kind of contents i should

subscribe to your email or that's right yeah so i have a newsletter we'll link to it where um i do

maybe once a month only important stuff linking to new tutorials um that i've written to podcasts

i see amazing stuff out there so it's very intermittent but yeah i'll link to the newsletter

that's the best way to be updated um there's also an rss feed um through that is available

on the site i'll link to um and it shows up in the django has a community feed right i'm not sure

who's in charge of that but it's on the django community feed yeah so you submit and then we

just verify that it's a valid django topic blog and then we'll it gets added to that feed okay

yeah so yeah so someone submitted me uh which is very kind to them so it's so when i publish things

with the Django tag on my site it pops up yeah so if you go to djangoproject.com and the community

tab you can find the the link to that feed yeah that's that's a really good feed for people

yeah so it's out there um email me feedback uh I'm really proud of it I want to see how people

think but it's been a full year of work and I think it's really going to help people out

well well done and have a little celebration to get it out the door yes yes I will all right

thanks very much that's everything from us this week take care and join us for the regular show

next time. Bye-bye. Okay. Bye.