Transcript: Django & Healthcare - Jacinda Shelly

Hello, and welcome to another episode of Django Chat, the weekly podcast on the Django Web

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

Hi, it's great to be here, Will and Carlton.

We're thrilled to have you on. I've been a fan from afar of your talks and some of your writings.

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 uh django specifically was or python i or you

know you can give us the origin story as as short or as long as you like okay i'll i'll try and keep

it compressed and then we can expand if we want to 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 when they made the transition from Scheme

to Python. And 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 at a place where all of our back-end code

was in Python. And our front-ends for the web applications were in JSP and Java server faces

at the time. But a couple of 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 programmer,

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 2011, 2012. Okay, that's back in the day. I'm curious,

What does a backend not written in a framework look like with Python?

Was it using something else or is it just sort of raw from scratch, the first job?

It was a sort of from scratch JSON RPC API interface.

And what was in connecting?

Do you remember what type of database?

Was it like MySQL?

It was originally MySQL and then we transitioned to Postgres.

the we were using mod python with apache at the time okay doctor on demand where you were was

jenga from the beginning is that correct yes 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 yeah no constraints no no constraints really um

and got to choose Django.

But it is such a different beast.

Like, 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 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 of 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. But anyways, the different spheres and, you know,

the startup phase is a different one. But I totally agree. Like, it's, it also does feel

like this burden of like, I don't want to, like, I'm almost done with a relatively big project on

my end. And I'm totally overthinking it. Because I'm like, I should architect it perfectly, right

with what I know. But there is that balance between like, just ship it to that's, that's

always the balance, right? It's like, I definitely felt this pressure, like everything I did was kind

going to cascade down. But then I also eventually realized that if it did cascade down, that would

mean that people were actually using it. And so it's, you know, if you're lucky enough to have

technical debt down the road, it means that something went right on the business end.

Oh, no.

Because nobody cares about technical debt on an unsuccessful project.

Yeah, right.

Right. Well, I think, too, there's, I've started to think more and more about

the patterns and 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 to take a little more effort than others so maybe

i personally i've gone full circle well 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 talks about

technical debt and something that failed so that's what i did like um at the time that i started it

was right when uh audrey and uh danny were were publishing the the first edition of uh two scoops

of django 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 I have to say that that helped a lot.

And their book was something that as the team grew,

we actually would buy for engineers coming on board

because we're like, yeah,

we don't do absolutely everything in here,

but if you use this as a starting point,

then you'll have at least a solid foundation.

Yeah, I think that was the first Django book

that I read more than once and really enjoyed.

And actually, I remember,

so before I got into publishing,

to make this about me,

before I got into publishing as a book editor,

and they had a whole bunch of typos,

and I actually sent them,

and they were really sweet.

They had problems with its and its,

and they sent me an autographed copy after,

And so I was such a fanboy. I was like, oh, my God, you know, these crazy people did this thing.

But it was such 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, it's still on 111.

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

I definitely bought the new editions as they came out.

And it's funny, you mentioned like a typo, like 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 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 isn't there. Oh, yeah, I think I'm in there too. It's a really

nice. Yeah, now that I'm thinking about it, because it's a really nice thing to do. I think I did

on my first book, I had a whole bunch. But now I'm in so many people catching so many things.

I sort of stopped doing that.

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

So Doctor on 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'm curious what if you can look back and think of like, yeah, what were those big changes

in terms of architecture or 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 don't know

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 people i think don't

get to do it was an incredible journey 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 of the architecture

are still the same.

Like, it's still a Postgres database.

And I think one of the things

that helped in scaling

was trying to, like, use things

in the way that made sense for them.

So, like, we use Postgres for relational things,

but then also make really heavy use of Redis for things where Redis makes more sense.

So like caching, simple key value stores, and then a lot of the priority queues are done in Redis

because Redis makes that really easy, but it can also be persistent,

which queuing is a big part of the backend architecture at Doctor on Demand

because you imagine like people are waiting to see a doctor

and the routing mechanism there is based on the state

that the patient is located in.

So in the U.S., you have to be routed to a doctor

that's licensed to practice in the state that you're located in.

So we have to do a lookup.

We do a geolocation lookup to find out where you are

and then match you to a doctor that's licensed in your state.

One of the things that is an interesting story, I think, is premature over-optimization and not

doing some simple math ahead of time. I over-engineered the original version of how we

route patients. So I think you had a reference in some of our notes to 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. But that got really unwieldy whenever providers had multiple state

licenses in terms of like tracking when doctors were and weren't available in different states,

if they could see patients across multiple states

and tracking the state there.

Turns out that even at like massive scale,

the scale at which humans need to see doctors

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?

And I did some back of the envelope math and I was like, yeah, that's fast for a human, but for even for Python to be routing, like you could handle basically all the patients, like even if 1% 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 totally fine.

And 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 not the typical scaling story, actually, where it was like I made a realization that I'd overcomplicated something and then simplified it.

I think that's really cool.

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

like we you know you read um you know high scalability or whatever and it's high and you

think oh 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 you see these blog posts will django scale yeah

It will scale more than you need it.

Yes, if you get to the point where you're worrying about it scaling,

that's a good problem to have.

And if you're having trouble scaling Django

with a site that has less than hundreds of thousands of visitors a day,

there's probably something in your configuration or your code

that's the issue.

It's not Django.

That was the other thing was keeping an eye on queries

because the database and always learning about how the ORM works

And when it makes queries and the single biggest thing that helped in not having to shard or do crazy things with the database is just making sure that the queries were efficient and that the ORM was used correctly.

are there any examples you can give so i mean prefetch select related jump out but what were

like what are like next level prefetch and select related but then also realizing that like

iterating over a query set as opposed to like pulling all of the values at once um can be a

big time saver uh on certain tables depending on what you're storing like only can be really

valuable 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 a an easier way to to eke out

performance than like trying to redo the whole schema and and keeping an eye on like and using

django debug toolbar was was always super helpful anytime i saw that there were like a thousand

queries coming from a single API endpoint or a single web page. I was like, there's something

not right here. Yeah, it's like an N plus one. I was going to ask, yeah, beyond Django debug toolbar,

but then we're probably getting into monitoring tools because I find Django debug toolbar gets

me a lot of the way there. And if there's a problem, like, so I guess, did you have rules

of thumb for beyond seeing, oh, there's a thousand queries?

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 at you as like,

oh, this deserves to be optimized versus something else? 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 jumps the queue? Early on, the this feels slow thing was a reasonably good benchmark,

to be honest 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 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 going to 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 part of me that is like 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 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 good enough.

And that's always a tough balance.

But monitoring the API response time, average time, got us a long portion of the way there.

That's pretty forward-thinking to be mobile first back in, was that 2013, I think you said?

I mean, because now that's sort of, I would say, standard practice.

But I think even then, right, I mean, iPhone had only been out, well, I guess four or five years.

But was that a big decision to make?

I mean, because that's very prescient.

But I don't think that was the case really back then that you would default to that.

This is one case where I definitely can't take credit.

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

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

But also it ended up being that, yeah, that's one where actually the requirement came 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 for my experience i i did um that mobile app

development around that time and it that was the real that was like the the mobile app gold rush

days that you know 2013 2014 people are like oh i've got an idea for an app you couldn't you

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

free it was it was crazy equity carlton equity yeah no but and don't get me started on that

those little scars from the past but yeah well then um and i assumed you used django rest framework

um is that correct you know this is actually a funny story we we did not um and okay interesting

and there was a transition to using rest later 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 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 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

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 um do you have

insight Carlton on what that when we just yeah we were just talking to Tom Christie last week and

like he was going over the history and yeah that time that transition from two to three or

one to two I think it was one to two yeah one to two in the kickstarter there and yeah yeah 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 web sockets and like not be tied to uh rest based constraints which in some part of my mind

seemed very appealing um but you're thinking like so you've got real-time syncing between the client

the mobile client app and the the api back end right so i was going to ask you what was how are

you handling that kind of um communication on the back end uh to the back end that was actually one

of the the first places where we used redis so i um had a poor man's state machine um james

bennett works 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 was i could have done it so much better

um right but that's always true that's the software right uh so we use redis to track

the state that a doctor was in and that was tied to like um a call id 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 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

but also kind of needed to be persistent if a call got disconnected or someone came back later

or something like that and so i'm on my mobile phone and i've i've got a i'm a patient and the

doctor's accepted my call and i'm i'm in the connecting state how are 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 because that's kind of uh the back end that's kind of

tricky question the back end was the arbiter of all state um which which was actually a good

decision 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 web sockets so

and push notifications so when us so say you were the patient and you made a call your call

once a doctor accepted we'd use the web socket connection to push a notification to the client

that the call had been accepted with information on like what state it was now in 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 you got the whole http overhead and all of

that yeah super that's really interesting so it's you know i don't know how it comes across on the

podcast but that's super interesting yeah i i don't know exactly like uh how how getting into

that level of detail will come across on the podcast but um oh the other thing that we used

that was successful once I got the configuration working

was Celery from the perspective of using scheduled events.

So if there needed to be timeouts on something,

like if something hadn't happened in two minutes,

using Celery for that was a very successful choice.

Although from an infrastructure perspective,

like it could also be frustrating at times

because it has so many little knobs

in terms of configuration, that the first few times that I started using it,

there were some deadlocks that happened at like 1130, 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

it for for any like errors that happened um so speaking of that what was it like scaling up the

team because you you said there's now something like 50 engineers I guess in terms of I don't

necessarily want to get into the hiring because that's this whole 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 are your sort of rules of thumb that you take away from that

that you're now applying to your new startup right because 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 yeah the balance between like

letting go and implementing has has always been challenging for me um and 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

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, by the way, you're now leading this team. You have one person

reporting to you, and you need to hire someone else. And I was like, wait, what? I remember this

was my first job after college. What's a vote of confidence? It was a terrifying vote of confidence,

to be honest. Like, it's 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. On Demand was very

attractive as like a first engineer because like 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 a longer term thing

And it's definitely a I don't know if it's entirely a personality difference or like some people, I think, just naturally seem to be better at it than others.

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

I think some people are get a little tired of coding.

So, I mean, I think 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 just read that book, Technical Managers, just came out two or three years ago talking about all these things and all these tensions from the woman who was CTO of, I think it was Rent the Runway.

Oh, cool.

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

So, yeah, I haven't seen anyone with an answer.

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

Of course, I live a hermit lifestyle for a reason, you know.

You're an IC for life?

Yeah, no, I do like mentoring.

I do like helping other people and working in a team environment, you know, to work.

help on other people reach it 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 that's why it's just and it's impressive

that you've been able to do both because it's either one is a lot of work and to do both

three times now um yeah it's not for the faint of heart so 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 AproHealth? What's been different, you know, on the technical side versus Doctor in

Demand, having gone through that journey? AproHealth is a medical billing startup. So

probably tackling a challenge that, you know, it sounds terribly boring. But if we get...

I mean, it's very relevant. 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.

But I was exposed to the problem when I was at Doctor on Demand when we, because originally we only took cash pay, which was very straightforward.

When we started accepting insurance, things got in order of magnitude more complicated than I expected.

And we were working with an outsourced medical billing partner who was supposed to handle a lot of the complexities.

And so watching the way that they operated, 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, because they both take, I think, a lot of time to fully understand the complexities.

Interestingly, my husband had been looking at various ideas because he wanted to

found something of his own. He has a connection with a family medical practice. And I was like,

well, for a doctor on demand, this is a big pain point. Maybe you should talk to your family's

practice and see what it's like for them. And I was not, this was several years ago,

there were like so many things that I wanted to do at Dr. 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 he started looking into that, also was looking into

other ideas. So it didn't really go anywhere for a while. I was working on Apero and then

eventually came back to it. 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 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'm just i'm just thinking of the dynamic of like not just looking at someone

else's code but a spouse's code i can't even imagine um what is this robin it goes both ways

right so it's it's also with django is it also postgres 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.

Well, I mean, it scales.

We just had Wenbin Feng, who wrote a popular post on the boring tech

behind a one-person tech company, was talking about lists and notes,

his company, and, I mean, if you can do it, if it works, it works.

Yeah, and when you say boring, or no, you didn't say boring,

but when you say it's pretty vanilla in how you would expect

if you knew the stack, but that means you're using it right.

You know, you're going with the grain of the state of the wood.

You know, you're not fighting it.

And then it does scale.

Then it does work.

I mean, that's what David Hennemeyer Hansen was saying with Pride when we talked to him about Ruby on Rails is that both Shopify and GitHub are now on vanilla Rails, whereas they had custom this and that over the years.

But, you know, it's a point of pride to be even at their scale on vanilla releases.

So, actually, so maybe that's a relevant question. Django just updated. I'm curious, either at Doctor on Demand or at APRO, how up-to-date were you all with the Django versions? What were those transitions like, you know, being hands-on?

Yes. I can talk about this now. At Dr. On Demand, it was something that I felt like I had to hide for a long time. But it's relevant to the point about vanilla rails. And it's also relevant to choosing dependencies carefully.

Yeah, that's always what it is.

Early on, I was actually, like, very diligent about keeping up to date with the versions.

And then, but there was one dependency I was using that needed a patch on something.

And so for that reason, we, like, forked Django.

And then we didn't have to after 1.7.

But the transition from 1.7 to 1.8 took a very long time.

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. Yeah. I think, I hope I, I hope I didn't already mention this

on the podcast but i've i i told carlton um someone emailed me the other day because i get a lot of

emails from people learning django saying yeah will um how do i which django apps are good ones

to use 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 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 I don't

know, Carlton, what are your thoughts on this? It's just such an interesting question.

i've been burned so hard so many times for this like i've wept tears of blood over third-party

dependencies that i wish i'd never installed so what would i do no no no like that process

have been different you know you have to learn you have to learn why it is that this pip install

magic package like yeah it's not a good idea folks like there are okay so there are there

are what a dozen or 20 or 30 right 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 got a

history they're reliable you know you know but yeah but be cautious so go on the there was a

post on the forum.djangoproject.com the django forum uh which packages do you like and that is

gold you know people have got i started that one right you still well well done but there were

you know 10 20 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

something came up on twitter the other day hash id so for slugs you want yeah yeah yeah you want

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 yeah well that i think that we'll link

to it i think i i think the question on the jenga 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 10 15 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 to

to provide a counterpoint 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 yeah yeah 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 you can't google for it but because

there's another package that also has it and like it looks like it i'll i'll have to find it and put

it in the show notes but it's it's what i used um as a wrapper around um redis queues and it worked

really well 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 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 easy to use interface um but yeah there are libraries

that i wouldn't start a project without but it's 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 i think it's a good rule of thumb well i'm just gonna say i like what you

said about like it it's only 500 lines i can grok it so 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 yeah

And that was one, actually, I think the dependency that I mentioned

is actually one that we upgraded to Python 3 because we used it.

I have to check it.

I think they open-sourced it.

Is it Django RQ? Is that the one?

It's just called QR.

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

And I was able to find it because it's one of Dr. Arnimand's public repos is QR3,

which is the Python 3 version of it.

just before we move on just um just like about going back to the history of Django like I think

that upgrade period between like 1.5 1.6 1.7 1.8 the whole migrations coming in and that was just a

you know that was a massive difficult period for a lot of people a lot of projects um and I think

it sort of marks the difference sort of up to 1.8 and then 1.9 1.10 1.11 2 you know it's there's a

a different world now right it's much smoother much easier yeah it's sort of changing and and

to that point i am level of the framework i am actually so grateful that we started with 1.5

and not 1.4 um because going from 1.4 to 1.5 would have been uh painful yeah so it's a different like

it's just like a different epoch in django's history right those early days to to now yeah

well and even uh 3.0 it just came out sounds like a big leap from 2.2 but i just updated a whole

bunch of projects and it's really not much of a leap 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 it's the contributors and tim graham again for like putting putting the systems in

place such that django has you know the stability that it needs as a mature framework yeah just and

wanted to ask you about, so you've given a tutorial on security, I think at least the last

two Django cons, and I haven't been able to attend in person, but I've gone through all the slides.

It's really fantastic. I wonder if you could just sort of tee that up in terms of, you know,

because I think you, what is that tutorial like? And I hope you keep doing it, right? In terms of,

I think 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 yes um 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 but the

security tutorial is again another thing that i i can't take credit for it's actually originally

um ashisha's tutorial that he gave at pycon um i want to say 25th 2014 2015 um

i 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 django con 2014 which was

my first ever DjangoCon. And I was crazy, simultaneously crazy enough to propose a

tutorial and a talk. And then the organizers accepted both of them from a first time presenter.

It was, it worked out fine.

Yeah, we'll link to that talk. That's a fantastic talk because you talk about

building out the early version of Doctrine and Demand.

But I was giving an admin tutorial at PyCon in 2015, and Ashish had sent out a request for TAs for a security tutorial he was giving.

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

It seemed like an awesome idea.

He set up a deliberately insecure Django web app, and then you go through all of the instances around 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 OWASP top 10.

And then your team that you were assigned to has a Heroku instance that you try and like find the vulnerabilities and you can see like why you're not supposed to use raw SQL and why you shouldn't put CS or F exempt on on things.

And, like, how a cross-site scripting attack actually works and what it looks like.

And it's a lot of fun because people, like, will do unexpected things to each other.

And, like, they'll find the vulnerabilities.

And then because you're working in a team, like, someone will come up with, like, people who are much better at JavaScript than I am.

And have, like, crafted their own, like, fun little things that are surprising for folks.

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

I loved that tutorial, and a couple years later, I met Ashish again and thanked him for doing it.

It was like, that was an awesome tutorial.

And he mentioned, yeah, I don't have time to work on it anymore, but if you ever want to take it, it's all open source.

You're welcome to give it yourself.

And so I did, I updated it from 1.4 to 1.8 last year, or no, when I gave it at DjangoCon 2018.

Yeah, last year.

definitely remember or maybe it was to 111 um regardless i i realized why he hadn't used one

seven because that was the most recent version because like django introduced some stuff that

made one of the vulnerabilities much harder to execute oh yeah in one seven 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 more secure

over the years and so i remember um complaining 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 going

to complain about django getting more secure i was like well yes but my yeah yeah it is well

and i think i don't i don't know if either 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 there is like the dev version and the production version and

for someone who hasn't done it before like i go into some depth in this in my book but it's

it's quite a leap to, you know, to understand what are the differences and then why would we

not just have it be secure all the time? And, um, and then it would be what, you know, I, I love the,

you know, pen test version of like hack this site, which is, I think, yeah, such a fun way to do

these, what can be sometimes dry things. 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?

Cause you only get five free accounts from Heroku, but it's doable to do that.

Yeah, I have a paid account.

But I don't think I've ever even, even with the tutorial, having used it,

I don't think I've ever had to really pay very much at all for the way it's being used.

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

And so anyone 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? Right. 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 you're definitely abusing the admin if it's your primary

customer support tool um that's that's one one key indicator um i forget did you put i don't think

you i've seen people like throw elastic in the search there i don't recall if you i remember

you showed you stepped through how to speed up like some queries i i did not do that but i know

um i know the woman who gave the talk about throwing elastic search in there and it's it's

quite a good talk i definitely encourage people to go watch that one as well i think she gave it

at django con this year or well we'll find it and link to it but i mean i loved i loved 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 just like some code you've memorized but i assume that came from

some real world examples of using the admin to do lots of stuff oh yeah the admin is a great way to

like get a quick overview of data and like make quick changes 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 don't want to give like a blanket rule because it's like it's such

a useful tool uh yeah but i think it can get tricky if it's like something that is externally

facing 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 yeah i mean you can

you can do a lot of permissions i i would i'll 100 agree you shouldn't show outside or customers

your admin panel i mean even and even you know basic thing the clue is the user model right it's

got an is staff flag and if you're not staff you can't log into the admin by default right so go

with that if everyone is staff you might be doing something wrong right but well right you know if

internal side internal app you know well i mean because you might have i don't know customer

or some support versus engineers.

Some people can do reads, some people can do...

The addition of view permissions, I think,

was really nice from the perspective of,

I don't know, depending on your perspective,

either making the admin more flexible

and more useful for more people, but safer,

or from the perspective of just encouraging people

to quote-unquote abuse it more.

I don't know.

That's potentially one of those,

like, we could go down a deep rabbit hole here.

Yeah, well, I mean, I think on some level

have to take responsibility if you have enough knowledge to customize the admin go for it i mean

not go for it but like you know it's a little bit how i feel like 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 without sounding trite with with great power comes

great responsibility yeah well yeah exactly 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 have your admin it's

admin like i was looking at some somewhat prominent django company and i was like i was

like i wonder if admin's exposed yeah it's exposed and then i was like you know doing past you know

so change that like i would rather you give outside access to your admin than have that

slash admin personally carlton you agree it's so easy to change it's so easy to change instagram.com

forward slash admin or whatever 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 got to change that anyway sorry your your talk though i think you focused a lot

on on queries right on speeding up i forget that that schema that you were dealing with yeah i

think an alternate title for that talk could be like basic usage of uh django debug toolbar for

analyzing um for analyzing queries and it just happens to be really easy to like demonstrate

that against the admin because it's very easy to create um oh in queries when when using the list

view so so one other talk that you've given that isn't technical i think was on becoming a parent

um i'm curious if you will link to that if you could share you know the non-technical side of

being a coach yeah um i think being a programmer has been simultaneously like a huge blessing when

when becoming a parent because it's fortunate that it's a it's a job that in some cases can

can be more flexible 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 oh okay 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 a number of conferences that

you're there because it actually makes me feel like oh man i should have brought my kids too

she she definitely comes along yeah um to a lot of conferences and it's been really fun as she's

gotten older and like different things 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 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 yeah i would agree and i think too i mean just for me

like i've i'm now my second year going to conferences 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 right jacinda thank you very much for coming on the show 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 yes thank you for thank you so much for having me and for like having a podcast for

the community and definitely very much appreciate all the people who who spend time putting out

content for people. Well, thank you for sharing your stack too, because I think we're not afraid

to dive into the details because for people listening, it is interesting. Thank you so much.

And I hope you have a great rest of your day. And you. That was Django Chat. We're on Twitter

at ChatDjango and join us next time. Bye-bye.