Transcript: Django Deployments - Eric Matthes (Ep108 Replay)

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

for why not the heroku stories how does that how does that um sound to you eric if i just

throw it up in here and you can smack it over the bleachers oh i have not heard that uh metaphor

before i think it's brilliant i like the cul-de-sac uh but i have been yeah no it's a it's

a nice coldy sack but the second you're your 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 dino and this section and it becomes

it goes from 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

um i have been curious i 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 i groan and moan in the kitchen and laugh and i'm sure it happens all over the

place um so i was going to ask you guys um what's your thoughts on why so deployment is critical for

um 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 share why i laugh when i'm listening

okay i'll start i'll start you're making bunny ears at me i was like peace sign

well no i've got two i got two points i'll say but you go first will and then i'll say mine okay

okay uh so i thought yeah i thought a lot about this both you know at a company deployment you

know 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 Django is not responsible per se

for deployment, yet because we use it, we think, oh, it should just have that too. Heroku is really

good. It's designed for Rails. So Rails, there's a one-click solution. There's several steps to

make uh 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 sequel light

you don't have to worry about security everything defaults to it but then when it's production it's

the 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 it's how do I do that? You know, 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 to 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 basically hit my points. I think that I'd say there's so many

options like one reason that there there isn't a django solution is that um we can't agree so um

quite regularly it comes up to the django developers mailing list um something like oh can we can we

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

mviles aren't mvars 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 it so much depends it depends there you are we've

done it we're seven minutes in bingo so it so much depends on what what your 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 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 they are too many options too many options too

many moving parts they're my they're my one and two i 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 these are check these are

checklists you know like a pilot flying a plane i'm robbing uh daniele profiter'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 netlify bought this

company, Drop, where you can drag and drop a static site, just 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, it has a hosted database, it has 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 a more advanced case. No, no. So 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 there um okay eric you you go for half an hour now all right um boy

one of the things I was thinking about, um, 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. Um, 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 a 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. Wow, 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.

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 when I think of this specifically for people who are new to Django

or new to deployment, I think of deployment as a cliff.

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 it a little bit and see like, oh, my idea works, and it's all working on your local system.

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, yeah, what do we do about that cliff?

I just finished listening to your conversation with Adam, where he talks about book-driven

development. And I think that's, it's a good phrase. 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.

And I've been thinking about like, okay, why have I been so dissatisfied with that part of the book?

And I realized, just thinking about this last night, that a lot of what I've written is

teaching people concepts, teaching people how to think about code, how to think about

solving problems with code.

When you get to that part of the book, it's 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 Heroku 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 three or four frameworks that use it.

Well, I think I have that answer for Heroku, or a fair understanding of that answer.

And this is a little plug for going to conferences when it's appropriate to do so.

I've gotten to meet, I think, all of 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 they're tasked with so many other things

that this never rises to priority and so i think is that that growth issue so heroku was founded

to make initial deployments easier they 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 um small issues

tend to disappear and unless somebody is is there long enough to to continue they say okay

there's been hanging out for a while we need to prioritize that it doesn't excuse it but i think

it 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 um this kind of niche because well you know

people getting their first jango up online aren't necessarily the biggest spenders yeah and i think

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 was, it's still referenced, it's dead and it's still there. And, but yeah, I don't doubt it's what you said. It's there, 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. You phrased it slightly strangely, Eric, in that you said something like, I found it uncomfortable that I was doing Heroku's 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 ruminating on this over the years, I realized that what didn't feel good

about that Heroku Buildpack solution was that it's grounded in the Heroku world. And so I realized

there's multiple ways to modify a project. So the Buildpack solution was to take your project

And as it heads toward the Heroku platform, on Heroku's end, modify the project for their deployment.

And I realize you can modify on your own end.

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 you can push your project pre-configured for that platform.

So I turned it 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 project 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 on Azure because I was looking for a platform

where you can do the entire deployment process

through the command line.

go ahead carl are you using app service there which is like the um the manage okay so these

your app service it's like the managed runtime it's like go on karen yes yes i 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 like from a couple years ago so is the app i did not they're good

you should check them out that azure is um app services like their their google app engine or

their heroku or that it's their sort of managed application environment their equivalent of that

right so um before we get into details about a specific platform i want to point out that um

for django simple deploy azure support is experimental right now um 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 dingo 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.

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 backend?

Well, it's interesting because 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 for the package.

There's a lot to say there, but tests are important.

They're challenging to do in an automated, universal.

Can I come back to that?

Because I think what would be good is to focus on what this looks like for users for a moment

and then come back to the developer perspective.

So who's this project aimed at?

This is aimed at people who are brand new to programming, brand new to web development.

They've finally gotten their project working locally, and they want to push it live.

And 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 commit to maintaining this project,

especially 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 Heroku, Will knows this,

Heroku is quite likely to change their process

at some point because they have mothballed

project that they're relying on, 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

Django simple deploy, then I'm going to need to rewrite half of a chapter in my book. The moment

Heroku decides to change their process. If I write my, if I revise my book based on Django simple

deploy, that acts as a layer between my book and Heroku'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.

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 uh done correctly for you and then you get to go back and look at it carlton you

were gonna 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 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 um 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 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 and i think what i'll probably do is dump 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

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 project.

So if you run 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.

Builds your proc file, does the static file settings, sets 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 make it true.

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,

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,

you can fix that.

And 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 starting point and go from there.

It has to be at least safe by default, right?

Because for every person who's in that learning position where, you know, perhaps turning on DevoTrue just to see the error output, you know, it might be a safe thing to do because it's a learning project.

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

make a roadmap or a 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 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 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 um all the the surroundings of

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

um or provide a um kind of map of where you can go interesting interesting and i think it's hard

to do that in a book i think you kind of i think that's an you can provide that online but it's

really hard in a book to say here's all the the directions you can go take taking your point and

for sorry go 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 um to different degrees but most people it just

doesn't pay to to teach technology and it's 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 i see it's hard to do anything as 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 you know 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 like do it yourself you have

to be very entrepreneurial i mean you you wrote the book but you also you have the website you

have these projects you've been doing it for a long time like 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 i throw that to you is you know

the need is there but the pieces to to make it happen still seem to be missing to me boy uh

cue up the big question well you're as a former teacher too right right or as a current different

classroom teacher yeah uh the orange site had a an article yesterday about how we teach code is

broke broken or something like that i think of carlton when big things come up like oh oh gosh

okay all the all the things we should think about for this so i think it's it's important when you're

thinking of the question that will just posed um 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 um 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 like come with trucks and install it into

your institution and you would pay people to come and like 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. And then programmers started writing for the

general audience, but they're still fairly dry and fairly non-friendly, I should say,

non-pedagogical. They were not written with a critical mindset of what might go wrong

and what can people do when something goes wrong.

And then you started to have a mix of people

with a programming background and more general backgrounds.

And so you started to see better programming books

where the technical foundation was still strong,

but there was more thinking about,

okay, what might it be like for a non-programmer

to work through this?

And in the past 10 years or so,

I feel like there's been 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 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 combo 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, there's a, there's a place for that.

There's a place for that in, uh, niche markets where you never can have an, uh, a large audience,

a large number of buyers, and there's a place for that in corporate.

But when people are aiming materials that are aimed at individuals

and pricing it at multiple hundred dollars, that's an interesting decision.

And so 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 for the market and the world.

Yeah. Well, edX just got sold too, which makes me sad. And it reminds me that

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 $3 billion acquisition and probably $100 billion IPO.

So the desire was there, but the business model, that can't be the reason why you

while you do it anyways there's nothing to say after that you know it's a perfect thing yeah

so we all 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

can i make one request yeah yeah please do please of listeners yeah so i don't have anything to

promote beyond what Will is mentioning, but for Django Simple Deploy, it's on GitHub.

And 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. If you are creating learning resources for Django and

the idea of being able to let your users deploy the project quickly, 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 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.

need about three weeks of normality and then we're there so all right well again thank you eric we

are jango chat.com chat jango on twitter and we'll see everyone next time bye-bye join us next time

bye-bye thank you bye