Transcript: Django Deployments - Eric Matthes

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

Hi, Carlton.

Hello, Will.

Welcome, Eric.

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.

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

Yeah.

Yeah, um to briefly catch up, uh 2019, I left the classroom um because it turns out writing a popular book and teaching means two jobs.

Um so I've basically worked two jobs for five years, um, 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 um 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.

Because Heroku is great, but doesn't quite get you where we want to be.

So I think we're gonna talk about that, right?

Like our ideal wish list for deployment.

But um and and maybe we could tee up and maybe Carlton to you since you're working on

So you mentioned Heroku.

So I kind of I 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 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?

I think it's brilliant.

I like the cold attack, uh, but I have been.

Right.

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 have 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 gonna 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 why I laugh when I'm listening.

You're making bunny ears at me.

I was like, peace sign.

Uh so I've thought yeah, 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 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.

You know, Heroku is really good.

It's designed for Rails.

So Rails, there's a one-click solution.

You know, there's is 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 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.

Um, 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 know, you ask the experts, they all tell you something different about how to deploy.

Um so to me, that's I think the crux of it.

So it's partly Django, but I think it's more the local to 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,

I think that that um I 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 um include a solution for n 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 vials aren't nvas 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.

That there's that 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.

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 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 Ember's, 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 they're my my one and two.

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.

I'm robbing uh Danny Ali Profit'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.

So it's okay to look it up.

It's okay to have a checklist.

That's that's allowed.

I would want something like so there's Net Netlify bought this company drop, where you can drag and drop a static site, uh, 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, it 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 gonna 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 f 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.

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 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 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 1.4 or 1.5.

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 it 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 involved changing the structure 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, uh 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.

Um, 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.

Um, and this is before Heroku.

And so my solution was to um uh uh configure a laptop to run with the lid closed, and I get it got it running on RunServer and dumped it into a closet, and we all had access to it.

And I'm so perfect.

Yeah, and so

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

Um so if you think of people who are just learning Django, um, you know, it's a little intimidating for a lot of people to get into because there's so many moving parts.

Um, but they they face that 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 on your local system.

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

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

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

Um, and after that week of learning, I'm still gonna have this thing that I worry about um 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, learning log project that we build in the in the book.

Um that's the most fragile part of the book uh because it 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 disfat 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 problems 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 uh as grateful as I am to Heroku for what they have offered, I 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 they're 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.

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, uh, 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.

Um 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 Heroku.

But that didn't feel good.

Um, it did not feel good though, because it really did feel like doing Heroku's work for them.

Um and Dana Greenfeld, pie Danny, um pointed that out, 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 it did not leave a good feeling behind for me.

No, like

I mean, I've tried to I saw 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 you know this other service work?

Uh I've wondered why don't they invest in someone to do this.

You know, Stripe, for example.

You know, Stripe's a great company.

I had the official Django Stripe tutorial for a long time, and I had a team of a I think it was a half dozen Stripe employees kind of jumping on my back to update it for this and that.

I was like, think calculating, okay, six of you, the time it takes, like that's so much money.

Like you just do it.

You know, like why why are you outsourcing this?

Like, why don't you just take a half dozen popular frameworks and do it?

And I still don't have a good answer for why they do that.

Uh 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 it's a little mystifying to me, but I've also just uh 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 I've asked a lot of developer advocates.

I I I wonder, I think they're more focused on like new features, whereas 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 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.

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 of the people who've been responsible for uh Django on Heroku over the years, uh Kenneth Wrights, um, back in probably 2013, 2015 ish, um, Casey Feist, I think, was for a while.

Um, I Ed Morley, I think, is is the current um Heroku person responsible for Django.

I haven't met him in person, but I've had conversations with him online.

Um, 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 it's 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 continually say, okay, this has 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 and not just Heroku, but a lot of organizations.

I think also um Jacob Kaplan Moss was at Heroku back in the day, and um I know around tooling, I mean Kenneth did a lot.

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

Um, you know, he really was making some efforts on that front, but yeah, he it was it's still referenced, it's dead, and it's still there.

And um but yeah, I I don't doubt it's what you said.

It's you know they're they're hit with so many other things, and if there isn't a top-level business case for it, it's

Um 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 to jump onto.

That's where business is.

Um you you phrased it slightly strangely, Eric, in that you said something like I found it it uncomfortable that I was doing Heroquous work.

And you the way you use the past tense slightly there, it sounds as if you've done something else that moves past that.

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 uh 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 uh pre-configured for that platform.

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

Um, 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.

I mean, I 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 how do you handle that part?

And so one of the things I I like about this project is it's not Heroku specific.

Um the goal is to take a simple Django project that works on your system and let you deploy it um as simply as possible.

And right now that's three steps, and I don't think you can get any uh shorter than that.

Um so one of my tests for is this project worthwhile is does it serve as a as a layer uh between our local projects and any platform?

And so I looked for a second platform to support.

And so I considered a number.

I I set it on Azure because I was looking for a platform where you can do the entire deployment process through the command line.

Um Go ahead, Carlton.

Which is like the um the managed okay, so the Azure App Service, it's like the managed runtime.

It's like the go on, Karen.

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 is the app.

I did not.

But Azure is um app services like their Google App Engine or their Heroku or that it's their the sort of managed application environment.

Um the equivalent of that.

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, Django simple deploy, add simple deploy to installed apps, and then an alternative deployment command is um manage.py simple deploy um, I think it's dash dash platform Azure, and then automate all.

And your project the runs, modifies your project, and it pushes to Azure and a new browser tab opens and your your project is live in Azure.

And so that's the vision for this project.

That if people have um a simple project that works in their system, they can deploy it where they want to in three commands.

But you know, it would work anywhere, right?

I mean, with the right back end.

So somebody out there, like, I'm gonna solve this problem and take that business away from those other providers.

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

That there are some providers where you have to go to their site, click in, um, do a couple of steps through their GUI, and then go back to your your system.

Every one of these platforms you have to go to their site to make an account.

Um, but once you have an account to do the deployment, some require clicks and some can be done entirely through the command line.

Okay.

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 they're challenging to doing that automated universal.

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 developer perspective.

So who's this project aimed at?

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

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

Um it's aimed at people who may have more experience as a programmer but haven't delved into um deployment.

It's not meant as a replacement for projects like Cookie Cutter uh that are much more about configuring um a more complete, complex um production level project.

Um and there's a variety of reasons for that.

One of the the goals for me is to provide something that is um reliable uh 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 um 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 because they have mothpawned 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 Django Simple Deploy, then I'm going to need to rewrite half of a chapter in my book the moment Heroku decides to uh change their process.

If I write my if I revise my book based on Django's Simple Deploy, that acts as a layer between my book and Heroku's process.

Um and I'm, you know, book driven 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 book is out of print.

Um, and also your readers are gonna have to go find something else uh 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've 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.

Can you command lines?

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 a Roku gives you um your database URL, for instance, that you have to pull from the environment, right?

Um 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 that literally that one, two, three in your existing um Django environment.

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

I think that's 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.

And so they spend a week and they go through polls and it works in their system and like, cool, I'm gonna 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 polls 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, what it in my mind, what this really does is people get to the point of being ready to 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, like, 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 of um of kind of poking around trying to figure out why your product is not working.

And beyond just those those hours or days of um 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.

Um, 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 the changes that were made?

Um if I'm gonna 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.

You know, 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 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 it's I even say, like, you know, don't really worry about this, like 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.

Um, because I yeah, you do need that.

And I was gonna say to you, one thing I was impressed by reading your both your books the first time and then the the update is learning log is not a simple Django project.

Like you go right into it.

You've got user accounts, you've got um static files, you've 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 with a statistical one and then the pie game one, those feel uh there's more space to be descriptive, whereas the Django one, you cover a ton of information.

Um 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 is I I know is the point of your book is to say here's a Python web framework you can do something interesting with.

Um if you're using the this default user accounts, the default auth packages in in Django.

I'm considering that fairly simple.

Uh if you're doing email.

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

I think it's I think you need it.

I think it's great to do, but you know, 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, it's a it that's a cliff, you know, for for newbies.

The Heroku deployment steps are pretty prescriptive regardless of what your project looks like.

Proc file maybe is simpler if you don't have static files, but projects don't look very good without any static files.

That uh leads to a lot of beginner errors.

Yes.

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

That's kind of it, right?

Uh 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 just think it's hard.

Is there anything else you can tease that you're uh gonna change or update?

Um everything in the second edition is up to date, and so we try to, 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 gonna work.

I think this is a really good project.

Um and I think I'm gonna 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 learners?

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 the the third aspect of this is okay, implementation.

Uh is there anything you're curious about what this looks like but um under the the hood?

Because to users, this is really three com 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 uh 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.

Um and then once you close your terminal, that information is gone.

And you can run something like Heroku Apps Info and see uh what the current state of your project put.

Um 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 you know, 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 leave enough behind that people can know where to go to learn more and use it.

Because it it's also like, okay, we just changed your project.

And so that's that's an interesting step too.

I wonder, do you 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

Um so there's actually two ways to use a command.

So the the three-step version is as simplest.

Um 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 project are one uh that you have specified your requirements, either using um requirements at text, pipem, or or poetry, and then uh that you are using git to track your your project.

Um so if you run uh 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, does it static file settings, uh sets a um config variable for debug to be false uh 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.

Uh I did one of my challenges with this was to uh answer the question, how 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 um approach to all those deployment questions.

Uh, 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 um 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, um 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 a false initially, give them a good a good starting point and go from there.

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

There's to 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.

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 I spend a lot of time trying to think about not just saying, oh, see you later, you know, here's here's a couple websites.

Like, can I 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, or you know, uh you know, 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.

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 four or five pages.

Yeah.

Yeah, it's really four or five pages of okay, you got through the the base of the pyramid or the 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.

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.

And so at some point, like Carlton said, okay, some people are gonna use a project like this for 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 if you're building out um business critical infrastructure on um say Django, like you have to dig into deployment.

And so you have to choose a platform, and then you do need to spend time um digging into that platform's documentation or you know, consult or pay somebody who knows it better already.

Um, and those are 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?

Like one of the motivations for getting started with Button was that actually if if people go and start trying to type about deployment online, was that they they get taken into this sort of tiger pit of um macho deployment uh you know, one-upman shit, 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 all it is is infrastructure engineer stuff, and you can't, it's really hard to find deployment, you know, for for the you for your 95% of projects who who don't have a 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'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 that's the same thing.

I mean all 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?

So you can you can define a set of requests that will come, yeah.

And you can um you can say, I want you know th 30 requests from 100 qu you know, I want so many quests per second from so many clients, and it 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, oh no, it's basically flat line.

It's like okay, that that's my that's my limit.

That's as many as I can hit.

And if hacker news hits me and I get more than that, you know, my site's not really gonna perform.

Um, so it's a really good tool, and it's quite it's you know, you use Python, you write little Python scripts to um to generate this this traffic.

So what

was it called again?

Locust, locust, locustio.io.

Yeah, yeah.

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 um Gunnarcorn worker processes should I use?

Well, yeah, okay, you can spin up the box and you can try hitting it, you know.

Do I need eight?

If I have four workers, how many requests can I hit?

If I use pre-fork versus threaded, you know, the these these options which are in the Gunnarcorn 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.

It may be great, like small online course, but it'd be hard to write a book on that.

And I I say write a book on it and maintain it.

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 just in the last two years around is there a solution there?

Because when I look at, 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 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 guess 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.

Uh the Orange site had a an article yesterday about how we teach code is broke broken or something like that.

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 I think another 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.

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

Um and then people started writing books.

Um, 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 and fairly non-friendly, I should say, non-pedagogical.

Uh, they 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 a 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 gonna go next.

And 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, of how do you make money offering those those resources and services?

That's a that's another question.

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

There's this huge cliff.

Like I saw Code Academy just got sold, they were founded around the same time.

Um Treehouse just imploded.

You know, there's I wonder if there's any middle ground between free code camp, which is fantastic, and a structured curriculum that isn't paid by an employer or isn't doing all sorts of dark tricks to up, you know, crank the knob on getting people to pay for something and not having a good outcome.

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

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 as critically and intentionally about that as you would building an engineering project.

Um it's a classic like people disappear into their 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?

Um and so it's the same thing with with resources.

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

Um and money and education are an interesting, interesting pair.

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

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

You know, 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 every year.

It's right, it's a not a great business.

Anyways, it's one of those.

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 so there

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 is just fantastic.

I mean, it's yeah, off the charts the value.

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 an 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 and come up with an answer that makes sense for yourself, uh, for your learners and and for the market and the world.

Well, edX just got sold too, which makes me sad.

And it reminds me that uh back in my younger years in 2010, um, 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 a hundred billion dollar IPO.

Um so you know, the the desire was there, but the business model, um, you know, that can't be the reason why you why you do it.

Anyways.

You know, it's a perfect end.

Yeah.

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

Yeah, yeah, please do.

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 creator of learning resources, I'd love to know that.

Um, 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 interest in this project, please do reach out.

Um 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 you.

Well, again, thank you, Eric.

We are DjangoChat.com, chat Django on Twitter, and we'll see everyone next time.

Bye bye.

Bye bye.

Bye.