Transcript: Django Testing - Jeff Triplett

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

by Will Vincent. Hi Carlton. And today we have a special guest, Jeff Triplett. Hi Jeff. Hi,

thanks for having me. When I thought of this podcast, one of the very first people I wanted

to have on or do it with was you, Jeff. So I'm pleased that we're finally making this happen

for episode 20 or whatever it is. So I was trying to think of how to describe your role

in the Django community, but I thought I'd punt it to you because you do so many things. So if

someone said, who are you and what do you do in Django? Where would you start? Probably that I

don't say no, which I'm working on. So I've been a lot better at saying no for a while. But yeah,

I am a Django and Python developer in Lawrence, Kansas, which is the home of Django. I do a lot

for the community, but I am a PSF board of director. I'm the president of Defna, which is the

nonprofit behind DjangoCon US. I've also been the former chair. I'm kind of an advisor organizer for

the conference too now. I'm a Python fellow, which is not the same thing as Carlton's Django

fellowship. I'm also a consultant and a partner at Revolution Systems in Lawrence, Kansas, which

is what pays my bills. All right. Do you say RevSys or Revolution Systems? How should we refer

to it um revolution systems is what everybody knows it as we just kind of say revsys you know

shorthand so it's kind of like defna the non-profit i'm a part of is the django events foundation of

north america it's just easier to say defna so revsys is the same okay great so um given that

you are a professional consultant one of the things uh i want to ask you about is testing

so this is something that carlton and i are asked frequently by readers uh excuse me by listeners

and you know I think as a consultant you have sort of a unique view because you get to see a

lot of different code bases existing projects as well as new projects from scratch whereas

most people are kind of working on the same code base for years at a time and so they don't

necessarily have a chance to think about how they do test so I'm curious if maybe the three of us

can just talk about testing and I don't know where we start if it's on a new project or an

existing one maybe we'll start with an existing one because we've had that conversation where

Yeah, I mean, one thing I'm really interested in when you get a client and you get a new project and then you're like, ah, we've got to perhaps say it hasn't got tests.

Right. Let's start there. That's the archetypal. What do you do if you get a.

Yeah. So Carlton comes to you and says, here's my project, but I've got no tests. What do you do?

Well, that's not uncommon, but it's also not super common.

And so usually we're kind of somewhere in the middle.

And especially like as a consultant, you have a problem and you're coming to us either because you want to build something or, you know, you've got fires every time you deploy code.

So starting from no tests, the first thing I want to do is basically lay down a simple layer of tests.

And so I want it to be effective because I do not like writing tests.

I don't know that many people who really like writing tests.

One of my coworkers, Lacey Williams Central, she loves writing tests for some reason.

And so you open up a test file, you can see thousands of lines of code.

Not what I do, but what I will do is I think the most effective way to start is to look at your views in Django.

If you're doing Django REST framework stuff, you can also do endpoints, which is also a view in Django.

So I'll start there.

And what I'll try to do is just a really thin layer of test everything that's a view, record the status codes, and just see what they are.

And so you'll get a lot of 200 status codes, which are going to tell you that everything

is working in some way.

It may not be working 100%, but at least Django is telling you things are fine.

Then I'll go through and I'll still record like 400 and 500 error tests or status codes,

which is going to tell you that maybe there's a piece of data missing to be able to see

that view and to have all the information come up.

And so once we kind of very quickly go through and just get some kind of test coverage, and

then that way, at least we have a test suite.

So if I go in and delete a bunch of code or I make changes, it'll at least tell me if the status codes are going to be the same.

And then once we have that reassurance, then we'll go back and start looking at, you know, why is there a 400 error on this or a 404 in this particular view?

That may be that, like, I'm trying to hit a blog article or something and it just doesn't exist.

So then that gives me room to be able then to do, like, generate some data or use, like, a factory library, which will, you know, create fake data.

And then I can start testing against that to see, you know, does this view work as expected?

After that, then we'll hit the 500 level code or 500, excuse me, status codes and start making sure that, you know, we have the parts of the view that need to be there for the application to not blow up.

So if it's a blog or something, there might be categories, there might be tags, there might be authors, there might be some other bits of information there that's needed just to construct that view and to make it testable.

Once this is done, another pass I like to go back and do is Django has a really nice feature called Assert NumQueries inside the test framework.

And so we'll use that then to start, like, measuring how many database calls each view has.

And this is usually what's pretty critical.

Like, if you called me because your homepage is slow, when I start looking at how many database queries are on it, you may have 200 database queries or you might have 2,000.

So that's kind of a good place to start.

And if, like, every view starts to have, like, a ton of database queries, that may mean that you have, like, a part of middleware that runs a number of requests that's going to be hitting the database more than it should.

And so once you kind of have this base level of test to know the status codes are good, you know where the database queries are, then we can start making performance decisions.

So we've had a lot of, like, nightmare stories where we had a middleware one time where a client was hitting their database and pulling up and trying to do it.

I think this was like the earlier prefetch-related days or something.

Or, yeah, I think it's prefetch-related.

Because select-related was there first, and then prefetch was added, I think, right?

Correct.

So basically prefetch would load up everything associated with a table.

So it might do like an early lookup.

And so this was a case where somebody had, let's say, 250,000 categories.

And so every single request made to any page on their website was reloading this table.

And they weren't caching it either.

Yeah, I was going to say, just cache it.

No problem.

Yeah.

Yeah. Yeah. So if you cache it, it wouldn't have been bad. It still would be bad because

that's a lot of data. Well, yeah. I mean, it's a number of requests. It's a first step. Yeah.

So I think this has been fixed in Django now. So you can actually like limit the number of

records that are going to be accessed. So that was like a pretty blurring. Like that was an easy

one. Like let's just eliminate this one middleware, cache this one request or this access.

So that only gets hit one time and let's limit actually how much data it's pulling in. And then

your website's going to be a whole lot more performant than it was before. But without tests,

without looking at database queries,

there's no way you would ever know

that that's actually what the problem was.

Yeah, that's super.

That's a really good example.

I assume that to see the number of database queries,

almost everyone's using Django Debug Toolbar.

Is that what you would use?

I actually never use it.

I think it's a great tool.

I just go straight to the test on that

because it's going to tell me more.

And most of the time, I'm dealing with back-end code.

So if I'm working on APIs, it doesn't really buy me much.

And again, I think it's a great tool.

It's just where do you spend your time?

And for me, most of it is just running tests.

There's actually sites that I've developed features for and APIs that I have probably maybe looked at the actual front end at it maybe once or twice.

Yeah, I use debug toolbar a lot for the templates because what it will do is show you the exact templates that were rendered, the includes that came in, the context that was available in each one.

It's like, yeah, that's quite handy, but that's a template layer rather than what Jeff's talking about.

Yeah, and where does logging fit into all of that?

Or does it?

It depends on what type of logging, really, because that's gotten so, I mean, so for some people, logging is just printing, you know, to the console.

We've dealt with some pretty big systems where, you know, we're basically spitting out JSON via Django struct log, and that's getting consumed by like another process.

So especially like in the Docker world, like we're collecting the logs sometimes and aggregating it to like another system where we can go in and check and see what's going on.

So we can leave clues about metrics of this user logged in or this user did something else.

So it kind of depends on what you mean by logging.

Fair enough. Yeah.

So what about if you have a Greenfield project?

How does RevSys think about testing in that capacity?

Do you have an internal framework that you use on new projects?

Or what's different versus an existing project that you get?

Well, I mean, from the beginning, then we don't really have an excuse to not have good test coverage.

So, you know, and again, like I tend to start with views and part of it really depends on what the clients like.

What's our business objective?

Like right now we're working with a client that's a friend of mine.

And it's basically like a brew pub type service where you can walk into a restaurant, you can order food, they can bring it right out to you.

And you can do everything through your phone, which is kind of nice.

Because if the restaurant's busy, you don't have to worry about waiting.

If five of you sit down and a sixth and seventh person sit down after you've already made your order, then they can come back and bring you food or drinks or whatever.

Yeah, this is super common in Asia in particular.

I think this is like the norm, plus, yeah, not so much in the U.S. yet.

Yeah, so for that test or for that situation, we're starting with basically we've done all the modeling.

We'll write a little bit of model test for it, but we're basically looking at what's the business logic.

You know, is the business logic or is the main core part of the application going to be inventories or is it going to be the ordering systems?

And then we try to prioritize, like, what is the bread and butter of the application that has to work perfectly?

And then that's what we're going to make sure that we have 100% test coverage on.

And so from there, we just kind of distill it down.

If you have about pages, you probably don't need anything more than just a simple test to know that this thing doesn't blow up.

And like I was talking about database queries earlier, we just want to make sure that somebody doesn't add a template tag to pull in news articles or something and you end up not getting a select related on.

And all of a sudden you've got a couple of thousand database hits on your homepage because that's really frequent.

Yeah, it's worth testing the 200.

Does this template actually render?

You know, somebody mistypes a template, they use a template tag that's just, you know, you never loaded the page, you didn't check it was running.

But if you've got a unit test that just loads it and check that it returns something sensible, that error will be picked up.

Yeah, for sure.

So I definitely tend to like error more towards performance when it comes to testing.

Business logic.

This is something Carlton and I have talked a lot about and always like to ask guests.

How do you think about where to put that?

Because in Django, you can put it in the views, but you can also, and if you can, you can put it in the managers or in the models.

I'm wondering what sort of, how do you think about, you know, that question of where to put the logic?

And obviously that can change over the project as you build things out.

But I mean, do you subscribe to the fat models, slim views approach or?

I kind of I really don't like either one.

I mean, it kind of depends.

And part of being a consultant is people are very opinionated.

So some people will have thousands of lines of business logic inside of models.

And it's hard to follow.

And so I usually like a mix of in between with views,

especially with endpoints and stuff for doing like rest apis if you put too much of the business

logic in like a traditional django view then you're going to lose that whenever you're using

like django rest framework and so i tend to try to do as little as possible with a web request

so sometimes that means we're taking the actual logic and maybe putting it in celery

so i had an application i worked on a couple years ago where they would literally get millions of

hits um sometimes they're in really active like news and stuff like that and so people might come

and do a bunch of donations and so what we would do is batch order those those requests up and we

put them in celery to be processed because we don't want like any blocking to go on when you

hit a form or when you hit an endpoint we want to try to get the request you know we want to try to

get a response back to the user as quickly as possible so in that case we want the view to not

really do much, but do a quick validation check, get their information, batch things up, put it

inside of Celery, make the actual request go through, and then we can like email them later

to give them the, you know, to congratulate or thank them or whatever. So it really just kind

of depends on the application. I know signals aren't really popular. I tend to not want to put

a lot in signals, but I do tend to use signals as an easy way to hook into parts of an application

to call Celery. And that's a pattern that I'm pretty comfortable and happy to use.

And then, um, a pie test. Do you, you guys, uh, not you, you guys, that's funny. Actually,

do you want to plug your, your, you guys site? Yeah. So this is one of those things that just

kind of, it's, I guess, passive aggressively annoys me, but, uh, Lacey and I, Lacey Williams

Henshaw, we are coworkers and we worked on Django con together for four or five years.

And, um, one thing that we get a lot of, especially being in business meetings now that we work

together is you know there might be four or five guys in a room and then there will be you know one

woman and then someone will repeatedly use the term guys over and over and over again and it's

kind of one of those once you hear it you can't unhear it type of you know statements or phrases

and it's really common and so a lot of people will say like it's okay to use guys because it's gender

neutral well you know if i were to just use hey girls or hey gals in a room full of men people

would notice and you know it's there's just you know there's there's better ways to speak and so

it's an easy uh way to make people feel more inclusive and not make people feel exclusive so

we wrote a site and i'm gonna have to look it up i think it's heyguys.cc yeah we'll put it in the

show notes and it's just kind of a quick easy way to send to people and let them know like you know

i use it as like an email footer and so it just kind of reinforces it so once we've started using

like y'all. I've had clients thank us after the fact, and we don't correct them. It's like,

I'm not going to stop you in a meeting and say it. It's just kind of through osmosis of the

more that we can say this, the more that, you know, people will pick up on it after a while.

It's just about changing cognitive biases, right? It's not necessarily that

there's a conscious prejudice, but there's this kind of cognitive bias and this

this kind of paternalistic language that we use.

And if we just think about it, we can start to change it.

And perhaps we change the attitudes that created it.

I made that statement on purpose.

Well done.

But I was going to ask you all, do you use PyTest for your tests?

Yes.

Maybe you could talk about why.

Because I don't think everyone does.

What do you like about PyTest?

It's another thing to add in, but, you know, basically once you've learned it, it has a number of shortcuts is sort of the selling points of it.

Yeah, I think it's faster is probably why I started using it.

And it does have a lot of really neat plugins.

And so I don't know that I have like a bunch of go-tos that I can mention off the top of my head.

But there's some like different formatting.

It kind of has the right hooks involved so I can like pop into a stack trace at the right places, which is really helpful if a test is failing.

because I don't want to run a test suite that's going to take a while.

If I have to wait five minutes, which your test suite shouldn't,

you shouldn't have to wait that long anyways.

But I want to be able to debug and look at the code through tests

to try to figure out what's going on.

And PyTest just seems to work well.

It's a pretty good standard.

You can basically just install it and run it.

In most Django apps I've used, I really haven't even had to do much

to actually just be able to install it and run it and just go.

Actually, I think in a couple of dozen projects, I've never actually had to change any code to work with it.

RevSys does have an open source project called Django Test Plus, and it kind of adds some nice wrappers around the Django test suite.

And I believe the last couple of versions actually has some better PyTest support for it, too.

Because PyTest tends to like this very functional view type where you can make easy test functions and you don't have to have a class and stuff.

And Django Test Plus actually, well, PyTest kind of has some nice wrappers around not needing like a, what would you say, like a class-based test approach.

And so I tend to, since I learned a class-based test approach, that's what I tend to do with Django just because, I don't know, I've got a pattern that I like.

But I do plan to spend some more time writing like a PyTest native looking tests.

I'm sort of in halfway land in between.

I kind of used PyTest as a runner and I love plain asserts, you know, just being able to use the plain Python assert statement instead of self.

What was it? Assert equal. What was the parameters for that?

You know, that kind of remembering what the assert statements are.

But I still like the unit test style classes because they help me group tests.

And perhaps that's just because I'm not quite into the PyTest idiom yet.

But, you know, that's kind of where I'm at with it.

Yeah, I find that tests, because I'm asked a lot by people learning Django to cover testing, and I think it's a somewhat hard thing to teach because you rarely see it in any sort of linear fashion.

You'll see, you know, maybe an open source thing just has a bazillion tests and it's hard to make sense of it, yet most people, if they just throw something up, maybe won't have tests.

So tests are, I think of them as they're really confusing until you learn kind of the standard

tests that you write every time, kind of you were mentioning you have your standard views

tests, and then they get really boring because you're just kind of tossing them at everything.

So that's sort of the leap is like, you want to get to the point where you go, oh, okay,

I can just, you know, kind of copy these tests that I've written elsewhere to this project.

But until you get to that point, it is this feeling of, well, I don't even know how to

get this page to work.

And now I'm supposed to write tests and, oh, I'm supposed to do test-driven development

and write the test first.

it's like, well, I don't know where I'm trying to go. Um, that's kind of the mindset I see of

beginners. And so maybe with that said, I take it, you don't do a pure test driven approach or

how do you think about that? I don't, I feel like kind of my job, especially with like a

greenfield project is I want to model the project and I want to see the data first. And so I

actually, I kind of do a Django admin first approach. So I'll write the models and then I

pop them in Django admin because I feel like everything else in Django kind of derives from

that that pattern agree so when i start doing django django rest framework even a lot of the

filter options a lot of the way the data fits together the admin for me kind of models that

very well and so i once i can see it and visualize it and it's pretty easy for me sometimes to

discuss with other developers like how to make model changes that maybe they're struggling with

just because i will go into the admin i'll create the models and i'll interact with it and so it's

easier to see like a mini to mini in this situation may not be the best, you know, the best way to

model something, especially when you start getting into like Django REST framework, because dealing

with many of the minis, especially when you're doing like nested serializers. So you've got,

you know, multiple layers of models deeper, you know, model references in JSON, it's it's hard

to work with. And it's really, you know, you've got these really cool rapid design tools with

Django and Django REST framework. And as soon as you start getting into nested serializers,

it just all kind of falls down and you're doing everything by hand.

So, Carlton, you work on Jenga REST framework, don't you?

Yeah, I do. I've just been busy nodding away to everything you say, Jeff.

Can you fix that?

No, and I'll tell you why.

Like, there's a limit to what's auto-introspectable within, you know, reasonable effort.

Unless, you know, you have to be, I'm fairly sure that for some specific framework

in a specific setup you can create some code which will introspect much better than what's

available in Django REST framework but that will only apply to that particular project right and

particularly with nested serializers like there are different conventions are they meant to be

read only are they meant to be writable if they are writable how do you handle conflicts do you

do you abort the whole request do you write the ones which don't conflict and then report the

errors on the one that do how does that look what's the format of those serializers those

are decisions that a framework like red django rest framework can't make for you um not yet not

in this stage in in the technology where the technology frontier is um yeah what else can i

say i i you know i'm not at everything you said yeah it does get complex especially you know if

you've got a many to many with many to many with a through model and you want to serialize some

attributes from the through through model on the nested serial ah this you've just got to make

those decisions. And yes, I think, ultimately, you have to write serializers by hand. But

well, speaking of complexity, another thing I want to ask you about is what are your feelings

on Docker in terms of is it do you use it all the time on projects? Do you try to convince clients

of that they should switch to it if they're not? Where do you fall on that spectrum? And I say

this, you've you've actually taught me a lot about Docker over the last few months. So I know you

know how to use it. But I'm curious what your preferences are. I like it a lot. Actually,

I think it's overused, and sometimes people, you know, they see Docker as a hammer, and they just try to use Docker to solve everything.

Jessie Frizzell, who I'm a huge fan of, she's written some really amazing Go code, and I think she's written pretty much everything.

Like, I've seen discussions before, Spiral Online, where people are saying, this part of Kube is broken, and she's like, no, I fixed it.

And there's like, well, this is a bug, and this is something that's a bug in Docker.

and she'll point to literally her commits in like kube or docker or they'll then complain that this

is a problem in a particular like linux library and she'll point to the code that she fixed also

in linux and it's just amazing to see people like that who you know can who have worked on

and can work on go code and everything um didn't she just have a tweet other than i think i just

wanted to plug her because she's awesome so and didn't she just have a tweet a couple days ago

that said maybe containers were a mistake i saw that probably because of that overuse and i guess

i think why i was thinking of jesse is because she has this awesome github repo of docker files

and so she runs chrome and docker on her laptop and so everything she runs is is docker based

which is amazing wow um i like docker my clients are kind of mixed on it but what we can do with

containerization is just absolutely amazing and i don't mean me as like a consultant i just mean

technology wise, like when I compile a Docker container, when I make an image, I know that

that's kind of a contract that it's going to run if I give it the right environment, environment

variables and link it to the right, you know, context. So like, if I know this thing needs

Postgres, and it needs Redis, as long as I plug the right values in and tell it where to go,

it's going to run. And I've already tested it. So I know how it's going to perform.

When you start using like, some of the container services, and I don't want to plug any particular

one because they're all great and crap at the same time but it's really powerful to say like

i can start this running on one node and if i need a hundred of them i can spend that up in a couple

of minutes and that's amazing right and you can also it's more you can take it from one provider

to another much more easily because it is just containers it's also a lot easier i think working

with other developers because it's no longer oh well you know use use homebrew but you're on

Windows or you're on Linux, so you need to figure something else out. Like once I have a Docker

Compose set up and I run tests on it, I know as long as you have Docker installed on your machine,

it's going to run. And that can also run on like GitHub or GitLab. I guess GitLab since GitHub

doesn't have a test runner thing yet, but you know, I can, I can use CI tools to reliably run

and test it. And so that to me is pretty great. Yeah. I mean, I'm almost tempted with, with true

beginners who are struggling to, who want to do Django to install Python to say, well, let's just

jumped to docker but you know i can give them a recipe that works but then it i think it's a little

much for them but it does you know fundamentally it it is the answer which is a reproducible

environment that all team members can have and you can almost entirely mimic production locally too

which is pretty nice to do yeah it definitely can be but like let's say you take a beginner

how are you going to tell them to deploy django to digital ocean let's say like is that easier

do you tell them to use roku or what's the what's the answer isn't that now you're punting to me

so let me just say that i hate deployment um everybody does that's um well so i i think the

issue is that most people they don't have to deal with deployment they're in a company or an

environment where someone else has figured it out or you iterate on it you just kind of like hold

your breath and get through it and then it works um it's yeah it's it's a pain i mean i tell people

i usually recommend heroku or python anywhere just because they're pretty straightforward

and they have free tiers uh you know actually with heroku so in my book which should be out

by the time this is released jenga for professionals i'm uh finishing up the deployments

chapter and a big question i had is we use docker in the book do we deploy with docker as well

because heroku just added this um pretty recently and uh i think it's simpler when i show you

exactly how to do it um but i don't know exactly if it's simpler than i think it is than doing it

the old pro c file way um but there's just a lot of for heroku i mean heroku in particular

there's just a lot of steps right i mean it'd be nice if you know carlton or someone had a perfect

drag and drop deployment for Django. But, you know, collect static, you got to configure static

files. It's just a lot, a lot of things. It's hard to go from a basic CRUD app to a deployable

worthy project without taking a whole ton of shortcuts, allowed hosts, you know, deployment

checklist. So yeah, so that's a, that's a rambling way of saying I haven't fully figured out exactly

how to handle it other than I know the two extremes

and as I become

more comfortable with Django I'm less comfortable

just sort of waving my hands at

stuff and not

covering it for people but I am

still a big believer in an iterative

learning path and so I don't want to

overwhelm folks with proper deployment

so

it's tricky because there is no

there is no

really simple solution I'm still a big fan

of you know run a VM

and if you want to use docker just use docker on the vm and if you need to scale it get a bigger vm

for you know to keep a lot of these things simpler but that only goes so far and eventually you do

need you know 100 units and then you need you know kubernetes or whatever because you know vms

aren't going to go that far yeah i don't know what do you think i mean we actually just just had a

whole episode on deployments where i think we we gave some of our thoughts i mean basically the

advice is pick something learn it and then move on if you have to focus on it that's a great problem

to have and then you can take other steps well i think the selling point for me is if you ever try

to like set up a let's say a django app and not to pick on django any python app or really almost

anything it is a pain when you say php kind of has an advantage because you can in theory copy php

code and run it remotely on services that run php but if you try to host your own because if you

have a website that needs to scale at all you're not going to use that model and so you're going

to go and you're going to have to install I don't even know now Apache, you're going to install a

bunch of libraries and a bunch of stuff and the average person is not going to be able to do it.

And so one thing that I like and I think you could actually do this kind of tutorial. If you go and

fire up a DigitalOcean and DigitalOcean needs to sponsor you now I think we plugged them like four

or five times. But if you go to DigitalOcean, if you install Docker, you can actually run your base

image on port 80. And you don't have to install really anything else. And so that to me is pretty

powerful to just app get install docker run your image container you've got to do some authentication

stuff that you'd have to do anyways even if you're doing a get checkout and so one thing i've liked

is through like get lab or through docker's registry you can push images from your local

machine to that you can run another docker process i use one called watchtower and all it does is it

looks for new images it pulls in it restarts the service that's running that's about the most

simplistic architecture I can think of for how to run something if you're rolling on your own.

Now, that's built upon years of knowing, like, here's how these applications and these parts

put together. And that's really the challenge. It's not that this stuff is so technical,

you can't teach somebody. It's also that, you know, I kind of did all the crappy parts with

Linux for a long time. And I don't want to do that. But I also want to know what's running

behind the box, because I don't know that I want to hand a container to, you know, a cloud provider

and trust what's going on behind the scenes

or even know like if I'm paying X amount of dollars,

how do I, why do I get one Docker process

or how many Docker processes do I get?

And I think that it's been kind of hard

for cloud providers to be able to explain

and sell that to people in a way they understand it.

but what's probably done the best job of that what's also difficult is the costs you know you

don't it's really hard to see how things scale and short of like putting them on there and trusting

it and then finding you've got a big bill it's you know which you often read you know i i got

seventy thousand dollars on firebase or whatever it's like ah you know how do you control that i

would say that that that is true but like that is the problem you want to have um you want to have

such crazy traffic that you have a huge bill and then you, it's worth the time to dive in and,

and solve it. And I would add, I mean, this comes from, uh, even at scale, you know,

if you can throw hardware at a problem, any problem you can throw money at, I think that's

a good problem to have. I mean, you know, in a startup setting, like, yeah, okay, you need to

find the money, but it's so much easier to throw money than some of these trickier problems. So if

it's, Oh, we just need more machines. Okay. Like that's, that's a good problem, right? Like you're

always going to have problems um so yeah you don't want a seventy thousand dollar firebase bill but

kind of got to blame yourself if somehow you rack that up right i mean were you just sitting there

and you didn't see the analytics you didn't see the millions of traffic yeah i mean i don't know

you know i never again i would take that i would take that problem because either you just i don't

know either your company goes out of business because you don't know what you're doing anyways

or you're growing so fast you can find the money somehow like it's solvable

yeah you know like going bankrupt is a is a good fix for a success yeah but i mean on

deployment separately i don't know you know for any of these providers that are listening i mean

i was just going through the heroku docs yesterday and i've done heroku so many times and i was

finding the container part confusing like i would love to have a simple django project and just show

how to in i guess my words deploy it on all these major services but the challenge is that

they don't have affiliate fees so it's just totally giving it away it takes a lot of time

and they change all the time that's what's so difficult it's just not worth it um but

yeah if anyone wants to sponsor sponsor will to show how to deploy on your sponsor me i would

love to i would love to do that um but anyway separate moving on um right so i want to talk

about your community work jeff i want to talk about the work you've done oh we're going to

jump right to that yeah yeah come on we've got dockers i want to talk about architecting a little

bit more okay go on one more on architect okay i just i i've seen you talk about jeff how you're

able to evaluate the time a project will take and i would just love any sort of stories you can tell

about the mismatch between what clients think and kind of what you see and how you have that

conversation where someone comes to you with some outrageous request how do you how do you kind of

talk them down from that cliff and you know what words do you use when um they think something will

happen you know can be done in a month and you know it takes 12 months right because that that's

going to happen all the time um it doesn't uh strangely enough and i know i started the podcast

saying i don't my other consultant friends have that all the time so you're different well i mean

it's just it just is what it is i mean so let's say a client comes to us and they say we want this

really awesome service and it's something that you know has taken years years to build so let's

say somebody comes to us and they want github or something we we could say sure that's multi

multi millions of dollars to do and you know we're a small company so we don't have the you know like

the the labor or the the workers to do this thing but you can't just come in and say copy every

feature of a multi-million dollar or billion dollar startup realistically and put it up in

two weeks like it's just not going to happen. So it really depends on can we just evaluate is this

even doable? Part of it is if you come to us with a bad business model, and Frank does more of this

than I do. So I can I can make it sound like a better story. But we do discuss it as well. If

you come with us to a really bad business model, and we know that you're not going to be able to

be successful at it, or it's just a bad idea, then we want to also get paid. And so if we can't get

paid to do the work because of your bad business, then there's no reason for us to do it. We don't

want to be in the collections business. We want to be in the right applications and, you know,

do what we do. So for me, it's realistically a, you have a feature or you have an MVP. So the

site that we just finished, that's been, are we, it's going through like a beta process and stuff

where we're doing the brew pubs. Um, they had a three month deadline basically, and they knew

they have investors and these are the marks they need to hit. So if they say we need to be able to

sit down at a restaurant at 6 p.m. on a Monday, which is what they did, and order a couple of

beers or a cheeseburger, that's what we know that the goal is. So if we need to scrap other features

because the inventory management maybe doesn't matter as much because the order has to go

through. So for us, it's really a matter of prioritizing these are the features. And when

people come to us and say we want to add this other thing or an investor or somebody thinks

it'd be really cool if we could do xyz it's just reminding them of the focus and that is you you

know this is the idea you have sold this is what you need to do we can do these things but the more

things that you add the more that deadline is going to get pushed back and so i can do that i

guess without sounding like i don't know i guess i'm being a consultant as long as i have i can

tell people no and they thank me for it where when i was probably eight or ten years ago they

probably didn't thank me they thought i was being rude or maybe i didn't know how to communicate it

so maybe eight or ten years ago you might not have had the authority that you have now so that

you may i don't know i'm just sort of extrapolating from my own experience where

you you find yourself in scenarios where unrealistic deadline after unrealistic

deadline after unrealistic deadline and you're saying that this can't be done and here's why

but it's not that that's not necessarily being listened to and you know software estimation is

notoriously difficult and managers notoriously don't listen so do you think that the like so

i'm thinking specifically about this software estimation problem and like working with clients

um i mean and i guess the point i started one from was when you said eight or ten years of

you know eight or ten years ago did you find you were able to make that point or were you just

did you find yourself not listen to then um yes um so eight or ten years ago i was at the

lord's journal world and we basically i was working for one of their startups that was

basically so we i worked on ellington cms which was the first django app or actually i think it

was technically the second django app but it's the biggest at the time and so we rolled this

thing out to hundreds and hundreds of newspapers. And so I got used to unrealistic deadlines. I got

used to trying to do all-nighters, not because they pushed us to do this thing, but it just was

like self-induced pressure to do it. And then at some point, I just decided I'm not doing that.

I'm not going to stay super late. I'm not going to do all-nighters. I can tell you what I can do

realistically, because I just don't want to do it. Life is too short. So if a client wants to

fire me for not, which never happens because I won't work the weekend for them, then it's not

a good fit. And it takes a lot of privilege to be in that situation to be able to say that. But

clients tend to respect us more for that because they don't want to be, they don't want to be

stressed out because we're working on a feature an hour before they're supposed to show it,

especially if like their income is based on this, this demo being successful. Most of the time

When we deal with startups, that's a little more normal that, you know, they're kind of going from like funding round to funding round.

That's probably not most of what we do.

But, you know, I think it's kind of a trust, too, that can we deliver it when we say we're going to deliver something, we're going to do it, we're going to deliver.

And it's just a matter of what features do we need to cut out.

So I think with working on the projects like you do, you probably understand is it better to do the feature wrong or not 100% or is it better just to land the feature just to say you did it?

Well, with something like Django, it's better to just take the time it needs. It's got to be a good feature. There's no point putting in a broken feature. So if it takes longer to get in, that's fine because Django is an upstream dependency of all these end projects.

But in a commercial environment, sometimes it's like, no, this feature's just got to ship on this day because the marketing department sold it to the client before the estimation was ever done.

It strikes me as that happens all the time in software.

I mean, it's not great, obviously.

I mean, I think it's just because we're not afraid or I'm not afraid to just cut out features or cut out what we need to get it done.

but it's going to change based on their feedback and what else they need so but we're pretty up

front about it so kind of it's a if we take a project on we know it's going to be three months

can we deliver this in three months and you know we we can whittle that back and and i don't know

i don't sit down with any like task tools that measure productivity or try to figure out how to

do it uh when i look at models and kind of know can i get this mvp up in a couple of weeks and

if i can get the models done the rest you know the drf stuff it's just the tools that we deal

what they're so mature now that it's pretty easy to kind of guesstimate i guess in my mind what

it's going to take to get something at least you know plausible and passable yeah and that's the

key point about estimation right is that it's always the there's this idea this meme this trope

that software timelines aren't estimatable but with mature technology that you've and you've

done it a lot of times and yeah they kind of really are because you know oh it'll take a day

or so to put these views wrapped around this it's exactly that can you model it right and if you've

got the models and that business layer the views are a known commodity and you know what drf makes

it so easy to like there's a pattern that i've kind of grown into recently that i like where

we'll do a lot of model view sets and i'll basically take all the models and make an admin

version of it and that's gonna require like a staff or super user or something and that that's

easy and quick for us to do if you're a front-end person that's not the most useful thing if you're

writing like an admin or something for it like a javascript based admin then you know it may be a

pain but technically the job is done you can hit everything and then from there that's where we go

back to that like what's the bread and butter of your application and we'll start writing like very

particular views so you can place an order or so you can get like a full menu with all the nested

everything that you want and then that way we can work on optimizing those views but by default i do

push back on front-end people sometimes to say this isn't a very performant way of doing things

so if you just want to save an extra request don't i'll make it easy so you can do batch requests

which i would love to see in drf by the way well there's a bunch of things we can do to make lives

easier too that aren't always nested okay so the thing i'm really hoping for with the whole um

async thing the ascii and whatnot is that we can um have a way of really building simple kind of

proxy endpoints which hit you know because the natural um the natural format of a rest api is

flat right so you have one request for ingredients one for drinks one for you know whatever but the

requests that front-end developers want to make is one request fetching you know all of these and

all of those and all of those and combining them if i'm really hopeful that the async stuff will

enable us to build quick proxy endpoints that will really serve front-end developers really well

so i don't know if that's going to come in drf per se but it'll be part of the django async move i

think that's what i'm hoping oh i think that'd be great as uh somebody who does a little bit with

django con i uh think we have a few fun surprises coming up so all right so speaking of django cons

and community let's let's dive into that area and maybe we could start with uh so when when we met

at PyCon, you mentioned you were off to the Python board meeting. What's the titles for that? And

then we'll get to the Django specific stuff. So you're involved with, you're sort of like the

Django representative on Python right now? I wouldn't say that because Katie McLaughlin,

and if I said her name correctly, there's other Django people on the Python Software Foundation

board. And so a year ago at PyCon, I just, a couple of people came to me that were directors

and they said they were going to be stepping down and asked me to run.

And so I thought, sure, why not?

I really didn't think I would get on the board.

And then I think I was on a flight from Chicago coming home

and my phone blew up when I landed and apparently I'm on the board.

So I don't think they knew what they were getting

and I don't think I knew what I was getting into.

So it's been good.

It's basically a lot of meetings, a lot of email.

The Python Software Foundation is the nonprofit behind the Python language.

And so what they try to focus on is the education and the community and growing the community.

So if you have events, you can hit the PSF up for money to try to help and spread the word about Python.

I'm still new enough to it that I don't kind of have the spiel down.

So I'm still trying to learn it all.

So hopefully none of them listen and then cringe whenever they...

Well, Katie, we already interviewed her, and her interview will be coming out before yours, so that's at least one other.

Awesome.

So education, community events, are there discussions about the language itself and features, or is that handled by a separate part of the organization for Python?

So I know that's changed recently, and there's a government's board.

So they used to have a BDFL model, which doesn't really scale.

Like, one person just doesn't scale.

And so I don't know the timeline, but that recently has changed into a council, which I guess they discussed at PyCon.

So the board itself has nothing to do with the actual language as far as features and stuff goes.

When they're going to have meetups or they want to try to get all the CPython devs together to work on stuff, I think they do it like once or twice a year.

Yeah, so anything we can do to aid CPython for their meetups or their, I guess it's like

an in-person meeting they'll do a couple times a year, at least once a year.

If we can help fund that to try to get everybody together, because not everybody works for

a big corporation and can afford to go, then really anything we can do to support CPython

community and support that movement is good for Python. And that's good for Django and good for

all the projects we like to work on. Yeah, well, and so just as Python has the Python Software

Foundation, Django has the Django Software Foundation, which you are what's I know you're

part of it. Do you have a specific title as well within that these days? I'm just a I don't even

know what I am. I think I'm just a contributing member. I don't know. Carlton, do you know what

that's called dsf member i i don't know if there's categories of that there's a dsf anyone can join

the dsf by the way if you're a django user part of django community go to the um django project.com

website look for the django software foundation there's an a form you can fill in and you can not

you know apply to join this it's not like a there's an entry criteria other than

you know just that you're a real person i guess um but join that join the dsf there's a mailing

this for that which you know it's private in that only dsf members are on it but it's not private in

the sense that you can't be on it um and that's about the ds the django community and you know

there's it's not particularly high traffic so do join um i don't think there's well then there's

defna too yeah defna is something else because defna is responsible for organizing django con

am i right in that and i know you've done maybe if you want to thump your chest a little bit about

your involvement with Django cons because I know you've done a lot yeah so I guess I've been a

principal organizer for I think this is the fifth year six years something like that um

yeah I didn't even know where to start with with uh how did you get involved how did you how did

you so I mean I guess you've been working with Django forever so you how how did the ball of

organizing Django con land in your hands I went to the first Django con because I was working at

Lawrence Journal World. And I've kind of been to most of them, I've probably been to half or 75%

of them. After, after, like, everything started off as a community model, a couple of things

didn't work, I guess, out very well. And so it kind of became a commercial model, which worked

for a while, and then that didn't work out. So I just happened to go to one where things really

weren't working out at all. And so I just kind of volunteered to try to, like, make sure that,

you know, there were speakers and there was stuff going on. So I guess you could say I was the last

minute program chair with about a week or two weeks notice. And so I just, I don't mind begging

and asking people for help. So I asked a couple of people if they would speak. I think Russ spoke

like three or four times at the conference. So thank you, Russ. That was amazing. And then we

basically made sure that DjangoCon happened. Russell Keith McGee at the time was the DSF

president, he asked me if I'd be interested in maybe, you know, trying to at least get the next

DjangoCon going, even if I wasn't going to be involved with it. One of the speakers who stepped

up and really helped a lot was Craig Bruce. And so he said, if you're in, I'm in, we could maybe

create a nonprofit and start this. Stacey Hasler, who was at the time, I think the DSF, maybe

treasurer, she volunteered as well. And so the three of us started the Django Events Foundation

of North America. And our goal was just to make sure that DjangoCon US happened. And then after

that, things kind of were going a little better. Everything, you know, the community got really

behind it and was really, you know, helping us grow and do good stuff. And so, you know, when

we were just basically trying to have a conference that, you know, evened out every year, hopefully

didn't lose a bunch of money, we started taking the extra profits, putting some of that back into

the DSF, putting those back into other Django events and Python events that we feel, you know,

support the community and so that's kind of how that ball got rolling right and so and one thing

that's sort of really noticeable about the jango community is the um for one of betward outreach

you know that to make sure that um the speakers are representative and that um you know everybody

can attend or you know that it's not just not just white men in a room for one of a better phrase um

so how how did that get going or you know what's the what's the birth of that and that kind of

important stuff because for me it's one of the features of the django community that makes it

worth hanging around for so the first django con us was in santa clara and there were a couple of

women who worked at laurence journal world at least one woman worked at laurence journal world

and then a couple of the more notable people who were women in the django community were there and

it was really odd for me walking in and knowing four or five of maybe 10 women of 200 people

And so it was just a weird experience.

It was mostly white men.

And so from there, when I looked at, let's say, DjangoCon, when some of the years were going pretty well, representation wasn't very good.

Like we probably the first, and I'll just throw out a number, maybe the first nine or ten years of DjangoCon, I don't know that we had a single woman speak as a keynote speaker.

And so looking at that, whenever I was the program chair and started doing my first actual all-running DjangoCon, I wanted to make sure that we prioritized having a couple of women speak.

And so I think by the time I had my first two keynote speakers of the three, I realized these are both women, which was very intentional.

And then I was looking for recommendations for another speaker.

And so I said, you know, got this list of people that we could maybe pick from.

And I picked a couple of people that like I was, you know, fans of or friends of mine who I really thought a lot of because maybe they helped me in technology kind of get my start.

And so when we had the opportunity and I realized like this could send a really powerful message to have like three women keynote speaking.

And so it was partially by design and partially just kind of happenstance, I guess.

And once that happened, then I think it started sending kind of a message that this is a little different than your average tech conference.

We're going to prioritize something very different.

And I think it's like the Ruth Bader Ginsburg, and I'll get the quote wrong, but it was like, how many, I think somebody asked, I should probably like look this up.

It's like how many women is enough to have on the Supreme Court?

And I think she basically said all.

Like it would not be a problem because there have been all men do this thing for so long.

so you know we didn't have any rules that like xyz needs to be all men or women or people of color

what we did do is kind of look at what we've done in the past and notice and then decide that we

need that we need to kind of change the way maybe talks are picked so let's make it a community

model let's go to a blind you know type process then let's go to a double bind blind process that

way, you know, when you start taking out speaker names, and you start removing the bios from,

you know, proposals, it really changes the people at the top. So you don't always get the same

people all the time. And so we do have some people who are very spectacular. And even though it's

double blind, even though they don't put their bios in, they're always going to be the top 10

as far as reviews go, because they're really good at what they do, I guess. So, so I think changing

that emphasis was a little better and then from there we kind of learned from mistakes like you

know because we had that first year where we had three women um it was a very valid criticism that

we had three white women and so we should you know we have a lot of underrepresented people

in our community we can do a better job and we've just kind of iterated on it over the years yeah

and that's the thing is iteration isn't it it doesn't you know it's going from here to there not

uh we're terrible let's give up and and i think as far as like some of the people who are doing

amazing things in tech. You know, like I talked about Jesse Frizzell earlier, like if I get my

pick of who I want to speak at a conference, then why would I not ask Jesse Frizzell to be a keynote

speaker? And she's not this year, by the way. But, you know, there are people that are just doing

such amazing things that the people who I started following on Twitter definitely changed a lot.

And so every year when we ask for keynote speakers, we just look at who we have. And

like this year, I don't pick them. I haven't picked them in a few years, but I'll give

recommendations on, you know, maybe people that I think would be good. And we do get a lot of

white men still, but it just kind of comes down to who's going to give the right talk at the right

time. And you mentioned async earlier, like how cool would it be to have a Python async kind of

keynote for this year? So maybe that happens. Yeah. Well, so as we come to the close of this

interview, what else should we discuss? So you have, I know, a number of side projects. All three

of us are, I guess, Django developers of a certain age with kids. What should we discuss that'd be

interesting to people. So I think if I do one thing, well, I think it's driven by the idea of

the campsite rule, which is leave the campsite better than you found it. And I think that works

for relationships, that works for community projects, I think it works for clients. And

that's the one thing that I think that the more time that you spend making the campsite better,

or, you know, putting effort into making the community better, I think people who also

identify with that are also going to put their efforts into trying to do that and so if i had

any like parting wisdom it's follow the campsite rule and then the kids stuff i think is great too

if you want to talk about that or yeah whatever you guys let's talk about i mean side note we can

edit it out if we don't like it or we can include it people tend to like that stuff i mean the thing

for me with kids it's it's just about um energy levels and maintaining those and realizing that

there has to be a rhythm to life that if you don't maintain it's unsustainable and when you're young

and you can perhaps have a lion on the weekend or whatever you can maltreat yourself and somehow

get away with it but actually it has a cost which perhaps you don't notice but once you've got

youngsters because on the weekend they get up at exactly the same time as they do every night there

is no lion there is no break there is no day off so if you don't care for yourself you can't perform

and you can't perform as a parent and you can't perform at work and you can't keep going not just

this week or this month but all year and all next year and for the next 20 years when they

they're going to need you um and so for me it's a that that's this kind of lesson professional

lesson i learned as a parent was about self-care and the priority of self-care and it's much more

important than some project deadline that's fake and all the rest of it that was that would be

where i would begin well i would say i mean to make an analogy too it carries over into into

projects and coding so all the things that you know you need to do you know stay up to date with

django add tests you just have enough experience where you go i'm going to prioritize that over

maybe this new feature or this rush deadline because you just know how it's going to play

out and you've seen the record play and you know again hopefully this is wisdom and you know it

ultimately, it just makes you more, it does make you more efficient. I think maybe the challenge

is that it's can be hard to communicate that efficiency to someone else who doesn't have that

knowledge. But it's certainly I mean, I feel like I'm every year, I'm a better Django developer,

and it has nothing to do with the number of hours I put in. But it has a lot to do with to your

point, Jeff, initially of knowing what to say no about, and having that framework for making

decisions about, um, you know, personal time and then also professional time.

I think I've learned that if I'm not going to say yes to something that I can't put

the energy in to do it. So I'm either going to be all in or I'm going to be all out. Like I don't,

I don't like the middle on that. Maybe my kid has taught me that a little bit. Cause my kid

just does not care. My kid doesn't care if I have a deadline, you know, he's happy to come to my,

you know computer he loves like amazon echoes and alexas so he will point and say bus and that's

really all he cares about is he wants to hear wills on the bus um he just doesn't care about

deadlines and so there's just something about that that i definitely and i i guess i'm the

only person here with just a kid you all have multiple kids which is just i don't even know

how you do it well one at a time the energy stuff you're absolutely right about and i think it's

because my kid doesn't care if i'm tired let's go outside let's do these things and so um that's

that's kind of nice actually but yeah it's a good slap across the face of perspective on a

24 7 basis which uh well i think it's helped me too because i know there's this idea of like flow

and you know you're in flow and you know kids just again they don't care about flow and so

I've had to kind of learn that I need to be more concise and if I do like if he has taken a nap

maybe that's an hour maybe that's two hours but it definitely changes that I've got two hours

whether I'm going to do something around the house or laundry or whatever I definitely approach it

very differently and to me it's not an art what we do it's it's a job so I don't really worry

about like writer's block or coding block or plumber's block you know there's it's just I've

got this amount of time, I'm either going to get this done, or I'm not going to get this done. And

so I kind of pick and choose what I'm going to work on, if I have the luxury of working on

something based on what I think I have available in that time. So I, that's the one lesson about

having a kid that was amazing for me is that, you know, flow is just non existent when you're a

parent, I feel like, yeah, well, you're just so deliberate and focused when you have the chance

to be that you can't entertain thoughts of, I mean, it's sort of like, sometimes you'll see

people on youtube with their morning routines and their evening routines and you know uh people

will fill the space that they have uh but kids fill the space for you so when you do have those

gaps you say right i'm you know i can get a lot done in 20 minutes actually on this coding thing

if i have to as well like yeah and it's just that well sorry um no go ahead as well the the thing

if you spend time with your kid you call you know you're spending time with a kid you you're right

brain your creative bit of your brain is busy working on the problem that you couldn't solve

anyway and you come back to the computer later on and you've got that 20 minutes say and it's like

yeah there's a solution for you and that was kind of free work in a way because you didn't have to

sit at the computer laboring for it you were playing with your kid and it's like ah you know

the life pays you back for being present and it's like thank you well i think maybe we could end on

that one carlton well said jeff thank you that's awesome thanks for coming on the show and uh thank

you all for listening as ever if you've got any questions you can find us as uh chat django on

twitter and we're at django chat.com all right bye-bye bye