Transcript: Django Deployments - Eric Matthes

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

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

Hello, Will.

And we're very pleased to welcome back Eric Mathis, who is the author of Python Crash Course,

works a lot with Django Deployment, and we're going to talk all about deployment this episode.

Welcome, Eric.

Thank you for having me.

So deployment, multiple ways we can get into this.

You have recently released an open source package, Django Simple Deploy.

So we want to talk a lot about that.

We want to talk about deployment in general, book-driven development, and just catch up

on, I guess, how you've been too the last two years, I think, since we spoke.

So yeah, it's been a while.

Catch us up on what you've been doing since, because you were teaching, I think, still

teaching full-time when we spoke, and you've stopped doing that.

So you've had time to fill with other things.

Yeah.

I have had my time filled.

Like COVID.

Yes, exactly.

Yeah, to briefly catch up, 2019, I left the classroom because it turns out writing a popular

book and teaching means two jobs.

So I basically worked two jobs for five years and it was getting a little overwhelming.

So I left the classroom in 2019 and then took that fall semester off to just decompress and make a long list of projects I wanted to do, and then 2020 came about.

So I'm here to talk about Django Simple Deploy and deployment in general, and that really is one of these projects that's been kind of lingering in my mind for years, and I'm finally finding time again to dig into these kinds of projects.

Yeah. Well, we've spoken about this in the context of just how do we make it simple for readers of our books? Because you have a great section in your book, and I certainly looked at that when I was doing my books. And we've had back and forth on, is there something we're missing here? Because Heroku is great, but doesn't quite get you where we want to be. So I think we're going to talk about that, right? Like our ideal wish list for deployment.

Right.

And maybe we could tee up, and maybe Carlton, to you, since you're working on...

okay so you mentioned heroku so i kind of i kind of think heroku is awesome if you fit its use case

but the way i kind of came to think of it after the years was a kind of deployment cul-de-sac in

that you drive in it's all very nice and houses are pretty but you get to the end and you realize

that oh actually i've got to drive all the way back out to carry on to the next the next section

there's no through road from that kind of platform so that that's kind of you know my metaphor for

why not the Heroku stories?

How does that sound to you, Eric,

if I just throw it up in the air

and you can smack it over the bleachers?

Oh, I have not heard that metaphor before.

I think it's brilliant.

I like the cul-de-sac, but I have been...

Yeah, no, it's a nice cul-de-sac,

but the second you don't quite fit the use case,

it's like, oh no, I've got to spin up this extra service

and this extra dyno and this extra...

And it becomes anything but simple and quite limiting.

very quickly. Once you reach that point. Right. And so the subject of deployment just

brings us into the weeds right away. I have been curious. I've really enjoyed listening to your

podcast over the years and listening to a podcast for years, you start to get the patterns. And so

I don't know if you guys know this, but I've noticed that whenever the word deployment comes

up, there's audible groans and moans. And I groan and moan in the kitchen and laugh,

and I'm sure it happens all over the place.

So I was going to ask you guys,

what's your thoughts on why?

So deployment is critical for a framework like Django

and any web framework.

So if there's a piece, deployment,

that's involved in almost every project,

why is it that we groan and moan

every time the word comes up?

I'm curious to hear from you guys

and I'll share why I laugh when I'm listening.

Okay, I'll start.

You're making bunny ears at me. I was like, peace sign.

Well, no, I've got two points I'll say, but you go first, Will, and then I'll say mine.

Okay. So I thought a lot about this, both at a company deployment, most of the engineers at a

company at scale are focused on infrastructure, basically. It's not the crud part. It's the

making it scale, making it fast. And then how do you teach that to beginners? I think

One of the hard things for Django is that, you know, Django is not responsible per se for

deployment yet because we use it, we think, oh, it should just have that too. And, you know,

Heroku is really good. It's designed for Rails. So Rails, there's a one-click solution. You know,

there's several steps to make Heroku work for Django. It's not that complicated, but it's

complicated enough that you can mess it up. So I think part of it is that Heroku is not a Django

first solution. It's one click for Rails by design. I think the bigger thing though, is that

local to production is hard and you have really nice guardrails and it's a nice clean garden

doing Django locally. You got SQLite, you don't have to worry about security, everything defaults

to it. But then when it's production, it's a choose your own adventure and you're just waiting

to make a mistake. So there's performance problems, there's security problems. There's also

just lots of different ideas about how you deploy it. Plus production database, right? So how do I

do that? Nowadays, you can do a hosted production database, which really simplifies it. But you

still probably want something working locally. So does that mean Heroku? Does that mean spinning up

your own thing? So I think it's that huge leap from the knowns of Django local dev, which is

really nice and clean, to you ask the experts, they all tell you something different about how

deploy. So to me, that's, I think, the crux of it. So it's partly Django, but I think it's more

the local production thing. And then Heroku, as much as I like it, again, could be more optimized

for Django. But Carlton, you go, you've got... Yeah, well, you hit my, you basically hit my

points. I think that I'd say there's so many options. Like one reason that there isn't a

Django solution is that we can't agree. So quite regularly, it comes up to the Django developers

mailing list um something like oh can we can we um include a solution for m variables reading m

variables into your setting files because that's better than hard coding you know but as soon as

that comes in it's like hang on but you know um m files aren't m bears aren't actually you know

best practice necessarily look at the um log4j thingy bob vulnerability where they were reading

environment variables you know that there are serious objections to using environment variables

at all and so then it you know and it gets into this massive debate and it's like no this isn't

something we can have inside django but look there's django environs that lives as a perfectly

good third-party package go and use that and you know it would be the same for deployment

you know there's there's just no consensus at all about how you should get your web app online and

so much depends it depends there you are we've done it we're seven minutes in um bingo so it's

so much depends on what what your um circumstance is that there is no django battery included this

is the thing that should live in the core framework solution that fits the 85 case um and then the

other bit was so there's just so many moving parts you you know you learn to you go do the django

tutorial you learn to build your web application and then it's like you you go how do i get it

online and you've got literally like another week full time's work just to get it provisioned and

you know, the first time you do it,

you've got to learn about bash,

you've got to learn about envers,

you've got to learn about databases,

you've got to learn about rsync,

you've got to learn about SSH keys,

you've got to learn, you know,

just all of it is, it's just massive.

So there you are.

Too many options, too many options,

too many moving parts.

They're my one and two.

I find too that, because I,

you set it up, your deployments processed pipeline,

and then you don't really look at it again.

So in doing the books, I'm curious if you have this, Eric, I sort of do everything from scratch

and I'm, I forget half the things or something's changed. Whereas in a company setting, if, you

know, if you're a Django expert, you kind of, you have it set up and you're good to go or my

existing projects, you know, I have it configured, but when I have to do it from scratch, it's just

so many steps and things change. So that's challenging. Like I'm still, I can still never

remember all the steps, even for Heroku for a production database, you know, I mean, just

tossing it up i got that memorized but all the little steps even i'm just like you know i have

to refer to my own books as a reference we write books to document their own learning right that's

right to check these are checklists you know like a pilot flying a plane i'm robbing uh daniele

protheter's take here but a pilot um flying a plane uses a checklist why because it's the high

stress thing and you'll forget if you don't have a checklist it's okay to look it up it's okay to

have a checklist that's that's allowed but my before you start eric my dream because you also

asked this in the notes like what would be the ideal i would want something like so there's net

netlify bought this company drop where you can drag and drop a static site just like physically

drag it or push it and they'll just deploy it so it's very opinionated but if there was something

for django where you could just drag and drop it in has a hosted database it has you know some

degree of caching by default and then it's kind of had a list of buttons where you could

up the ante on security and performance which ups the complexity but there was some baseline of like

this won't you know debug is off you know you're not totally bad it's not performant but it's you're

not going to get hacked right away and you could just go from there that would be ideal to me but

i don't think that is a great business case because it's beginners who don't have much money

but i think it's possible to do a drag and drop because carlton i don't think button is not

designed for that you're you're a more advanced case no no so the the button use case is provision

a um setup on ec2 just a basic setup on ec2 with the very with the bits in place pull your project

from github make sure that's and and set up all of that and get that running so it's it's provision

deploy and then backup monitor redeploy that would be the the sort of the picture that you're looking

at that. Okay. Eric, you, you go for half an hour now. All right. Boy, one of the things I was

thinking about anticipating this conversation was what was my first deployment? And it was

probably back in 2010, 2012 ish. I think it was Django one four or one five. And I had a problem

at school where we were keeping track of the learning standards that we were, we were using

for our students. This is a small high school. Um, and I looked at the system we were developing

and we were doing some really innovative work. And I realized that all of our work, all of it

was in word documents. And so we had had a conversation and our staff and had figured out

a way to, to, um, to move forward. And it involves changing the structure of, of what we'd been

building. And I realized we could not do it. We literally could not take that step forward because,

um everything was in static documents um and i realized really quickly um that we needed a

database um and you know there's no real i don't think there's a real generally user-friendly

database like people used to have access and i don't hear much about that anymore

and i realized quickly that if you want a database now a lot of it is um about building a web app

a front end for web app is a can be oftentimes viewed as a front end for a database so i did

some research learned about django built a little project that did exactly what we needed

um how cool it works on my machine all right i can probably get this ready for other people on

my staff to use like oh no oh gosh deployment um and this is before heroku and so my solution was

to configure a laptop to run with the lid closed,

and I got it running on RunServer

and dumped it into a closet,

and we all had access to it.

And that was on the local network, yeah?

It was.

So perfect.

Yeah.

Yeah, very safe.

Yeah, I used RunServer in small production.

So I think of, when I think of this,

specifically for people who are new to Django

or new to deployment.

I think of deployment as a cliff.

And so if you think of people who are just learning Django,

it's a little intimidating for a lot of people to get into

because there's so many moving parts,

but they face that difficulty.

They choose a learning resource,

whether it's a tutorial or a book or whatnot.

They build a project, maybe they modify a little bit

and see like, oh, my idea works.

And it's all working on your local system.

And to really get something out of a web app, you need to share it with other people, for most people.

And so you say, okay, it's going to continue on the same momentum that I've had in building a web app.

And then like Carlton, I think said, or one of you just said, then you realize like, oh, it's another week of learning.

And after that week of learning, I'm still going to have this thing that I worry about falling apart somehow.

And so, um, yeah, what do we do about that cliff? Um, I, I just finished listening to

your conversation with Adam where he talks about, uh, book-driven development.

And, uh, I think that's, it's a good phrase. Um, I certainly have experienced that. And so

a lot of my motivation for thinking about this has come from helping readers of Python Crash

course deploy the learning log project that we build in the book. That's the most fragile part

of the book because I basically walk people through configuring a project for initial

deployment to Heroku. And at that point, my book is really just a recasting of Heroku's

documentation for how to do your initial deployment um and i've been thinking about like okay why have

i been so dissatisfied with that part of the book um and i realized just thinking about this last

night that a lot of what i've written is is teaching people concepts teaching people how to

think about code how to think about solve problem solving problems with code when you get to that

part of the book is really not teaching about concepts it's really a set of instructions do this

then do this then do this then do this and I think as grateful as I am to Hiroku for what they have offered it

think it's, it's absolutely fantastic. If I, if Heroku was available back when I was doing that,

um, education project, I probably would have used it and been very happy with it. Um,

and so Heroku has moved this space forward. Um, but there's still at a space where like

those initial steps could all be automated. Um, so I've been wrestling in my mind for years about

how to automate that for people. It sounds like you should be the Django evangelist for Heroku.

yeah well i think um you know we can kind of build this where all this this new work has come from

about a year ago um i ended up learning about the um heroku build pack a little bit more

and i wrote a custom heroku build pack that lets you set a configuration variable

like automate all and if that variable is set then heroku would generate a proc file for you

would um pull in white noise for static files it would basically inspect your project and do

all of the automatable steps that could be made um as well as you mentioned it's basically an

opinionated uh initial deployment of foroku but that sounds perfect but that didn't feel good

because that didn't feel good because it sorry go ahead so i was gonna say but that sounds great

because 90 of projects are just exactly the same especially for that first deployment

right right um it did not feel good though because it really did feel like doing heroku's work for

them um and dana greenfeld hi danny um pointed that pointed that out when i shared that on

twitter and i appreciate him and i appreciate people like him calling out um when open source

work uh leans too far into the world of doing a company's work for them um i was okay with it

because for me it was an exploration of of what could be done but it did not leave a good feeling

behind for me you've got you've got thoughts on this as well will know like yeah you're triggering

i mean i've tried to i so i've stripped out increasingly uh external things from my books

just because of i felt that that i was doing their work for them and they change constantly

and then people come to me and say, why doesn't this other service work? I've wondered why don't

they invest in someone to do this? Stripe, for example. Stripe's a great company. I had

the official Django Stripe tutorial for a long time and I had a team of, I think it was a half

dozen Stripe employees kind of jumping on my back to update it for this and that. I was calculating,

Okay, six of you, the time it takes, like, that's so much money, like, you just do it. You know, like, why are you outsourcing this? Like, why don't you just take half dozen popular frameworks and do it? And I still don't have a good answer for why they do that. Don't just like dedicate an engineer to, you know, once a month, look at it, other than maybe they feel, I don't know, they don't want ownership over it. I don't know, it's a little mystifying to me.

but I've also just stripped out as much as I can just for that reason that it feels like I'm doing

their work for them. And I don't, you know, presumably they're making enough money. So I

don't know what the issue is. I've asked a lot of developer advocates. I wonder, I think they're

more focused on like new features where sometimes, you know, specific to Django, it's not like the

top framework they're thinking of for whatever reason. So that's just a word jumble. I don't

know. It's a frustration for me. I don't quite understand why a billion plus dollar company

can't devote a little bit of time to just having a tutorial not just docs for the top you know three

or four frameworks that use it well i think um i think i have that answer for heroku or a fair

understanding of that that answer and this is a little plug for going to conferences when it's

appropriate to do so um i've gotten to meet i think all the people who've been responsible for

Django on Heroku over the years.

Kenneth Reitz, back in probably 2013, 2015-ish.

Casey Feist, I think, was for a while.

Ed Morley, I think, is the current Heroku person

responsible for Django.

I haven't met him in person,

but I've had conversations with him online.

All these people are nice.

All these people get the core issue,

but I think they're tasked with so many other things

It's that this never rises to priority.

And so I think it's that growth issue.

So Heroku was founded to make initial deployments easier.

They solved that problem to a large degree.

They got bigger, and then their problems became bigger.

And so once you get to a certain size,

small issues tend to disappear unless somebody is there long enough

to continually say, okay, this has been hanging out for a while.

We need to prioritize that.

So it doesn't excuse it, but I think it does explain it.

And not just Heroku, but a lot of organizations.

It's kind of the point you made, Will, about there not being a business case for this kind of niche because, well, you know, people getting their first Django up online aren't necessarily the biggest spenders.

Yeah, and I think they don't have a way to track it, you know, because you would think that opening the funnel would be a good idea, and I'm sure it is.

But if they can't track it, they can't reward it.

I think also Jacob Kaplan-Moss was at Heroku back in the day.

And I know around tooling, I mean, Kenneth did a lot.

He had, I forget the name of it, he had his Django deployment package, which is still referenced in the docs, though it hasn't been updated in five years.

You know, he really was making some efforts on that front.

But, yeah, it's still referenced, it's dead, and it's still there.

But, yeah, I don't doubt it's what you said.

They're hit with so many other things, and if there isn't a top-level business case for it, it's...

Well, see, Carlton, but I'm going to say one more thing on this.

It's understandable why these kinds of things drop in priority, but it's also a little risky.

Because if the other platform solves this problem, it becomes much easier for everybody else to jump onto.

That's where business starts to...

Disruption, a new upstart comes up from the bottom, makes it simpler.

So it's an understandable business decision, but it's also a risky one.

so okay cool um you you phrased it slightly strangely eric and that you said something

like i found it uncomfortable that i was doing her ruckus work and the way you use the past

tense slightly there it sounds as if you've done something else that moves past that yes

all right yeah so uh ruminating on this over the years um i realized um that what didn't feel good

about that Heroku build pack solution was that it's grounded in the Heroku world. Um, and so I

realized, um, there's multiple ways to modify a project. So the build pack solution was to take

your project and as it heads toward the Heroku platform, um, on Heroku's end, uh, modify the

project for their deployment. And I realized you can modify on your own end. Um, so I came to the

solution of writing a management command that you run this command once and it modifies the project

as needed for the platform and then and then you can push your project pre-configured for that

platform so i turned into a package and you can pip install it basically you can take a simple

project simple django project if it works locally on your system you do three steps pip install

Django simple deploy, add simple deploy to install apps, and then you can run the command

python manage.py simple deploy dash dash automate all, and it pushes your project to Heroku.

And a new browser tab appears and your project is live and deployed.

Fantastic.

What's the database piece?

I mean, I've looked at your project, but to describe to someone, right, because someone's

got SQLite locally. You can't use SQLite in Heroku because it's ephemeral. It'll be nuked

every 24 hours or so. So how do you handle that part? Let's take a step back because

we've been talking about how Heroku is good, but it's not everything. And so one of the things I

like about this project is it's not Heroku specific. The goal is to take a simple Django

product that works in your system and let you deploy it as simply as possible. And right now,

there's three steps, and I don't think you can get any shorter than that. So one of my tests for

is this project worthwhile is, does it serve as a layer between our local projects and any platform?

And so I looked for a second platform to support.

And so I considered a number.

I set it up on Azure because I was looking for a platform

where you can do the entire deployment process through the command line.

Go ahead, Carlton.

Are you using App Service there, which is like the managed?

Okay, so the Azure App Service.

It's like the managed runtime.

Go on, Karen.

Yes.

Okay.

I'm brand new to Azure, so this was my month of having 20 browser tabs open on my screen.

Yeah, okay.

So did you see Carlton's videos with Azure from a couple years ago?

I did not.

They're good.

You should check them out.

But Azure's app service is like their Google App Engine or their Heroku, or it's their sort of managed application environment.

They're equivalent of that.

Right.

So, before we get into details about a specific platform, I want to point out that for Django Simple Deploy, Azure support is experimental right now.

But I wanted a proof of concept before digging into it further that this could work for multiple platforms.

And so, you can also do, you still do pip install, Django Simple Deploy, add Simple Deploy to installed apps.

And then an alternative deployment command is manage.py, simple deploy, I think it's

dash dash platform, Azure, and then automate all.

And your project, it runs, modifies your project, and it pushes to Azure, and a new browser

tab opens, and your project is live in Azure.

And so that's the vision for this project, that if people have a simple project that

works in their system they can deploy it where they want to in three commands and then if you've

got it working on heroku and azure then it would easily work on app engine or i can't remember what

amazon's one is because they have too many services for me to remember the names of all of

the services but you know it would work anywhere right i mean with the right back end well it's

interesting because um one of the things this leads to i think we come back to this maybe near

the end is like, what's our wishlist for existing platforms or new platforms? So somebody out there

like, I'm going to solve this problem and take that business away from those other providers.

Heroku and Azure, you can do this entire process through the command line.

There are some providers where you have to go to their site, click in, do a couple steps through

their GUI, and then go back to your system. Every one of these platforms, you have to go to their

site to make an account but once you have an account to do the deployment some require clicks

and some can be done entirely through the command line okay tests so you have a nice section on

integration tests on the for the package um just yeah you know there's a lot to say there but

you know tests are important they're challenging to well do an automated universal can i come back

to that because i think um what would be good is to to focus on what this looks like for users

for a moment um and then come back to the the developer perspective so who's this project aimed

at um this is aimed at people who are brand new to programming brand new to to web development

um they finally gotten their project uh working locally and they want to to push it live um

it's saying that people who may have more experience as a programmer but haven't

delved into deployment, is not meant as a replacement for products like cookie cutter

that are much more about configuring a more complete, complex production level project.

And there's a variety of reasons for that.

One of the goals for me is to provide something that is reliable and will be maintained.

And so I can, I can commit to maintaining this project, especially if, if it ends up

in the next edition of Python crash course, I am motivated to, it's actually my maintenance

work becomes easier because right now, um, Heroku will knows this Heroku is quite likely

to change their process at some point, uh, cause they have mothballed the project that

they're relying on.

Um, it is getting more and more out of date and likely to break.

and so once it fully breaks they're going to have to change something and so if i don't do

jango simple deploy then i'm going to need to rewrite half of a chapter in my book the moment

decides to change their process if i write my if i revise my book based on jango simple deploy

that acts as a layer between my book and Hiroko's process. Um, and I'm, you know, book, book driven

development. Um, when we see a pain point as authors, it's an opportunity for a tool. If your

tool only supports your readers, then that tool is going to go away as soon as your, your book is

out of print. Um, and also your readers are going to have to go find something else to solve that

problem as soon as they're out of your book. Um, so I am developing this, uh, for my own motivation,

but also for general use. And so if this idea is good, I think, um, book authors, tutorial authors,

video authors, um, if you're, if the focus of your resource is not deployment, then this is

a really good tool for just saying like, okay, here, we built this, this project. Um, here's

three commands you can throw it online and now we can focus on whatever aspect of the

the project we want to carlton would button work with this can you command lines yeah i mean so

the idea is i give you a list of um environment variables that you need to um for the most basic

setup a list of environment variables that you need to root um or settings that you need to

populate from the environment um and that would i need to look at the scripts but the idea would

be i guess that you edit the um the settings file to to draw because aroka gives you um your

database url for instance that you have to pull from the environment right um so in principle

that would work in a similar kind of way the i what i like about what eric's talking about is

that it's literally that one, two, three

in your existing Django environment.

I think that's really sweet for that first deploy.

I think that's a lovely pip install,

add to installed app.

So you've got a management command

and then just run it.

That's lovely.

Yeah, a good example for how to think about this

is one of you mentioned earlier,

people working through the polls tutorial.

And so they spend a week and they go through polls

and it works in their system.

They're like, cool, I'm going to deploy this.

And then, Oh, another week of learning, um, people who get to that point in their learning

can run these three commands.

And then their pulse tutorial that was working on their system is now in the live browser

tab.

Um, it doesn't, it doesn't mean you don't have to learn about deployment because you

do need to understand what changes were made.

If you're going to support that project on an ongoing basis and build on it.

And so in my mind, what this really does is people get to the point of being ready to learn about deployment, and now they have that week of learning, and that week of learning is filled with opportunities to make a mistake.

Okay, for Heroku, you need to make a proc file.

What if you make a typo in your proc file?

All right, your project is not going to deploy, and we can look at Heroku output and say, oh, there's where the mistake was.

But most people, that Heroku output is a wall of text, and they have no idea where to start to look for that mistake.

And so a little typo can mean days of kind of poking around,

trying to figure out why your product is not working.

And beyond just those hours or days of difficulty, that's that cliff.

There are people, every one of those typos that happen,

there's somebody who says, like, oh, this is too hard, or I'm too busy,

I can't figure this out, and they never come back to it.

And so this kind of flips that learning process around.

It says, run these three commands.

Now your product is live.

And now you can go back and look at, okay, what are the changes that were made?

If I'm going to do this again on a production level, what will I need to know?

And I think that that's a pretty compelling, to use a word, pedagogical approach.

Well, that's in a way what I, so my beginner's book, I wrote it in part because there was

the Rails tutorial where the first chapter basically was like install, create something

and deploy it. Boom. You don't know what's going on. It's all magic. But I wanted, to your point,

something like that for Django. So in my books, like the first real project you do, which is

pretty basic, I forget what it is. I think it's just a pages. It's just like a homepage and about

page, but you deploy it. And I even say like, don't really worry about this. This is just the

checklist, but I want you to get that feeling of something live that you can share with people,

to your point, to get that aha moment, and then try to iterate and add complexity.

Because yeah, you do need that. And I was going to say to you, one thing I was

impressed by reading both your books the first time and then the update is Learning Log is not

a simple Django project. You go right into it. You've got user accounts, you've got static files.

You know, it's not, it could be simpler. I think it's great that it's not, but I think part of,

You know, your other one is a statistical one, and the Pygame one, those feel there's more space to be descriptive, whereas the Django one, you cover a ton of information.

So I think that's part of, you know, kudos to you for doing that.

But if it was a simpler project, but I guess it's like, are you focusing on Django or are you focusing on the deployment?

Because it would make deployment easier if you just had something simpler, but then you're not really learning about Django, which I know is the point of your book, is to say, here's a Python web framework.

you can do something interesting with.

Okay, clarify what I mean by simple project.

If you're using this default user accounts,

the default auth packages in Django,

I'm considering that fairly simple.

If you're doing email...

Well, but users are confusing though, right?

I don't even put in users in the first two projects I cover.

I think you need it.

I think it's great to do, but it's another thing.

It's like, what's a user?

What's a session?

How do I log in?

Even though you tell people, that's a cliff for newbies.

I don't think my deployment work would be much easier if I left users out because the Heroku deployment steps are pretty prescriptive regardless of what your project looks like.

Proc file may be as simple if you don't have static files, but projects don't look very good without any static files.

Well, and the collect static thing on Heroku, that's something that trips things up a lot.

That it automatically, unless you turn it off, runs collect static.

That leads to a lot of beginner errors.

Yes.

Yes.

Again, that's another good point where the whole point of this is everything is done correctly for you, and then you get to go back and look at it.

Carlton, you were going to say something.

No, I was just, you know, I'm just thinking like, you know, the standard, that kind of standard setup that, you know, use for the simplest deployment, configure the virtual env, you know, migrate the DB, collect static, run the, you know, run the Whiskey server.

That's kind of it, right?

But to wrap that up nicely is the challenge.

and you know yeah anyway i haven't got anything particularly interesting to say i'm just

thinking hard can i so you mentioned the the third edition of your book is there

anything else you can tease that you're going to change or update no other than deployment

no i uh i'm not sure when the third edition will come out um everything in the second edition is

up to date. And so we try to, as, as you're well familiar with, try to maximize the lifespan of

each edition. Um, but as soon as the new edition comes out, um, I start a note file about what I

might need to change or want to change. Um, and so like I played with the Heroku build pack last

year. Um, I'm trying this approach now. I think this is going to work. I think this is a really

good project um and i think i'm going to use it and i think we're going to see some people use it

for um for tutorials um yeah um if you guys want to talk i i kind of think of this conversation

as motivation you know what's our our all collective experience with deployment why do we

groan um what does this look like for because we're old it's because we're old eric doesn't

matter what it is no i've heard the the young people groan about it too um my groan is the

same now as it was 15 years ago um and we talked about what it's like for learners and i think that

the third aspect of this is okay implementation uh is there anything you are curious about what

this looks like but um under the the hood because to users this is really three those three commands

install it uh add it to installed apps run it and then their project is online and

and i'm my next piece of work is to clean up the output and consider the artifacts that are left

behind um and i think what i'll probably do is dump um some files some text files maybe markdown

files into a folder in the project so you know this runs in the terminal you get a whole bunch

of information about your deployment.

And then once you close your terminal,

that information is gone.

And you can run something like Heroku Apps Info

and see what the current state of your project.

But I think I want to create a folder in the project,

like deployment notes,

and it just summarizes what was done,

summarizes how to make your next change,

and then maybe links to resources.

Because I don't want to pretend

that this is um a replacement for learning about deployment it just does that initial deployment

and then you need to move on and understand the deployment and how to work with it um

so you leave enough behind that people can know where to go to learn more and use it

because it's also like okay we just changed your project and so that's that's an interesting step

too i mean i just wonder from um you talked about it being a pedagogical approach i wonder

would you would you advise people to do something like a git commit before they run it and then so

they've got a nice um git diff that shows them exactly what the changes were that kind of

you know it's a great question um so there's actually two ways to use a command so the the

three-step version is the simplest. If you

run it without the automate all flag, then it configures

your project, and it leaves it for you to push the project.

So the two assumptions about this product are one,

that you have specified your requirements, either using

requirements.txt, pipenv, or poetry,

and then that you are using git to track

your your project um so if you run a simple deploy manage.py simple deploy without the automate all

flag then it just configures your project so that it's ready to push to heroku um builds your proc

file there's a static file settings uh such a config variable for debug to be false in the

production version generates a new secret key and so yeah after that you can look at your project

and then do the git push command.

I did, one of my challenges with this

was to answer the question,

what's the minimum number of commands?

And so that automate all,

going back to the idea of like,

what people want is an opinionated approach

to all those deployment questions.

Should debug be false

or can I leave it true in my first deployment?

Okay, I decided for this project,

I'll make it false by default

and then show you how you can you can make it true um because you know those of us who have

experience with production apps the idea of debug being true in production is oh gosh why would you

even consider that but for your very first deployment where you're just understanding

the process uh being able to say like okay it works on my screen my local system is not working

all i get is this blank error page if you can turn debug true on for a moment and just see oh okay

that's what heroku sees um you can fix that and i think there's i think there's room to let people

do that and not give them the impression that that's okay to do sometimes in production

but the opinion is set it false initially give them a good a good starting point and go from

there it has to be at least safe by default right because for every right for every person who's in

that learning position where um you know perhaps turning on debo true just to see the out there

output you know it might be a safe thing to do because it's a learning project there's be someone

else who's literally deploying their business using just the basic three commands and not

really thinking about it at all and whilst it's incumbent upon them to think about it

kind of we know that they won't so making it safe by default is a good idea

one thing that resonates with me is what we're talking about here which is the the next step

for for readers or consumers of your you know of your open source project or your book i i feel

like the weakest part of my books is, of course, I would say this because I wrote them, so I think

they're okay, but I think the weakest part is where I direct people next. I spend a lot of time

trying to think about not just saying, oh, see you later. Here's a couple of websites. Is there

something pedagogical? Is there something more I can do to guide people? Because it's easy to say,

well, you'd go learn about deployment online. Short of making that resource myself, how do I

like make a roadmap, roadmap or curriculum for people. I'm sure you've thought about this too.

So that's a way to tee up deployment. If you were going to create or write a book on deployment or

curriculum, what would you say someone should do? Like, how do you go about that? Because it's,

I don't know of a place that goes step-by-step in a progressive manner through, through all that.

Boy, uh, that is hard. I ended up, okay. One of the, the, um, kinds of emails I got most

consistently after python crash course started to become popular is what next so people would

write and say thank you for for this book it really helped me get through the initial learning

what now um and yeah i'd give some quick thoughts but i ended up writing um in the online resources

for the book a section called recommended reading um and it's really yeah that's a really nice yeah

Yeah, it's really four or five pages of, okay, you got through the base of the pyramid or the trunk of the tree, and now there's all kinds of directions you can go. And so where do you go with your general Python learning? Where do you go with Django? Where do you go with all the surroundings of things like Bash and databases and all that?

So I don't think there's a simple, quick answer.

I think you have to either have a one-on-one conversation with people and sort out where they need to go or provide a kind of map of where you can go.

Interesting.

And I think it's hard to do that in a book.

I think you can provide that online, but it's really hard in a book to say, here's all the directions you can go.

Taking your point.

Sorry.

Go on, carry on.

For deployment specifically,

for deployment specifically,

I don't know that there ever will be a book

because it changes so much

and there's so many options.

And so at some point,

like Carlton said,

okay, some people are going to use a product

like this for their business, and okay, if you want to start proof of concept with something

like Django Simple Deploy, you can try that, but if you're building out business-critical

infrastructure on, say, Django, you have to dig into deployment, and so you have to choose

a platform, and then you do need to spend time digging into that platform's documentation

or consult or pay somebody who knows it better already.

And those are conversations that sometimes people need

rather than just, here's the resource.

Sometimes it's what they really need is like,

okay, how do you think about building a business

on top of what you just learned?

Taking the phrase you used, Will,

about go learn about deployment online,

one of the motivations for getting started with Button

was that actually if people go and start trying to type

about deployment online was that they get taken into this sort of tiger pit of um macho deployment

you know one-upmanship where it's like well you know we're using this and sure for the big

companies and serious engineers that's important stuff you talk about deployment cliff i always

think of it as the deployment gap there's the beginners over here and then a massive gap to

the infrastructure engineers all the way over there and yes if you try and learn online it's

all it is is infrastructure engineer stuff and you can't it's really hard to find deployment

you know for for the for your 95 of projects who don't have a 10 000 um concurrent request

problem they've got a 10 concurrent request program you know they got i just need it to

serve a few requests i just need to get my app online that's really difficult to find resources

for especially if you just start googling i think that's right that if someone's taking the time to

write something it's generally an advanced person who's proud of something they figured out but it

doesn't yeah it doesn't apply to the 95 i've often wondered how do you is there a way to

there probably is but i don't know what it is to to mimic the load of a high performance

site without all the costs you know involved right so we say to people well like is there a way to

teach someone say okay i'm gonna make a sandbox and i'm gonna mock getting slammed with all these

requests you know either one at a time or all at once or that's simply i mean you know like once a

day versus like continuous heavy load and then have someone go through the steps to fix that

is there a way to do that absent doing it live in a big company locust there's probably some way to

fake that but locust io is a very good tool so you can you can define a set of requests that will

calm yeah and you can um you can say i want you know 30 requests from 100 you know i want so many

requests per second so many clients and i want them to scale up at this rate and what's really

nice is it gives you it's really difficult to interpret you know you have to go slowly and

interpret the results you know intelligently and that takes time and looking at it but you can kind

of see where your response time starts to flatten off and you're like right that's that's actually

you know, if it starts, you know, you get to 10 and it's going up nicely and you're like,

brilliant. And then 15 requests, it starts to tell. And then 30 requests, it's like,

no, it's basically flatline. It's like, okay, that that's my, that's my limit. That's as many

as I can hit. And if hack and use hits me and I get more than that, you know, my site's not really

going to perform. Um, so it's a really good tool and it's, it's, you know, you use Python,

you write little Python scripts to, um, to generate this, this traffic. So yeah,

18 000 stars and i just learned about it so what was it called again it's called locust io locust

locust locust.io locust like the insect yeah yeah because it's like a plague of requests that come

down and eat your eat your website but it's a very useful tool for um you know you compare you want

to compare different setups and oh you know how how many how many gun gunicorn worker processes

should i use well okay you can spin up the box and you can try hitting it you know do i need a

if i if i hit eight what's how many requests can i get if i have four workers how many requests

can i hit if i use pre-fork versus threaded you know these these options which are in the

gunnicon comfort config option but like what difference do they make well with locus it's

very easy to sort of spin one up send some traffic against it with a particular profile and say okay

interestingly the pre-fork with four workers for this for this size unit is the best option

i would pay for a django locus book again i think that that's a great tutorial

maybe great like small online course but it'd be hard to write a book on that and i say write a

book on it and maintain it we're coming up a little bit on time i know we haven't dived into

this but i i have to kind of ask eric like the future of teaching tech like i think sometimes

deep thoughts about, you and I have made it work to different degrees, but most people,

it just doesn't pay to teach technology. And yet everyone wants to learn this stuff to get jobs.

And I wonder if your thinking has changed this last two years around, is there a solution there?

Because when I look at it, I see it's hard to do anything that's to consumers, directly to

consumers, because they don't have money out of pocket. It's hard to do something without

an accreditation where they get a degree and then they get a cyber degree and then they can go

check the box on a job. So the need is growing and yet the pathway to do it yourself, you have

to be very entrepreneurial. I mean, you wrote the book, but you also have the website, you have

these projects, you've been doing it for a long time. There isn't a straight path where someone

who knows this stuff, who wants to teach can make close to what they would make day jobbing

versus writing a book, and then they have to update it.

So I throw that to you as, you know, the need is there,

but the pieces to make it happen still seem to be missing to me.

Boy, cue up the big question.

Well, as a former teacher, too.

Right, right.

Or as a current classroom teacher.

Yeah.

The Orange site had an article yesterday about how we teach code is broken

or something like that.

I think of Carlton when big things come up, like, oh, gosh, okay, all the things we should think about for this.

So I think it's important when you're thinking of the question that Will just posed, to look at the history of learning resources for programming.

So if you go back to, say, the 50s or so, when people were first building these big physical computers, electronic computers, there was barely any documentation.

I mean, I don't know if people these days know this, but it used to be like your company or institution would order a giant room-filling computer.

That company would then come with trucks and install it into your institution, and you would pay people to come and facilitate your first use of that machine.

And then things got smaller and people wrote documentation

so that now you can just ship a computer and ship a manual

and leave it to your users to learn that.

And then people started writing books.

And those books were written by programmers for other programmers

with no real notion of non-programmers reading them.

So they're very dry and very technical.

And I should say very dry.

Some of them had some attempts at humor.

Um, and then, uh, programmers started writing for the general audience, but they're still

fairly dry, um, and fairly non, um, friendly, I should say non-pedagogical.

Uh, there were, they were not written with a critical mindset of what might go wrong

and what happened, what can people do when something goes wrong?

Um, and then you started to have a mix of people with programming background and more

general backgrounds.

And so you started to see better programming books where the technical, uh, foundation

was still strong, but there was more thinking about, okay, what might, might it be like

for a non-programmer to, to work through this?

Um, and in the past 10 years or so, I feel like there's been more, um, more coming out

from people who have a pedagogical background have experience thinking and working with people

who are learning and focusing on okay we need a solid technical foundation for this resource

and we need clear critical intentional thinking about how people learn what they already know

what they're learning in this resource and then where they're going to go next and it's about

connecting that path. Um, so my takeaway from that article yesterday is like how we teach code

isn't broken. It's just that there's, there's no one way to do it. And so there are some bad ways.

There's some really good ways. And the long-term thing that we're all aiming for is a wide variety

of really good learning approaches and learning resources that are well-maintained and, and whatnot.

Your question will have, how do you make money offering those, those resources and services?

That's another question.

I think of this because the startup I was at, Quizlet, is an education startup, which hopefully for me will go public this year.

But that's a rare case of something actually working out in the ed tech space.

There's this huge cliff.

I saw Codecademy just got sold.

They were founded around the same time.

Treehouse just imploded.

I wonder if there's any middle ground between FreeCodeCamp, which is fantastic,

And a structured curriculum that isn't paid by an employer or isn't doing all sorts of dark tricks to crank the knob on getting people to pay for something and not having a good outcome.

It seems like there are people who know this information and would like to teach it, but there isn't an easy way to just do it.

No, it's a hard problem, and I think people need to approach the problem of how do you create a learning resource that's going to be received well and used?

I think you need to think as critically and intentionally about that as you would building an engineering project.

It's a classic, like, people disappear into their computers for a year, build something, and then come out with a working product and be like, oh, how do I tell people about this?

How do I gain users?

And so it's the same thing with resources.

I think money is important to talk about with that, because a lot of these projects that have failed or even caused harm, their priority is making money.

And money and education are an interesting pair.

Well, the problem is success means people leave you faster.

You can't have a subscription education business, because if you succeed, they leave.

And even if you don't succeed, they're going to leave.

So Quizlet, right, loses a quarter of its users or, you know, less than that.

But, you know, if you think of a high school product, right, like you're losing a quarter every year.

It's not a great business.

Anyways, it's one of those.

So you have to think about that.

And so what that means is, okay, if you're successful, your users leave, but then they should be telling other people how they learned.

And this should be a fresh cover every year, no?

Right.

and so high schools get that because people just show up um and so for learning resource your your

hope is that um people will use your project be successful leave and then tell other people about

it i will say something about pricing you know i see beginner-friendly pricing i mean books are

still popular because people can afford them largely um the value that people get out of my

books or will's books are just fantastic um and your book is so you know it's what 500 pages i

mean it's yeah off the charts the value 25 bucks and they get life-changing experience um but i

also see people charging 250 for um independently produced materials and so there's videos there's

a place for that there's a place for that in uh niche markets where you never can have a large

audience a large number of buyers and there's a place for that in corporate um but when people

are aiming um materials that are aimed at individuals and pricing it at multiple hundred

dollars that's that's an interesting decision and so you i think that if you're going into

educational materials you need to think through all those and come up with an answer that makes

sense for yourself for your learners and and for the market in the world yeah well edX just got

sold too which makes me sad and it reminds me that uh back in my younger years in 2010

I had a chance to meet the founders of both Segment and Stripe multiple times and both of

them started off with education products and then pivoted to respectively the three billion dollar

acquisition and probably a hundred billion dollar ipo um so you know the desire was there but the

business model um you know that can't be the reason why you why you do it anyways there's

nothing to say after that but you know it's a perfect thing yeah so we will have links to all

the things mentioned django simple deploy it's on github try it out use it i think people know

about eric's eric's book flashcards all the rest um thank you for taking i make one request yeah

please of listeners yeah so i don't have anything to promote beyond what will is mentioning um but

for django simple deploy it's on github um and if you have if you're interested in this project

if you have a simple project of your own and want to just try it i'd love to know if it works

um if you are creating learning resources for Django and the idea of being able to let your

your users um deploy the project quickly um please give it a try and if you have any feedback

on how this could be useful to you as a creative learning resources I'd love to know that

because I'm creating it for my own needs but it will do well if it serves um many people's needs

So if you have any interest in this project, please do reach out.

I'm going to do that myself once I finish the last two of my book updates.

But that's something I want to do, as well as button.dev whenever that's ready.

I promise, Carlton, when it's live, live, I will do a tutorial for him.

I just need about three weeks of normality, and then we're there.

All right.

Well, again, thank you, Eric.

We are DjangoChat.com, ChatDjango on Twitter.

And we'll see everyone next time.

Bye-bye.

Join us next time.

Bye-bye.

Thank you.

Bye.

Subtitles by the Amara.org community