Transcript: Django & Healthcare - Jacinda Shelly

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Hello, Will.

We're pleased to be joined by Jacinda Shelley of Apro Health.

Welcome to the show.

I've been a fan from afar of your talks and some of your writings.

Um so maybe to jump right in, could you tell us how you got into Django and then we can talk about all the cool stuff you've been doing with it?

I um so I I started learning to program in in Python um when I was at uh MIT actually right right after they switched their introductory computer science course.

I was a transfer student there uh when they made the transition from Scheme to Python.

And uh so that's where I first got into Python and loved the language and was fortunate enough that the first job I had after university was uh at a place where all of our backend code um was in Python and our front ends for the the web applications were in JSP and Java server faces at the time.

Uh but a couple years in got the chance to sort of rework that for a different prototype project.

And we worked with Django, and then my husband, who's also a uh programmer, um, used Django for a side project.

And so we started working, we both started working with it, I think around 1.2 or 1.3 back in in 20 2011-2012.

I'm I'm curious, what does a backend not written in a framework look like with Python?

Was it using something else or was it just sort of raw um from scratch?

Uh the first job?

Um and the we were using mod Python with Apache at the time.

Doctor on Demand, where you were was Django from the beginning, is that correct?

Uh that was the first project where I was lucky enough to get to choose this the stack, and I was honestly quite nervous about building something completely from scratch.

Um constraints.

Um and got to choose Django.

Like I I've been really struck by the fact that, yeah, I mean your average, you know, Django engineer expert, you almost never get to start something from scratch.

And so it's not that you don't know where the pieces are, but uh a number of people I certainly look up to have pinged me being like, oh, I was you know I'm doing a side project and I haven't done one for a couple years, and I was trying to do something and I looked up a post by you, and I'm like, oh really, you looked up something by me?

Like you're you know, you're this genius.

Um but the anyways, the different spheres and you know the startup phase is a different one.

But I but I totally agree, like it's it also does feel like this burden of like, oh, I don't wanna like I'm I'm almost done with a relatively big project on my end, and I'm totally overthinking it because I'm like, oh, I should architect it perfectly, right, with what I know.

Um, but it there is that balance between like just ship it too.

Is like I I definitely felt this pressure, like everything I did was kind of gonna cascade down, but then I I also eventually realized that if it did kit cascade down, that would mean that people were actually using it.

And so it's you know, if if you're lucky enough to have technical debt down the road, it means that something went right on the business end.

Yeah, right.

Well, I think too, there's I've started to think more and more about uh the patterns and the the fact that it does sometimes seem like some things are easily easier to change than others.

Um but yeah, at the end of the day, like it's all code, it can all be changed.

It's just some things that take a little more effort than others.

So maybe I I personally I've gone full circle while I've been like, oh, I really don't want to have to back in these things if I don't, you know, over-engineered up front.

And that's like, well, just to your point though, it's like it's all fixable and tech, yeah, tech no one's talks about technical debt and something that failed.

So that's it.

And so I I had an early review copy of that um and basically used it as like a checklist of everything that I needed to keep in mind.

Like I I read the book essentially cover to cover and then took notes on all of the things that I needed to make sure to keep in mind as I was building out the initial product.

And and I have to say that that helped a lot.

And um their book was was something that as the team grew, we actually would buy for engineers uh coming on board because we're like, yeah, there we don't do absolutely everything in here, but if you use this as a starting point, then um you'll have at least a solid foundation.

And actually I had I remember so I j uh before I I got into publis to make this about me, before I got into publishing as a book editor, and they like had a whole bunch of like typos and I actually sent them and uh and they were really sweet.

I I it was a they had problems with it's and it's and uh they sent me like an autograph copy after, and so I was such a fanboy.

I was like, oh my god, you know, these crazy um people did this thing, but it was such I I agree, it's like it's basically the Bible still.

I mean, and I think you know, even though they haven't updated it, I I it's still on 111.

I I hope that they do because the advice is you know 90% of it hasn't changed in terms of being rock solid.

Um and it's funny funny you mentioned like a typo.

Like I I got it like just a couple months before they published it, but I did find like one typo, so I think my name is right at the the end for the first edition because of that.

And I was like, this doesn't seem like enough.

Just finding one typo should not be a reason that my name is

It's a really nice yeah, now that I'm thinking about because it's a really nice thing to do.

I think I did on my first book, I had a whole bunch, but now there have been so many people catching so many things.

I sort of stopped doing that.

But anyways, but on architecture, I'm curious.

So Doctor and Demand, so you just started it and then it grew to this massive thing.

I guess the other thing I've been thinking about recently is I mean, there is no architecture that starts small and scales all the way up.

Like there it has to change.

So I I'm curious what if you can look back and think of like, yeah, what were those big changes in terms of architecture or what were there some tipping points where you said, Oh, we need to, you know, we need to change how we structure our apps to larger things around I I don't know, what what were the things, right?

Because that's such an amazing journey to go from like the initial lines of code to like a large code base with a lot of engineers.

Yeah, it was most people I think don't get to do.

I I was super fortunate to get to work with like really incredible people and and stay long enough that I saw the team go from like myself and the two mobile engineers who started right after I did, uh, all the way to like they have about 50 engineers now and uh handle thousands of video visits a day.

Um interestingly enough, uh whether by luck or um probably mostly, mostly luck and like copying people who I I admired, uh large portions portions of the architecture are still the same.

Like it's still a Postgres database.

Um and I think one of the things that helped in in scaling was uh trying to like use things in the way that made sense for them.

So like we use Postgres for relational things, um, but then also make really heavy use of Redis for things where Redis makes more sense.

So like caching, um simple key value stores, and then uh a lot of the priority cues uh are are done in Redis because Redis makes that really easy, um, but it can also be persistent, which uh queuing is is a big part of the backend architecture at Doctor on Demand, um, because you imagine like people are waiting to see a doctor, and uh the routing mechanism there is based on

the state that the patient is located in.

Um so in the US uh you have to be routed to a doctor that's licensed to practice in the state that you're that you're located in.

Um so we have to do a lookup, uh, we do a geolocation lookup to find out where you are, and then match you to a doctor that's licensed in in your state.

Uh one of the things that uh is an interesting story, I think, is premature over-optimization and uh not doing some simple math uh ahead of time.

I I over-engineered the original version of uh how we route patients.

So I think you had a reference in in some of our notes to the the first talk that I gave on like how we were using celery.

And one of the things that I did early on was like, well, if we need to scale to like every state, it probably makes sense for like every state to have its own celery queue.

Um, but that got really unwieldy uh whenever providers had multiple state licenses uh in terms of like tracking uh when doctors were and weren't available in in different states if they could see patients across multiple states and tracking the state there.

It turns out that even at like massive scale, um the scale at which humans need to see doctors uh is sufficient to just run through a single process.

So later, like after someone was like, so how scalable would this have to be even in like your wildest dreams?

Um and I I did some back of the envelope math and I was like, yeah, that's fast for a human, but for for even for Python to be routing, like you could handle basically all the patients, like even if one percent of everyone in the US was sick and needed to see a doctor over a single 24-hour period, you can run it through one routing system and it's it's totally fine.

And when I when I realized that, I was like, oh.

Well, this is a lot simpler now and actually a lot more stable and kind of automatically fixed a lot of bugs.

So it's it's not the typical scaling story, actually, where it was like, I I made a realization that I'd overcomplicated something and then simplified it.

I think that's more typical than you say though.

But like that we, you know, you read um you know high scalability or whatever, and it high and you you think, oh, I'm I've got to build a system like this.

But I think 95, 98, 99% of web apps have exactly this kind of phenomenon where you're actually a simple stack and you might get a slightly bigger server, but one of them's enough, and a slightly bigger database, but you don't need you know redundancy.

And that's that's a common story, I think.

I think you know, we you you see these blog posts.

Will Django scale?

Yeah, it does it'll scale more than you need to do.

And if you're having trouble scaling Django with a site that has less than you know hundreds of thousands of visitors a day, uh there's probably something in your configuration or your code that's the issue.

It's not it's not Django.

That was the other thing was keeping an eye on on queries, because like database um and like always learning about how the ORM works and when it makes queries and um and the the single biggest thing that helped in in not having to like shard or like do crazy things with the database is just making sure that the queries were uh efficient um and and that the ORM

was used correctly.

So I mean prefetch, select related, jump out, but what were the like what are like next levels?

Um especially if you have certain columns that store like large amounts of data, so you can either like use only or exclude certain columns.

Um that can be uh an easier way to to eke out performance than like trying to redo the whole schema and and keeping an eye on like uh and using Django debug toolbar was was always super helpful.

Anytime I saw that there were like a thousand queries uh coming from like a single API endpoint or a single uh web page, it's like there's there's something not right here.

And if there's a problem, like I so I guess w did you have rules of thumb for beyond seeing oh, there's a thousand queries, like just looking and saying, Oh, this feels slow, like how did you when you have so many things you have to deal with on a growing platform, like what jumped out as you as like, oh this this deserves to be optimized versus something else?

So I think that'd be like that's a really interesting question when you're in charge of the tech stack.

How do you decide or what what jumps you?

Um but also over time um we put in place monitoring, so our architecture was such that because we actually launched on mobile before web, we kind of got a a clean separation between front-end and back end um because the iOS and Android platforms were using uh an API.

So when we added on a web browser, it was just like, okay, this is gonna be a single page web app that is using the exact same API.

So at the API endpoint level, um, we tracked how long on average each endpoint took to respond, and then we could evaluate like and we had some rule of thumb thresholds based on we we definitely didn't always um follow these, especially for certain endpoints that weren't used as often.

Like I think the the part of me that is like the the engineering purist was like, no, we should have a threshold where like no API endpoint can go above this, and then the other part of me that uh was was thinking about the business from the startup was like there are other things that are more valuable that we could be working on, and this is this is good enough, and that's always a a tough balance.

Um but monitoring that the the API response time average time got us a long portion of the way there.

I mean the iPhone had only been out well, I guess four or five years, but did that was that a big decision to make or like I mean, because that's very prescient, but I I don't think that was the case really back then that you would

Our our CEO at the time was like we're we're launching on mobile and we're not gonna do browser first, I think for a few different reasons.

Um because we were trying to be next generation was probably part of it.

Um but also it ended up being that yeah, I that that's one where actually the requirement came from from outside of me, and I was like, okay, cool, I'll design around that.

And so I I can't really take any credit for that.

People were like, Oh, I've got an idea for an app.

You couldn't you couldn't go anywhere without people s telling you their app idea and expecting you to build it for free.

It was it was crazy.

That's uh scars from the past.

Well that um and I assumed you use Django Rest framework.

Um is that correct?

We we did not.

Um and

Um it it certainly stemmed from the the previous job that I had had where we were using JSON RPC.

And so I was very familiar with RPC, and because partly in my head it was like, oh, this is my there is like some tight couple coupling in terms of state between the client and the server, where it was important to be tracking what state a call connection, like a video call connection, was in over time and like the progress.

Uh I certainly looking back, uh, it's one of the things where it's like, oh, I wish I had started with Django REST framework, um, but I didn't have experience with it, and I did have experience with JSON RPC and had used it previously, and it uh worked sufficiently well that it lasted for a long time.

Um I think also at the time, and and this was probably my own inexperience uh just with the community and the the framework, honestly, where I remember that DRF was I think there was a Kickstarter project in 2013, and so I was like, oh, they're making this big transition.

I don't know if I want to do something right on this transition, or it felt like that without digging deeper into it.

I also vaguely remember thinking that I I might want to do the entire API uh in in engineering idealist terms, like, well, if I do it in JSON RPC, then there's a potential that I could do it entirely over WebSockets and like not be tied to uh REST-based constraints, which in some part of my mind seemed very appealing.

So I was gonna ask you, what was how are you handling that kind of um communication on the back end?

Uh to the back end.

So I um had a poor man's state machine.

Um James Bennett works at at Doctor on Demand now, and he can probably like laugh at my my first implementation of this, which was I mean it lasted long enough, but it it was like I could have done it so much better.

That's the software, right?

We never did the actual real-time video, we were um forward-thinking enough to and I had had experience like building out video infrastructure at a smaller scale, and so I was very pleased when the founders were like, Yes, we already have a a company that we're using that you just have to interact with their API for the actual video part.

So we just had to track the state of a call and it would transition from you know, like someone uh makes a request that they want to talk to a doctor, and then uh the doctors have to be paged, um, and then they can either accept or reject a call.

If they accept, then the call goes into a connecting status and the video connection happens like peer-to-peer.

And then once it's confirmed as being connected, then it moves into like, okay, the call is now in progress.

And so that status was was tracked in like the state for each doctor was stored in Redis.

Um since it had to be updated frequently and was was more of a key value entity.

Um, but also kind of needed to be persistent if the call got disconnected or someone came back later or something like that.

How were you how were you like polling or were you using a what were you doing to communicate the connection state back to the to the back end?

Just from the client?

uh the backend

So the client, if it did get connected, it would have to ask the server what state the call was in.

Um and then as state transitions happened, that was where we used WebSockets.

So um and push notifications.

So when a s so say you were the patient and um you made a call, your call once a doctor accepted, um, we'd use the WebSocket connection to push a notification to the client that the call had been accepted with information on like what state it was now in.

Um and then the client, if it hadn't received uh a push notification in a while, it could use polling as a backup mechanism because polling was much more expensive.

Yeah.

Super.

That's really interesting.

So it's cut, you know, I don't know how it comes across on the podcast, but that's super true.

But um oh the other thing that we used that was successful once I got the configuration working was was celery from the perspective of using scheduled events.

So if there needed to be timeouts on something, like um if something hadn't happened in two minutes, uh using Celery for that was a a very successful choice, although from an infrastructure perspective, like uh could also be frustrating at times because it's it has so many little knobs in terms of configuration that the first few times that I started using it, um there were some deadlo

cks that happened at like 11:30 and I was the only person on call and that interrupted like a trip to New York.

Definitely have to thank my husband for being very patient that first winter after we launched, where I was like, Yeah, I need to go find a Starbucks um and get Wi-Fi because I would get text message alerts on my phone, um, if anything if for if for any like errors that happened.

Because you you said there's now something like fifty engineers.

I guess in terms of I don't really necessarily want to get into the hiring because that's this old old topic, but for you being the like letting go and then managing people.

Um that's always I mean that's a super deep topic, but what are your I don't know, what what are your sort of rules of thumb that you take away from that that you're now applying to your new startup, right?

'Cause especially the first time, it's such a I mean there's so many balls in the air you have to juggle to keep something going, bring on new people, find stuff for them to do, let go of certain things, all that.

Um and I actually like this is the sort of like third kind of sine wave in my career.

Um I think I'm a little bit unusual in terms of engineers in that like I actually also enjoy the management piece of it.

Um, but I get a little bit antsy sometimes if I if I haven't done code.

So um at my first job I started as uh an engineer.

I was actually hired as an engineer, and it was also a very small company.

I showed up on my first day and they were like, uh by the way, you're now leading this team, you have one person reporting to you, and uh you need to hire someone else.

And I was like, wait, what?

Um I remember this was my first my first job after college.

Uh so

Like I was like, what are you thinking?

Um but but was able to like expand in scope of responsibilities and always enjoyed like organizing projects and like figuring out how different people could fit into pieces together.

Uh but after that job I I wanted something more hands-on for a while.

Uh so that's why one of the reasons why Dr.

Anamand was very attractive as like a first engineer because I I was excited to be very hands-on again.

Um the trickiest thing for me in in scaling a team was was was learning to get, I think, the same sort of dopamine rush that you get from getting a piece of code to work from helping other people build systems that would let them get code to work and thinking of it right.

It's it's always been something that's been challenging for me to to let go more of.

So it I mean I think part of part of it is, and maybe it's an idea that you know effective technical managers do oscillate between, you know, rolling up their own sleeves and managing others, but yeah, it's hard to say.

It's one of those I one of those I just read that what is that book, um technic technical managers.

Um just came out uh two or three years ago talking about um all these things and all these tensions from the woman who was CTO of I think it was Rent the Runway.

Oh, cool.

Um and there is no anyways, my quick takeaway is there is no person who has like a perfect equilibrium on this thing.

I mean, the very things that make you a good engineer are the kind of things that make you go, you know, maybe sometimes not want to deal with other people's issues, but then if you are the type of person who can see that helping others, you know, is a magnifier and also in some ways feels better than your own individual stuff.

Um so yeah, I don't I haven't seen anyone with an answer.

Carlton, I don't know what your thoughts on the matter are.

Like, you know.

I see that it's great, but do I choose to do that as my main thing?

No, I don't choose to do that as my main thing.

Yeah.

So I I do want to talk about your your current thing, um, and maybe we can transition to that, you know.

So round three, like tell us what is Apro Health, what's what's been different, you know, on the technical side versus doctor in demand um having gone through that turnout.

Um, but the if if we get

I'm dealing I think anyone of a certain age is just dealing with this all the time.

If you have family, it's just how yeah.

I understand the problem.

No, but uh when we started accepting insurance, uh things got an order of magnitude more complicated than I expected.

Um and we we were working with an outsourced medical billing partner um who was supposed to handle a lot of the complexities, and so watching the way that they operated, I I started thinking about like two or three years ago, I was like, this seems like an area that there's just not overlap between people who really understand software and who also really understand billing, uh, because they both take, I

think, a lot of time to to fully understand the complexities.

Um interestingly, my my husband um had been looking at like various ideas because he wanted to uh found something of his own.

He has a connection with uh a family medical practice, and I was like, well, for for Doctor on Demand, this is this is a big pain point.

Um maybe you should talk to your your family's practice and see what it's like for them.

Um and I was I was not this was several years ago.

There were there were like so many things that I wanted to do at at Doctor on Demand that I was like, yeah, it's not something that I can work on right now, but I think there's definitely like problems that could be fixed there.

So so he started looking into that, also was looking into other ideas, so it didn't really go anywhere for a while.

Uh was working on Apriro and then and then eventually came back to it.

Um, and he had been working on this since the end of last year, um, and was accepted into YC, which is kind of when when I decided that it was something that I also wanted to pursue.

So one of the differences so far has been like, yes, we're we're still using Django.

Um but one of the differences has been like coming into a project that already has like a significant amount of uh engineering work that that was done before I got there.

Um and also like I until really the last month um had been much more in operations and sales and wasn't even like touching the code.

So that was a whole other exercising, a different part of my brain.

I can't even imagine.

Um what is this robot?

Like what's the quick kind of stack

Django, Postgres uh running on Google App Engine, um but uh using uh DRF and GraphQL for some things.

Um React on the front end.

So it's an interesting mix of things, but mostly like mostly boilerplate and pretty much what you'd expect if you've seen the tech stack that I've been working with for the last seven or eight years.

We just had um uh Wenbin Feng, who wrote a popular post on uh the boring tech behind a one-person tech uh tech company um was talking about listen notes, his company, and I mean if you can do it, if it works, it works.

And yeah.

You know, you're cut you're going with no, but you you're going with the grain of the of the of the stack of the wood.

You know, you're you're not fighting it.

Yeah and then it does scale, then it does work.

Um so actually, so maybe that's a relevant question.

Um Django just Django just updated, I'm curious either at Doctor and Demand or or at Apro, how how up to date were you all with the Django versions?

What were those transitions like um you know, being hands-on?

It was a like something that I felt like I had to hide for a long time, but it's it's relevant to know, um, but it's relevant to you to the point about uh vanilla rails, um where and it's also relevant to like choosing dependencies carefully.

And so for that reason we like forked Django, and then we didn't have to after one seven, but the transition from one seven to one eight took a very long time.

Um actually one six to one seven and then one seven to one eight took a long time, yes.

So going from and and it was because uh this library that that I chose, which it was an address library, um, that you know had a what seemed at the time like a good idea from an architecture standpoint where you have like uh a table for um for countries and for states, and then like everything only has one key, but you end up with

like lots of joins.

Um and looking back on it, that's one of the things where I'm just like, yeah, I I should have just created an address model with all of the fields and been done with it.

Um because the the pain associated with using this third-party library and some of the things that digging under the hood later they had chosen to do and like undoing that after like we were using addresses in all sorts of places um was was more painful than than it should have been.

How do I tell?

And I was like, oh, that's I mean, I sort of love the naivete of that question, but it's such a deep question because it really it often is, you know, you install something, you know, when you're prototyping or you need it, and then that's what caused you to come behind on Django.

And I at least personally, I'm sort of yeah, I'm always extremely reticent to add any third-party packages to my stuff.

If I can, I'll try to reverse engineer it just for this very reason.

But that's not a practical mindset.

I mean, you just you know, you sort of want the technical debt, but yeah, you always don't really look under the code until you have to.

And yeah.

I don't know.

Carlton, what are your what are your thoughts on this?

It's just such an interesting question.

Like I've I've I wept tears of blood over third party dependencies that I wish I'd never installed.

So uh what what

No, I could just have been different.

You have to learn why it is that this uh pip install magic package.

Like it's not a good idea, folks.

Like there are so okay, so there are there are what a dozen or twenty or thirty, like really top-notch, long-term, mature Django packages out there that you just wouldn't.

There's no way would you build your own.

You just use them because they've they've got a history, they're reliable, you know.

But you but be cautious.

So go on the the there was a post on the forum.jjango project.com, the Django forum.

Uh, which packages do you like?

And that is gold done.

There's you know, people have

But there are you know, twenty ten quite people with like different overlaps of their best packages.

That was amazing.

That's great.

Use those packages, but don't you know, be careful.

So, like, you know, there's um uh something came up on Twitter the other day, hash IDs.

So for slugs, you want uh yeah, yeah, yeah.

You want uh a unique ID.

I use I use hash IDs, but I don't use the Django hash IDs project.

Not because that might that might be great.

I don't know, but I just won't go near it because I won't take on a dependency that I can't vouch for.

And I learned that the hard way.

I think I I think the question on the on the Django forum was uh top five third-party packages, because I was curious if there was a standard overlap, and I think you know it quickly becomes really like 1015 for most people that they're using on every project.

Um, but that is one of the things I think about in terms of is there a way to shortcut to that without uh you know tears and pain?

Like I'm still very pro-dependency.

Um and and there are there are other dependencies where I'm like so glad that I found them.

Um there's there's one called that's and it's actually not super well known, um, but it it just works.

Um and it's it's called uh QR, but I think it's it's hard to find because um

And the whole thing like was one of the one of the reasons I didn't have qualms using it either was the whole thing was like probably like 500 lines of code and I could like grok it and like see what it was doing, and it was like, okay, this this is like fine.

Um and I don't have to write this myself and thank you to the author for like putting this out there because it was incredibly reliable and an easy to use interface.

Um but yeah, there there are libraries that I wouldn't start a project without, but it's I I sort of have this someone asked me about this once um if I had a philosophy around like what tech I chose to use.

And I said something along the lines of like I like to use things that are new enough that people don't cringe when they hear you're using them, but mature enough that uh I'm not getting woken up at two in the morning more often than necessary.

So the the sort of cast iron test for a new dependency is if push comes to shove, if if this never gets another commit in its entire thing, could I take this on and maintain this as part of my you know daily job?

If I for the for the good of this project.

In that case, yeah, okay, maybe take it on.

But if it's you know loads of models and loads of views and loads of stuff, and it's like is this is this really what I need for my project?

I think I think they open sourced it.

Is that the one?

Um, and if you look it up on GitHub, it's it's TNM slash QR.

And I I was able to find it because uh it's one of Dr.

Anaman's public repos is QR3, uh, which is the Python 3 version of it.

Um and I think that it sort of marks the difference sort of up to one eight, and then one nine, one ten, one eleven to you know, it's it's a different world now, right?

It's much smoother, much easier.

Yeah.

A sort of change in uh

So it's a different like it's just like a different epoch in Django's history, right?

Those early days to to now.

Um which is which is really really nice.

That's how you that's how you want it.

So thank you, Carlton, Marius, and everyone else for making that happen.

Uh Jacinda, I wanted to ask you about um so you've given a tutorial on security, I think at least the last two Django cons, and I I haven't been able to attend in person, but I've gone through all the slides.

Um it's really fantastic.

I wonder if you could just sort of tee that up in terms of you know, because I think you you what what is that tutorial like and I hope you keep doing it right in terms of I think you you take a Django app and then ask people to hack it and run through kind of best practices which are super relevant to you know medicine.

Um it it's it's one of the things that I actually really like about Django is how seriously they they take security.

Um like even when there was a time period where we were using an unsupported version of Django, uh we we made sure to like backport any security fixes um and keep keep on top of that.

Um much better when you're on vanilla and you don't have to worry about that because you get it for free.

Uh yes.

It's actually originally um uh Ashisha's tutorial that he gave at PyCon, um, I want to say 205, 2014, 2015.

Um have to to double check.

Um but I I was giving a tutorial at PyCon, yeah, PyCon 2015.

I gave a tutorial on the Django admin actually, which um I had also given at uh DjangoCon 2014, which was my first ever Django Con.

And I was uh crazy uh simultaneously crazy enough to um propose a tutorial and a talk, and then the organizers accepted both of them from a first-time presenter.

Uh it was it worked out fine.

That's a fantastic talk because you talk about yeah, building out the early version of Doctor and Demand.

And I was like, sure, I'd I'd love to help out.

It was it seems like an awesome idea.

He set up uh a deliberately insecure uh Django web app and then you go through uh all of the instances are on Heroku, so you're split up into teams, and there's a short period of lecture where you go through like various pieces of the OAS top 10, and then your team that you were assigned to uh has a Heroku instance that you try and like find the vulnerabilities and you can see um like why you're not supposed to use

raw SQL and why you shouldn't put CSRF exempt on on things and like how a cross-site scripting attack actually works and what it looks like.

Um and it's a lot of fun because people like will do unexpected things to each other and like they'll they'll find the vulnerabilities and then because you're working in a team, like someone will um come up with like people who who are much better at JavaScript than than I uh am have like crafted their own like fun little things that are are surprising for folks.

Um I think someone probably rickrolled all the the other teammates at at one point, um which is great.

Uh I loved that tutorial and I like a couple years later I met Ashish again and and like thanked him for doing it and was like that was an awesome tutorial, and he mentioned, yeah, I don't have time to work on it anymore, but if you if you ever want to take it, it's like all open source, you're welcome to like give it yourself.

Um and so I did.

I updated it from one four to one eight uh last year or no in 20 when I when I gave it at DjangoCon 2018.

Um and I definitely remember, or maybe it was to 111.

Um regardless, I I realized why he hadn't used 1.7 because that was the most recent version, because like Django introduced some stuff that made one of the vulnerabilities much harder to execute in 1.7.

And so I like was banging my head against the wall, like how can I get this vulnerability to to work again?

Um it has to do with like cookie-based session storage and and how you um can hack that and like why the Django secret key should remain secret.

And so Django has gotten progressively secure or more secure over the years.

And so I I remember um complaining, it was like I had to spend so much time to get this vulnerability to work again.

Uh and and and I was talking to James, he was like, Are you really gonna complain about Django getting more secure?

I was like, Well, yes.

It is well, and I think I don't I don't know if either of you know when the deployment uh checklist that um is part of Django that uh I think we've talked about in the show.

I mean, I find that so helpful, right?

Because it really is.

Um and I I didn't realize it was actually yeah, you just spin up a dedicated Heroku for each site.

I mean I guess I guess you need two accounts, right?

Because you only get five free accounts from Heroku, but it's typical

Yeah, I I got the like um I have a a paid account, but I don't think I've ever even even with the tutorial um having used it, I don't think I've ever had to really pay very much at all um for the way it's being used.

And and all of it is like all of the all of the slide content and web app content is all available on on GitHub.

And so anyone can can go through it and like set it up.

The basic takeaway of the the tutorial is uh don't override Django's defaults um unless you really know what you're doing, and are you really sure that you know what you're doing?

I also wanted to ask you about I saw this year at PyCon you gave a talk on speeding up the Django admin.

Oh yeah.

I guess I'm curious, at what point do you leave the Django admin in terms of playing around with your data and stay in it?

Because you showed all these fun optimizations, but um with your experience, what's your kind of rule of thumb for when are you abusing the admin and when are you improving it?

Um that that's that's one one key indicator.

I don't recall if you I remember you showed you stepped through how to speed up like some queries.

I I definitely encourage people to go watch that one as well.

I think she gave it at DjangoCon this year.

But I mean I loved I love your presentation because you took like a really slow query and then you you kind of stepped through ways to improve it, which I love that teaching approach rather than just giving the answer because without the context, it's it's just like some code you've memorized.

But I assume that came from some real world examples of uh using the admin to do lots

of stuff.

I think if it's I think the general rule of thumb that the documentation gives, if if you're using it primarily for like internal use, then that's great.

If it's I I don't want to give like a blanket rule because it's like it's such a useful tool.

Like that's probably a you know, I don't want to say blanket bad, but uh application smell, maybe?

Like, are you are you really sure this is a good idea?

Uh kind of thing.

I I would I'll I'll a hundred percent agree you shouldn't show outside or customers your admin panel.

I mean, even and even you know, basically the

It's got an isstaff flag.

And if you're not staff, you can't log into the admin by default, right?

So go with that.

you know.

Some people can do reads, some people can do

I don't know.

That's that's that's potentially one of those like we could go down a deep rabbit hole here.

If you have enough knowledge to customize the admin, go for it.

I mean, like not go for it, but like, you know, it's a little bit how I feel like when when I'm when people ask me about like setting things up at computers and they're using Linux, it's like, well, you're in Linux world, like I exempted yourself into a different category.

With with great power comes great responsibility.

I was gonna say on the admin, and this just came up uh two days ago.

The thing one if I could solve one thing, it's like don't ex have your admin at slash admin.

Like I was looking at some somewhat prominent Django company, and I was like, I I was like, I wonder if admin's exposed.

Yeah, it's exposed.

And then I was like, you know, doing password, you know, so uh change that.

Like I would rather you give outside access to your admin than have slash admin personally.

Carlton, you agree?

It's so easy to change

Well, and I mean I just I just I just yeah, I just really judge harshly.

It's a little unfair, but I looked at that as like, nope, they just dropped a whole bunch of notches.

Like you gotta change that.

Anyway, sorry, I your your talk though, I think you focused a lot on on queries, right?

On speeding up I forget the the schema that you were dealing with in

An alternate title for that talk could be like basic usage of uh Django debug toolbar for analyzing um for analyzing queries.

And and it just happens to be really easy to like demonstrate that against the admin because it's very easy to create um ON queries when when using the list view.

Um I'm curious if you we'll link to that, if you could share you know the non-technical side of being a coder.

And and I was really fortunate um that at Doctor on Demand the culture was such that like I was able to take I was I was able to have a an extremely flexible working schedule, especially after my my daughter was born.

Um and so in that talk I discussed some of the things that like I totally didn't expect becoming a parent.

Um and it was it's different from most of the other talks that I've given that that you'll find.

Uh my daughter actually ended up on on stage uh towards the end of that talk because she was she was 10 months old and she was being held in in the front row for a good portion of the talk and then she decided that that she was just not not happy there.

I you know what I have seen this talk then.

Yeah, programming post-progeny, because I I do remember that talk.

And actually I love that I think you you generally bring her to the conferences because I've seen you at a number of conferences that you're there because it actually makes me feel like, oh man, I should have brought my kids to

The expos are always a really good time.

That's one of the things that coming for the language and staying for the community has been a big part of Python and Django for me.

Like when I started, it was because I appreciated like the test technical aspects of it.

And now going to the conferences is also for me like just a connection with a really fantastic group of people that I love being around.

And I think too, I mean, just for me, like I've I'm now my second year of going to conferences.

They they they just get more fun because then you already know people and you um you still meet new people, but um yeah, it's a very welcoming community.

What a super chat.

I'm you know, everything, technical details, all the way through to community and family and life and things like that.

So super.

We're um on Twitter at Chat Django and uh join us next time.

Bye bye.