Transcript: DjangoCon US 2023 - Drew Winstel

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

And we're very pleased to have Drew Winstall join us this week.

Welcome, Drew.

Carlton, how are you gentlemen doing?

Happy to happy to be doing a podcast.

It's always a good morning when that's happening.

So as

always, thanks for having me on.

But maybe before we get into all that, um what's your quick quick background, and then we're a lot of areas we want to cover about Django and other things.

Well, I got started, um, you know, usual like nerdy grade school kid, um, had Apple IIEs in the computer lab, then Mac, and um learned some Apple Basic along the way.

Got my first uh computer desktop computer at home in the mid-90s, did a bunch of Q Basic and you know fun stuff like that on there.

Learned some C got some got a book on C or C back when I was in middle school.

Didn't really take too much at that point.

Then in college, I um majored in electrical and wireless engineering at Auburn University.

Um had it, you know, so it wasn't a CS major as such, but a lot of CS adjacent stuff had classes in C, x86 assembly, um, C.

All the professors assumed we knew MATLAB, none of us did.

You know how that goes.

If you if you could do diodes, you can do MATLAB.

Like if someone's like an EE or an you know at MIT like Eeks or something, you know, that's that's like, ooh, like that's kind of the pinnacle.

It's like, oh, computer science.

Well, you don't really know how these binary gates work, do you?

At least, you know.

But uh yeah, and so while I was at there at Auburn, actually one of the first people I met there was Lacey Williams Henschel, who chaired uh DjangoCon US back in 2017 at Spokane.

And uh she and our friends through all the Honors College stuff there.

And Weird Small World thing, he had a college of 25,000 people.

She actually knew my wife back in then for doing um all the English major, English major stuff together because they were both English majors.

And then um, yeah, so then we've got then we Lacey and I reconnected on um Twitter back in the early 2010s, started chatting through there, and then when I was working at an IoT shop here in Huntsville, Alabama, where I'm based, um my we were it's a Python shop where all they were actually run a little embedded uh chip that runs um Python on the device itself, a subset, not quite microPython, but a similar idea to it.

And um they um we're looking for a something to run on the back end that ran Python, set up a little REST API, and one of the guys suggested uh Django and so set up a DRF back end for that.

Uh the front end ran um Angular JS back in the day and uh leaflet to do a little mapping thing.

And that's where I got started with it.

Shortly thereafter the um that uh project got shut down and I got laid off uh while my wife was pregnant, uh appropriately enough.

Right, yeah, good.

So quickly found a job.

Oh, totally.

Quickly found a job with um actually one of the guys in my homebrew class, or not homebrew class, homebrew club rather.

And um not the

Yes, homebrew.

So we're gonna put that on the side.

We'll come back to that in a moment.

You finish this and then we'll come back to that.

Brilliant.

So yeah, um all right, so went to the little shop that is uh remote lighting management, and they had a homegrown lamp stack.

Um, you know, it's very clearly written by a computer science person uh by an intellectual engineer, not a computer science person.

Um he um so yeah, I took that, I rewrote the stack and um made a DRF backend, uh DRF gateway to the remote devices, and um uh the other developer wrote a um React front end for it.

And so that was uh complete ground up rewrite, very nice.

And and the process of that, I wrote uh gave a talk at DjangoCon US 2001 talking about the pitfalls I had on that.

And I think we're gonna link to that talk in the show notes so you can see some of that.

Nice, thanks.

And the Enterprise API through historical accident runs on Flask and SQL Alchemy.

Because I think like quite quite a bit of scale, especially with the API that you all deal with.

cache it, right?

It doesn't change too often, or am I?

Um use Elasticsearch to handle a lot of the database that would be database load for hand for the searching itself, because you know, it's MySQL as the back end database, and so if you look at it the wrong way, things go south with it.

Save some money, ground up re-rewrite.

Yeah.

I've been through one ground up rewrite, what's another one?

Yeah.

Yeah, and so um, and the process of uh you know the j going at DjangoCon US 17 in Spokane where I first saw Lacey again for the first time.

That was a great time, got to meet a whole bunch of people.

Um, that was where the uh venue had some trouble getting people into their rooms, and so I was sitting out in the lobby and met people like uh Kaden McLaughlin, uh Russell Keith McGee, just a whole bunch of people sitting out the hallway and just you know, like these people who are like, oh hey, I've seen your name and things, but I have no idea who you are, and now oh hey, you're just cool people.

And it was a lot of fun, got to meet some awesome people, and then I talked in 18, and then um Jessica Deaton, aka Deats, uh recruited me to be an organizer for 2019.

And I was like, hey, where can I help out?

And uh I got put as opp in the opportunity grants uh group the group, took over as chair there, ran that.

Then 2020 the pandemic hit, and so that got cancelled.

2021 was pretty much just the board running the show for the little online conference, and so I ran program for that.

2022 came back to the in-person conference and uh back in San Diego one more time.

It was a lot of fun.

We had a bit of a skeleton crew running it, so I was running program, opportunity grants, and also effectively co-chair of the conference.

We have talking with Jeff Triplett in the past, is that you know you show up to a DjangoCon event, and maybe unlike other ones, it's not professional organizers, it's volunteers.

It's all volunteers.

They're not just hanging out in the hallway because they can't.

Um but it's right.

That's why we have these events, and especially when I was on the board the past three years, sort of see the inside of how much, you know, what a lift it is on on the volunteers who make DjangoCon US and DjangoCon Europe happen.

It's it's you know, it's an incredible incredible service to the community.

So I hope people are aware of it.

Oh totally.

So the first conference, everything is so new and um doesn't really hit in.

And so and as you both saw, we did I did the um call for volunteers as during the opening remarks on that Tuesday of the conference.

Got a great response from that.

We had a bunch of people sign up, and so right now, I think at the we had our first weekly organizer meetup last week and had somewhere in the neighborhood of 25 20 to 25 people show up for that.

So already a huge improvement.

And uh Jeff is trying to take more of an advisory role this year, and we're hoping that he can actually do that and not be involved in the nitty-gritty of everything again like he was last year.

Because that's something that I don't know if everyone's aware of that, you know, because it is expensive to go if your company doesn't help you pay.

Um but can you talk a little bit?

Yeah, definitely how those work.

So what happens is we'll this will be actually going live likely this week.

Uh both the call for proposals and the opportunity grants will open up.

And um, so what we're going to do, what happens is there's a form that gets posted out on the speaking page and over social media and everything.

It's just a Google form you fill out, talk about who you are, uh, what excites you about DjangoCon.

Is this your first time coming?

Are you speaking at DjangoCon?

Just some basic questions to try and get a feel for why you want to come to DjangoCon, why you should get money.

And then um we'll give you up to, you know, a little bit of money, somewhere up to, I think it depends on your case, whether you're traveling from the US or overseas, there's a travel budget maximum.

Help out with airfare, hotel, uh, food costs, so that and visa fees if you're coming from overseas to help out with um help alleviate the cost of coming to DjangoCon because it is a big outlay, especially given you know current fuel prices, things are going to be expensive to fly there.

I think my just looking at uh Google Flights yesterday, it looks like my f possible flight to Durham from Alabama is gonna be more than my flight to San Diego was last year.

Huh.

It's also the case, I mean just with on airline flights that you know if you're on one of these like because I'm in Boston, it's like way cheaper to fly all the way across the country than anywhere, you know, in between just because of like popular routes.

But yeah.

Anyways people should and historically if you if you give a if you uh propose a talk and it's accepted um you also um you don't have to um uh pay for the conference and then there's also uh if you need a chance for opportunity grants so an a plug to put in for a tank.

And then separate from that also is we have a $500 travel reimbursement that all speakers are eligible for even if they don't apply for opportunity grants.

So if you're so if you know your company's paying for part of it you can use the $500 to cover the gap and then you're good to go.

Or if you need more than that you can apply for the opportunity grant on top of the $500.

And so yes please submit talks.

Please submit

Um great

Basically we just have a few HTML related things to finish up on the actual the page itself and then once that's done it'll go live and it'll run through May 15th.

Yeah good

Could you briefly just talk about how DEFNA works

And so DEFNA and the DSF signed a contract where the Jen where DEFNA runs DjangoCon US so each year we submit you know here's when we're trying to do DjangoCon the DSF approves a date make sure there's no major conflicts with other national other Django cons or um religious holidays or things like that.

And so then we get together with we know we run um everything from get the call for proposals, venue solicitations, website design solicitations, um, and then maintain a doc well documentation of how to run DjangoCon year in, year out.

So that way we can, as we cycle through volunteers, we can help maintain some continuity and get a uh solid base under it and then hopefully get a more sustainable VIP base as the years go on.

But it like there's times where it's been like hang on who's going to run it next and then the that bit about passing on the knowledge, codifying the knowledge and passing it on, I just think that's monstrously valuable and you know something that right

We spent so much we on the we on the board spent so much time on this during

I wish you know can we you know can we get under the umbrella of you know Python or another thing but it it is it it it's it's um we didn't we haven't figured out a solution in Python like the PSF we always ask them for help.

I mean they're having a transition in leadership there isn't an easy solution that we're aware of um on the legal side and then the separate bit that DEFNA because it's been running and runs well has its has a little um leftover money like it donates a huge amount back to Django itself but it does have some reserve funds.

So for example it was able to absorb the cost during um during COVID of having to eat some bills there is no equivalent in DjangoCon Europe.

So then it's

Yeah solid five figures right

So that you know that's you know what is it eight six months out eight months out I can't do math eight months out and we're forking over something like fifty thousand dollars for it.

You know I think when I stepped down it was something like 200,000 total which is about a year's running run rate.

So um anyways yeah shout out to Jeff Triplett for being the lead on all that I know along with other Deaf Nut people but Jeff's Jeff spent a lot of time on that.

I think there's two aspects to it one is the legal body like can we do that in Europe?

I don't know you've obviously looked into it it's difficult but that the second bit is that kind of codifying the knowledge aspect if we can if we we you don't need we don't need a legal body to do that.

I think that's something that I don't know where is the run the run book for DjangoCon Europe.

I think we that's something that we could work on.

So I know when we had um so there are people still who kind of remember from five six years ago and have been called upon to help with the organizers this year but um it's it's a lot.

And I think it's also it's it's more complicated because it's not the same country right so all the some of the things that are um yeah if anyone wants to set up a duff you know a Daphna Europe uh we sh we we could use it.

Yes yeah tell us

Okay wow which is kind of nice called the Rocket the club is called the uh Rocket City Brewers Rocket City because Huntsville has NASA Marshall Space Center and lot you know Ferner von Braun and all of that so lots of space influence around here.

Because like so I'm up I'm from Vermont and you know so you know east East Coast style IPAs you know so the West Coast had these strong IPAs and now there's a New England IPA and like but what's it's it's warmer where you are so it may not want like an eight eight percent thing but I don't know what's what yeah what's popular down your way

My personal choice is like what I'm brewing, if I'm just brewing something for me, it's about a six to six and a half percent West Coast IPA.

Nothing too heavy, but still enough that you can enjoy some good, like strong, like piney, you have sometimes piney, sometimes citrusy hops in there.

Um but also a lot of the uh I've seen a bunch of these really good double IPA makers around here are making, you know, like four or five percent versions.

Like I can't have more than like like if I have two eight percents, I'm just wrecked.

So um, anyways, there's there's starting to be, you know, it's like you know, gradually softening up uh the beer.

You know, I was even I was talking to someone the other day about some video game, and all these games now have um like casual mode.

So there's like, oh, like hard mode, and then there's literally just like, you know what?

Like, I don't care if it's a shooting game or just an adventure game.

I just want to like chill and be like only moderately challenged.

And I love that like so all these games I play now have like a casual, like don't die.

Because like what you know, anyway, so I'm embracing getting older, right, Carlton?

Yeah, no,

I'm laughing because I'm just like we've just turned into old men now.

It's like, yeah, I've I have hardly.

I'm not ups.

Like I'm happy about it.

Oh no.

You just like all these things that you had time to worry and energy about before, you're just like, well, that's gone.

So, you know.

Anyway, sorry.

I have one

I have this imagination of um like Homer Simpson with a still that's sort of in the get in the basement that explodes as he's trying to, but that's a different kind of brewing, right?

That's a

Right, okay, that's okay.

You don't do that, but uh yeah, so my setup is uh big metal tank for uh doing the actual boil process.

You yeah uh start with a couple of uh actually 10 quart, that's what 38 liters um coolers that um I s actually uh do the what's called the mash, where you take your crushed up grains, barley, uh roasted to various temperatures and things like that to um give the flavor and color.

Steep the hot water in there for an hour, that then you rinse it with more hot water to flush all the rest of the uh sugars out.

That goes into a boil kettle where um boil it for about for an hour, adding in hops as you go along to um decide to make it how much bitter or how much hoppy flavor you want, depending on how long the hops are in the boil.

Longer boil means more bitterness but less flavor and vice versa.

Then cool it down, um add it at the yeast, uh, put and put it into a um a fermentation vessel, which can either be like a glass carboy, so you know, a glass tank that's about I don't know why I'm making signs making hand potions right now.

A podcast is a visual medium.

It's about screen height.

Yeah.

Uh five-gallon um glass jug or uh plastic bucket that uh you let that ferment for a couple of weeks.

Um then you can uh sh uh either bottle it or keg it and let it carbonate and drink it.

So you got you've got a shift.

Okay, pretty.

You can you can be faster if you hire things up or it can be longer, depending if it's a higher gravity batch.

You know, there's like what's what's your sort of time frame?

Like I've gotten some pretty good like micro beers up in Vermont, and you know, you if you don't drink them within like two weeks, they really fall off.

Um so that's one of the things that makes those, you know, if they're not super fresh, they'll fade within and they're not stored well, they'll fade within a couple weeks easily.

Your less hoppy stuff and higher higher alcohol stuff like your Imperial Stouts, your um Imperial Porters, um, those you can age for years if they're if they're um actually prepared right, where so you purge all the oxygen out of them before you bottle or can them.

I mean, I've got some beers in my fridge from 2015 that are still drinking very pretty.

I might mostly because you've managed to hold off that long.

I couldn't do that by myself.

Yeah, yeah,

Well well, there is uh there's this, I'll just maybe I'll put it in the notes if anyone cares.

There's a really interesting book that came out last year called uh drunk um about the history of alcohol and like why people have been doing this for forever.

And one of the interesting points was that the um distillation is quite new.

It used to be back in the day, because like back in the day, everyone just drank beer because you couldn't drink the water, so they were all kind of drunk all the time.

You know, that's why caffeine helped, because then they weren't drunk, but it was only two, three percent.

Um, you kind of couldn't get drunk that like drunk drunk, but now with distillation, you know, you can get drunk super fast, and it's almost like humans haven't culturally or are biologically caught up with with that.

But that's that's probably enough about alcohol.

That's what we should also mention one of the great things about Django Cons is there's absolutely no pressure around drinking, bars, all the events are um explicitly, not not directly about that, um, because that can be a thing at tech conferences, and so that's one of the things I like about Django Cons.

Yeah.

We have Slack channels for outings in our attendee Slack where you can say, hey, I want to go get food or I want to go get ice cream or coffee or whatever, and people just kind of self-organize into groups.

Uh Tim Schilling, one of our new board members this year and on DEFNA, um, he gave a tutorial last year and um just basically stood outside the entrance to the hotel and just waited for people to start forming groups and found a different group each night and had a grand old time uh meeting new people and trying different things.

And that's a really great way to meet new people, which actually leaves into how I got into Noun Project, because um at DjangoCon US uh 2019 back in San Diego, I was getting a group together to go to one of the the many breweries that San Diego has on hand, and uh Joseph Cochrans, uh who was the CTO at the time, actually drove down from at Los Angeles, and so he had he's like, I've got a car, I can drive a few people.

And so we drove over to uh North Park, the area which has a bunch of breweries over there, went to a couple of those, and um had a go had some great food, great beers together, and then um a few months later, um feb mar February 2020, I was looking for a new job, and uh Jeff Triplett actually reconnected me with Joseph and uh he's like, Oh hey, I remember you, interviewed, and then landed the job and was supposed to fly to Los Angeles to meet the new team in March of 2020.

Right.

That's wonderful.

Yeah, sure.

Absolutely, yeah.

There are two back engine engineers, myself and one other person, and um three front engineers right now with the hiring trying to hire a fourth one.

Um that are we are doing uh we yeah, we'd do um uh new pro trying to implement new features.

Right now we're working on um user-generated photo uploads, so they can because we sell both icons and stock photos, and so trying to expand our photo library a bit more.

And so that way we can, you know, start selling subscriptions to the photos and they can, you know, not just buy one-off photos, but actually get like, hey, here's X amount of money for X photos per month type of thing to help increase our steady subscriber base and bring in more revenues.

Um we the back end we have an enterprise API that big name customers like Adobe use to um fetch lots of icons at a time that will help us with um that they use to um you know offer to their own customers like some editing type things.

I'm not entirely sure what their use cases are for it, but like logo builders, uh uh various design and print services, they like yet they'll actually like search, you know, they'll do their queries on their end and actually search our icon library for the icons, and then they can, you know, they can use a block list to deny certain words that they or deny explicit icons if things that they don't want those, for example.

And uh so that gives them uh the fancy way to basically put our stuff forward and use it for things like say building this t-shirt that I'm wearing, which has a uh dumpster fire icon on it.

This was one that would be actually sold in our company store last uh yeah.

I was like, you've overcooked your toaster.

Well, yep.

So um merch.

So Django has a merchandise store, which is up and does have sales.

Uh, you know, I always see like Carlton was wearing his GitHub hoodie earlier, you know, felt you know, Marius has one, some people have one.

I would somehow I would love to figure out how we Django have like like a really nice hoodie that like we go to a Django con and people are wearing Django stuff.

Like if maybe if a listener knows, I know this is something companies can do, but it's something that we don't want just printed, we don't want what we have now where we have like um I forget which I forget which service we use, but thread threadless, which is threadless is great.

Like I I got the if you get a lot of things.

They're quite good.

I've bought a few of them and they last a long time.

They don't lose their shape.

Um, so I do recommend them.

Well done, well done.

But there is, I think there's there's probably a level up just in terms of design and stuff that um we could do on uh a sweatshirts.

So if anyone knows, I would love I would love to go to DjangoCon and see a little more Django stuff as opposed to

One thing we've got to think about as well.

I mean, just from someone who lives in Europe's point of view, is like getting them made up in Europe as well as made up in the States because shipping them shipping them into Europe becomes like you pay the external tariff, you pay the rest.

Whereas if we can get them produced here, it's a lot cheaper to your door.

Enamel pins and socks.

I want socks.

Socks are my favorite.

We could have that.

Yeah.

Oh, why not?

Um, all right, okay, yeah.

Uh well, one of the questions I wanted to ask you or just about Down Project is right with all the open AI stuff, how does that change or what's the internal discussion around, you know, images and all these things happening?

So even if they were trying to do it, it's a different plane of competition, so to speak.

But I mean, yeah, obviously we're taking we're watching the very the space very closely.

Um, especially I think uh Getty's suing stable diffusion over um over copyright infringement with and because you know they can that uh stable stable diffusion can um uh generate uh the Getty image wordmark pretty well because you can so you can tell that was very much used in this training data, for example.

And there's a whole bunch of whole litany of questions regarding um uh like diversity, um inclusion within the training sets, uh is it a representative sample of the population at large?

Does it i are there biases in there?

Because I mean, at the end of the day, the algorithm puts out the biases that you put into it.

And so that, you know, as a company that focuses heavily on DE on DEI, that's something that we just you know can't do per se because we need that human touch to it.

Right.

Um and

I mean, remember uh Microsoft Tay from a few years ago?

And it's like all these things too, like all these things are you know racist too, because like you know, there's a lot of racist things out there, and you know, it's like no wonder these tools are trained that way because look look what's going into them.

But yeah, anyways.

Exactly.

It's it's become a bit of a curse, is folks commenting on GitHub issues with just like um chat GPT generated nonsense.

And it's just like happening all the time.

And it's like, really?

Does that and it it's like please don't do this, please just like don't even bother posting that stuff.

Like, yeah, if you want to use it as a research tool or whatever, but don't like there was one on I don't know, Andrew Godwin's got this new um API framework, and somebody asked a question well, what's the difference between DRF and Ninja and um Hatchway?

It's called, I think.

And um Andrew's like, well, I don't and someone's just posted this thing about um fast API, and it's like, but this is totally useless.

Like it's it's like a and then again on Django, this has happened a number of times.

We've had to block users, and it's just oh is this is this what the internet's becoming now?

Yeah, yeah, yeah.

You know, I'm you know, I've um played with these tools and they're quite useful.

Um, you know, the co-pilot is quite useful, particularly for writing tests.

It's you know, oh

Oh yet, and there's this other sort of noise.

So I'm a bit like ah I'm having that frustrating this week.

Then you bought you brought up the topic.

Sorry, that's my little rant.

Well, there's I mean, there is actually this um there is a uh class action lawsuit about um both image and then also GitHub co-pilot.

Um, Matthew Butterick is doing because you know, for example, like Django, Django's open source, and we have a software license, and you can type in things and get Django source code back to you that they're charging for, which um I've had this argument with um IP lawyer friends, and I'm like, if that's not an infringement, I don't know what is, but what is you know, what is the DSF gonna do?

What you know, even if they're even if they're wrong, they're Microsoft and they're gonna win.

Um so I think people don't understand Python, even Python.

Python's tiny, you know, like they the Python can't go up against Microsoft in a lawsuit.

So um, you know, terms of

So, you know, it'll be interesting to see where where it plays out.

I'm glad there's some sort of class action just to sort of get at these legal questions which haven't been resolved because it's you know not going to come from open source projects, they're not gonna be able to pursue it.

Absolutely not.

Probably Simon Wilson must have might have quoted it.

That's not definitely, but that's probably where I saw it on his blog.

But um, someone was comparing these kind of tools to like chat GTPGPT to um like spellcheck.

When you first started using spell check, I was like, no, you have to learn how to spell.

But of course it frees you up to just write without worrying too much about your spelling.

And the the argument being made in this piece was like it's a good um, you know, starter to get some words down on the page, which clearly aren't perfect, but then the editing process and the refinement of it and the turning into actual uh you know text that's worthy of presenting is the creative work where you might find the the barrier of those first few words, a block.

I don't know whether that's convincing or not, but it was an interesting take that I hadn't considered.

Of course, it's not really autocomplete, but in the same way that you know we have autocomplete and Visual Studio Code and all these things, it's um but it's more than that because it's it's it is what it's trained on, right?

So it's it's not just

Yes.

I mean, even it's I mean, all this stuff is already the question is does it enhance people or replace people?

So like I just visiting the a friend of mine is a radiologist.

Radiologists, pathologists, you know, these are doctors looking at images.

They already, everyone uses these tools that look at a scan and say, hey, the computer thinks you should look here, here, and here.

And then a human, you know, confirms.

Um, but over time, you know, they probably won't get replaced because they have degrees and regulations, but there's so many other things that's like, ooh, you know, maybe

Like, I mean, I saw one where they were looking at for skin lesions and um they detect accidentally created a ruler detector because the images with rulers tended to be malignant, where the ones without tended to be benign.

Right.

And, you know, so getting the data sets, getting, you know, however thousands, millions of approved things to train on, you know, they will get those eventually.

And then once they do, then it's um, you know, they'll to me it seems like there'll be places where there's regulation, like in medicine, where everyone will be happy because they charge the same amount, you know, they they'll they'll pay the fee because if a doctor can do 20 instead of 10 an hour for the same amount of money, that's a win.

But there's all these other areas where if you can just get rid of the people, 90% is good enough.

Um, so you know, like programmers, we don't have a union.

So Okay, but I've been I didn't know.

Like it you can probably get part of the way there.

Like the I've been thinking about this a long time.

Like, if you're a programmer, if to be replaced by a co-creation tool, well, you just go up an abstraction level and drive the co-creation tool, program the co-creation tool.

Like it's not I don't really worry that computers are going to be generating all our software because there's so many design problems or so many, you know, usability problems, or so many, you know, areas where a kind of human's creativity will always be able to be deployed that you know if they can write my DRF endpoints, well, fantastic, because I'm a bit bored of doing it.

You know, to exaggerate.

Have you seen this?

There's a new job description, prompt engineer.

Right, okay, so what's that?

Have you seen this?

This is a real thing.

Yeah.

Like Drew, have you you've read about this as well?

I've seen it.

Okay, but your chat GPT foo.

You need someone who can craft a prompt, get an output, but then evaluate the prompt.

And so that is going up a level of abstraction, but they still need to have the capacity to evaluate the output.

It's not just trusting it, right?

I mean, this is I think in a way what you were you were saying.

So the question is how do you train yourself to evaluate you know prompt responses given that it's gonna be bigger than maybe your, you know, where's that expertise?

It's like, okay, I'm focused on one on DRF endpoints, but now if I'm a prompt engineer, I can do all this stuff.

How do I catch up to the point where I can adequately evaluate it because this uh the scope should be larger than if I'm handcrafting it myself?

I don't know the answer, but

Yes.

Right?

But yes, we were talking about that.

And the reason why I like those tests is because they tell me when I broke something that you know I I I left a I don't know, I left a colon somewhere in a model file such and I didn't catch it, and I run the test suite and all my tests fail.

And it's like it's clearly that I've you know it just shows when something's radically wrong, even though those tests.

But I don't really enjoy writing those tests, so to speak.

But I can write a class which will go through the URL conf and you know, check, you know, write some standard tests for all of those, and then I can run that, and that's that's to go up an abstraction level.

That's to do something a bit more that's not as labor-intensive as, oh, did I do it for this endpoint, did I do it for that endpoint, did I do it for this endpoint, which can get a bit boring, right?

It can get a bit like, oh, I can't be bothered.

Right?

Because he gets it parachuted into code bases and it's like, oh, I can't touch anything.

So yeah, right.

It is.

The answer is usually no.

Let's get your take.

Carlton I bang on about this.

I mean, uh my quick take is that tests are confusing, and then you kind of get how you do it, and then it's really monotonous, but you still need to do it.

Um, like what what's your philosophy on tests, and then how, you know, at the Down project, how do you, you know, in the real world implement, you know, where these ideas of like 100% code coverage and stuff uh generally don't apply?

So, you know, we have to focus our energy based on where it has the most rewards, which is focusing on the two on basically two levels.

One the business logic, like our test, our low-code pro code code flows to make sure that people can buy icons, people can buy um photos, people can subscribe, that those that those code flows work, you know, you ha and you handle uh the most common error case as well.

So that way when things break, they don't actually cause a 500 for the user.

So you gotta check those things first and foremost, and then on top of that, just you know, do a basic quick and easy happy path and obvious error path check for the um whatever API, uh GraphQL APIs you expose to the users.

So that way so the client so that the client, at least if they're doing things, not doing intentionally trying to break things, won't actually break things.

So focus on breakage first, and then um once you get a solid base in there, then you can work on speed, um all the little the polish around the edges type of thing.

Do you use like um Selenium or playwright or something like that for that kind of um site process?

She runs through all those and uh makes sure nothing broke and um does a great job of staying on top of that and making sure that everything doesn't work like it does.

So you know the tests I write are all focused within the Django unit test framework.

And then we have the unit the uh playwright set uh suite on top of that.

It's it takes hard to it's hard to write, it can be fragile because you know you you move a selector and all of a sudden the test breaks, but they really do cap they cover an awful lot of functionality with very few tests, and you know they the smoke for smoke tests, they tell you what broke that something broke.

That doesn't pin it to, oh do you know what it was this parameter to that function, but super helpful.

Okay, good.

And then our Flaska code base uses PyTest.

Okay.

Uh I don't love PyTest.

I know people do and like will die on that hill, but I feel like here's my old man take away.

We're gonna get my I can I feel like you can get a you can get a long way with just just Django, just Django tests.

Um, but you know, it is the difference between smaller, solo, small team projects and larger projects.

I'm trying to preempt.

That's that's my controversial take of the episode.

Where did the fixture for this test come from?

Whereas when you've got a unit test class where you've got the setup date data at the top, and it might be slightly more repetitive, but okay, dry in your code, but repeat yourself in your test because you want to be able to open that test class and read the test class from top to bottom and know exactly what's going on.

There's a there's a there's something important about that.

Um you know now

There, I mean it's just

You're gonna fall.

Why do we need anything else?

I'd have to track it down, I'm sure it's still there.

And every time I've come across that, which every couple of years, I'm like, I don't agree with that.

I think that's just wrong.

You're not the only one though.

Like, no, URLs.py for the win.

And someone's like, I don't use apps at all.

Yeah.

Um our URL conf is mostly pretty straightforward, nothing too uh fancy with that except we have a couple of things, you know, a couple things behind an if settings.debug checked in there.

Okay.

But aside from that, pretty much everything else is straightforward, just a whole giant list of URL con URL patterns.

Is where if you get a new new Django code base, where'd you go first?

And I always say that URLs are part.

Will often said the the models file, for you know, you can see the reasons.

Where you get a new new um, if you get a new project or new thing, what do you check out first to kind of get to learn that?

First thing I check is to see the um is to check actually the settings and see how do they have this structure.

Do you have a separate production versus production production versus local configuration?

Do they have their code going up into apps?

How much custom how much are they trying to do from your from say environment variables versus reading from a settings file?

You know, things like that.

Okay, good,

I like that.

I saw that, yes.

Like how how is all the work that the fellows are doing in the community like in the real world, right?

Because I know in the real world companies are just almost always, you know, versions behind just because that's the business imperative.

Um how does Noun Project stack up?

I have code written to port to 4.1 that that works.

It it it just you know OpenGraining 4.1 just worked.

The only reason we haven't deployed it yet is we're waiting for the uh test engineer to come back from maternity leave, so take a bit of thorough dog tire kicking first.

And what what version of Python?

The reason we haven't gone any higher than that right now is because we use uh PyTy type for type checking, and that does not work very well on Python 3.10 yet.

At least get the combination of the libraries we use plus that.

There there's some breakage involved that I haven't fully had time to di digest yet.

So maybe switching type checkers, I maybe doing a whole bunch of um dick um excavation there, I'm not sure yet.

That's just one of the things I need time for that.

And do

So you use a library that's perhaps not compatible with 310 and you or you know got little neaks.

Do you do you uh do you find that there's time in your week to make a patch and push it upstream?

So hey, it was well listed right in there and applied that fix and ta-da, we're back to normal.

We and actually got slightly faster as a result of that.

Yeah.

So I mean most of the time we're far enough behind the leading edge that that doesn't necessarily affect us too much.

But so I actually did submit a PR to Django way back when for um trying to improve the MySQL inspect DB command that kind of got lent lost in the shuffle, and I'm not sure where that is right now.

I need to look back and figure what that is.

I I can only ever apologize to people when they get sort of lost in the gap and it's like, oh, it needs a review and it happens.

You know, we've got quite a lot of stuff.

They did the I will say when you when you um that that phrase you just used, when you're far enough behind the leading edge, it's a good place to be where you sort of by the time you hit the issues, they've been there's a workaround found and you can just roll along with it.

Yes, exactly.

Yeah, and then upgrading to 4.2, we can't probably can't do immediately because of the um increase in MySQL minimum version.

We're on still on AWS managed 5.7.

So we need to upgrade to 8.0 before we can um do that, uh, before we can upgrade to Django 4.2.

Yeah, okay.

So that's not like a major deal anyway.

We gotta we that's not our radar, we have to do it.

Like you've got real deployed code base.

It's like we're we're looking at well, which versions we try and maintain and and which do we drop when?

And it's well, okay, this one now is reaching end of life, okay.

We can drop that.

I think this is Marsh's um take on that.

Um deployment.

How how is uh wait, did you want to say something, Carlton?

I'm not even gonna mention anything on your end.

I'm just asking Drew this week.

Yeah, yeah, cool.

Um how how is it all how is it structured?

It's just running through the it's just all done through AWS code build.

It's really straightforward, and uh use Terraform for the actual infrastructure as such, defining the infrastructure.

That's you know, Terraform and Code Build and you know automate pipelines.

But uh But no, it's uh yeah, Joseph when he was there did a lot of this, and then we our Robert or other back engineer has done a lot with it too.

So we it's a pretty well set uh uh set there, so we don't have to worry too much about deployments going haywire.

It's mostly just type deploy production and go, and then sit and wait 20 minutes for while it does the roll-in, roll out, uh slighting deploy.

It builds yeah, the AWS builds the images separately on each environment.

Okay, cool.

I'm I've just I've I'm giving a um keynote in um PyCon Italia in May.

Yes, so I'm now I'm learning I'm doing three months of Italian before I go.

So uh current current project is to pick up a pick up a bit of Italian.

So my I went to France recently.

Well value.

I only started a couple of days ago.

Give me a break.

I went to France um re recently, and my French is now adequate.

Uh it's not great by any stress.

Yeah, nearly coming up for some.

Yeah, I've just gotten started.

No, carry on.

Literally, like just a little bit.

Yeah, it is.

It's like well,

Are you doing French?

Uh yeah, for me, I I took Spanish through high school and then I um studied abroad in Madrid for summer of seven of oh six um through the uh Vodafone US Foundation.

And so they paid for my scholarship in the wireless engineering program.

And so um that spent six weeks in Madrid doing some computation research and uh and uh living in Madrid and being immersed in life, so it was great.

And um so actually my wife and I are going to uh Spain in July to celebrate our 15th wedding anniversary.

Fantastic.

And so yeah, Carlton, I'll be talking to you about this as we get closer.

Totally.

Yes, and so I've been and so I just I was pr basically fluent in that back then, so I just picked up Duolingo Gan to try and you know refresh myself.

And I'm at this weird point where I like 99% of the stuff I know and I just update to this is like, oh hey, I already know this, and then by but it's like okay, how do I get forward to the next level and keep going and keep going?

Because I'm at and cause it's like I can't and so it's like okay, just click through and says the next level, next level, next level, next level.

And so I'm at that we I'm like at the weird point where I know enough, but not quite the what the way they know it too.

So it's like the different vocabulary and also getting extremely frustrated at the fact that duo does not use vosotros, the um formal U plural at all.

So it's like, why, why?

You can choose which Spanish you want to learn.

You can either do sort of Central American Spanish or they don't use vosotros, so you could use the Castilian Spanish where they do.

Yeah.

Ooh, yeah.

But anyway, that's our crap engineering.

I mean they uh Argentinian steak.

No, it's a different topic.

It's very interesting.

But they're um yeah, this is a lot of fun because the I mean when I was in Madrid, we had uh in our dorm, we had people from Argentina, Honduras, um Croatia, Serbia, um Germany, all over and even some of a couple of people from the Basque country, just all over the world.

And it was a great little melting pot, getting to know different people from everywhere.

Made some good friends and had a wonderful time there.

So I'm looking forward to um going back to Spain and um seeing what I know.

Uh DjangoCon US, yeah.

Yeah, yeah, yeah.

Yes.

Go on.

Drew, so if there's um we're coming up on time, so we sort of get sort of a rounding off type question.

Is if there's one magic wand and you could change one thing in Django to what would that be?

What if you know if you could just have it?

Okay.

Because so many use cases these days have, you know, whether it be necessarily it's like serving something like HTMX or you know, it can maybe be format agnostic, so to speak, but just have a this is the best way to rate your API in Django.

Have something like that in core.

It doesn't necessarily have to be the only way, but this is a you're getting started, you're trying to write something and you don't know what you're doing, use this to start until you would have a reason not to start.

Okay, brilliant, brilliant.

Um for there's uh work current going on currently to make um to add a request.data property that will not only give you form data if you submitted form data, but also if you submitted JSON, it would give you pass JSON back, like kind of like DRF has done for many years.

Um and then after that we'd make that pluggable so you could provide your own passes.

You know, uh Django would probably only provide um form data and JSON out of the box, but you know, you you could if you wanted message pack, you could have a password.

So, you know, we've got um forms, we've got the serializers for use for load data and dump data, that needs a refresh.

There's Django, Django serialization that that's there as well.

Then there's the modern things like um Pydantic and Atters and Katters, and then you know, there's projects like Django Readers, where you know you define a spec and it creates exactly the um select related and prefetch related and and only's and defers that you need to get just exactly the data you wanted and no more.

It's a beautiful project.

And so, what can we do in this area?

And so Andrew's Hatchway is like the the his take on you know this first this first thing, and he's used Pydyantic and mapped it into Django in what knows way.

So it's like, okay, there's one, let's do a couple of those, let's look at you know what the options are out there, what how can we because it because one option is let's just use Pydantic, right?

It's great.

But can we get some Django nicer so it ties into the ORM in you know the kind of way that say Django Readers is doing?

We have an opportunity to take what's been learned in the last few years and you know really do something exciting, and that's not going to go straight into core, but some over the over the 5.x cycle, it would be really nice to have some stories there that you know that would answer your own.

I mean, it's really exciting.

It's the kind of like the exciting what's left to do.

Um, you know, the last few releases have covered so many bases, and now it's like, okay, there's that.

I think those are the two the two big ones, some sort of uh API serialization and then async.

But I I did want to maybe as my closing qu uh thought question thing out there.

I was had a reader was asking me about I mentioned something about I was like, oh, 4.2 has Psycho PG3 support and that's exciting.

And he was like, I don't really understand.

He's like, I looked at, I was like, why are you excited about this?

And I was like, well, async.

And he's like, yeah, but why async?

And I do think that the community and people who use Python and Django are convinced that async is the way to go and we do need to have it.

But 95, 99% of people are like, what?

Like, you know, there's still a if not a communication gap.

Um, you know, I so I I sort of worry in a way that it's it's almost like string theory.

Like it's beautiful and it kind of works, but like, is it core?

I mean, I think it's hard to imagine it wouldn't be the way things are done in the future, but it's still a ways out.

Um, and so you know, I realized I was like, I don't have you know, I was like, uh, you know, here's the standard explanations for async, but I was also like, you don't have to use it, but you know, for people who are into this kind of stuff, it is exciting and it it will be, I think, important.

But he was like, I read the docs and I don't know why I care.

Like you just don't, you know, your blog, I'm serving it with async views.

Why?

Just use us just use your bog standard Django that you've been using forever and just keep going.

It's much simpler, it's much less effort.

But if you want real-time updates streaming out to a client or something like that, then there's a real case for async, or if you want two-way communicate, long-lived two-way communication.

I don't know, like the classic the examples are like a chat client, but chat clients are a bit boring, but there's lots.

No, but it's a nice example is that you know you're typing and you want to see a little notification that says you're typing.

Well, that needs an open connection that's sending, you know, that that little graphic is is Drew typing?

Yes, he is.

Okay, well, okay, I'll wait for the response.

That kind of instant update between the client and the server, that needs that needs async.

And then the other the other sort of end of the scale, but you know, build build your core app with sync and then tack on these little async bits that as they are needed, but really it's not top priority.

Then the other end of the scale is these high throughput servers that, you know, okay, you don't want to have to switch web framework or even language just because you have one of these use cases.

So we need an async story for those high high throughput cases.

But even those are few and far between, really.

There aren't many cases that need them.

And then when you push it right to the limit, it really does become a question of why you're still using Python at all.

Like, why aren't you using Rust or Go or whatever?

And maybe Python can be competitive in those spaces uh for pure speed, but probably it can't.

And then uh it's you know, Django get Django's gonna get you close enough, but then by the time you're in that sort of super league, I don't know if it's it's worth Python's while competing.

Maybe, maybe I'm wrong there.

Maybe Python can compete for speed, but um I'm not convinced.

I'm not sure, is more the point.

It's you know, Google, Microsoft, you know, it's companies that do have do have that interest at heart.

And it is important that they push things forward, but that is the tension, is you don't want to leave behind the beginner-friendly nature of Python itself because all the focus is on these more advanced use cases.

I mean, I I know that that's you know, any language that's that's an issue is balancing that tension.

And I see, you know, Microsoft put them, they they sort of um uh with the Azure they started using Fast API, you know, and that's a big pickup for them.

You know, is that the language I'll be using?

I don't know.

I don't know.

I just don't know.

Um, first of all, DjangoCon US 2023 sponsorships are open.

If you're curious, uh email sponsors at DjangoCon.us, uh Catherine and Don, our sponsorship chairs, asked me to plug that on the show.

And so um also we are currently giving away two tickets to the Python web conference that's happening next month, or next well, it'll be this month by the time this airs, uh coming in March.

Uh the giveaway is on our uh Mastodon and Twitter.

The form's open until the March 2nd on the f at 5 p.m.

Eastern.

So go ahead and um if you're listening in in time, go ahead and DjangoCon.

That you can uh sign up there and um you know get a chance to win a ticket to the Python web conference.

And um also to tie back into um we were talking about uh tying in beer and Django, um a quick plug for my little hobby project.

It's called uh HSV.beer.

What we do is we um actually like survey the digital signage for like Untap, Digital Poor, the various places that um where breweries and tap rooms can list on the TV what's on tap and that shows up on their websites as well.

And so we use Beautiful Soup to parse some of that and display it in a form that collates together everything in town that has that so they can see, oh hey, I want this beer, where is it on tap?

And so you can find out without having to search through six or eight different apps and venues to figure out, okay, I want this, where do I get it?

Or what's on tap at uh this beer at this local place?

Can is this anything I'm gonna drink here if I'm picky or if it doesn't have much of a selection?

And so it's a little fun thing that myself um and two other people, excuse me, here in town have done together to um uh try and make other things easier for us.

And it's just a little fun project using uh a DRF for the back end and um uh Nux.js for the front end.

And that's at um tap list.io, the the site itself.

That's the domain.

I'm sorry.

Thank you for coming on.

Wanted to have you on for a long time, both just to hear about your work um both professionally with Django Cons and just you know all these things that you know we we had we got to chat about on the bikes at 6 a.m.

in San Diego.

So hopefully

I know, yeah.

I don't I don't know Raleigh very well, Raleigh Durham, but

Okay, great.

All right, all right.

We'll we have time.

We'll sort out some company to rent bikes from and get a little get a little group.

Thank you, thank you, Carlton.

Thank you, Drew.

We are DjangoChat.com, we are on Mastodon, and um check out the links for the call for proposals and uh if you want to help out with DjangoCon as well.

Um see you everyone next time.

Join us next time.

Bye-bye.