Transcript: Two Scoops of Django - Daniel Feldroy
Hello and welcome to another episode of Django Chat, a weekly podcast on the Django Web Framework.
I'm Will Vincent joined by Carlton Gibson.
Hi, Carlton.
Hello, Will.
And we're very pleased this week to have Daniel Feldroy, author of Two Scoops of Django, Django Crash Course, and many other packages in the Django community.
Welcome.
Thank you for having me.
Thank you for coming on.
So I think a lot of people who listen to this podcast already know who you are, but for those who don't, what's your quick background, how you got into Python Django, and then we'll talk about all the various hats you wear in the community.
Okay, sure.
So my I was born as Daniel Greenfeld, and then when I got married to my wife, uh Audrey, I became Audrey Roy Greenfeld.
I adopted her family name as my own just because it seemed like the right thing to do.
So just clearing that up right away.
A little bit about me.
I grew up on the East Coast.
Uh I spent most of my life uh nearby Washington, D.C., either north or south of it in Maryland and Virginia.
And uh I got into Python, started to get into it in late 2005, although I had the chance to go work for the Zope Corporation when Guido Van Rossum was there around 2000.
And except for it was about two hours away in Blacksburg, Virginia, and and it was you know back
then, right?
Yeah, and back then um Python was like no one knew what Python was, it was all Java, Java, Java.
So they called me in for an interview.
I was like, well, two hours to go for this obscure thing I've never heard of.
It sounds pretty interesting, but you know, I didn't have a car.
Just getting down there for the interview was like gonna be a challenge.
So I not so intelligently didn't go work with Guido Van Rossum and Paul Everett and all these other like personal heroes of mine that I'd love to have been mentored by.
Oh wow.
Yeah, not one of my better decisions.
Uh however
that's a sliding doors moment.
Well, and actually I think um Jacob Kaplan Moss is in Blacksburg right now.
Oh really?
As we speak.
Wow.
Yeah, his wife is doing veterinary school there, so there's lots of Python Django connections to that part of the world.
Yeah, absolutely.
Uh so in so I I programmed for you know a number of years um starting the late 90s.
Um I'm old.
And uh uh in 2000 uh at the beginning of 2000, actually sorry, the end of 2004, I had the job interview of my life and like the best job interview, and I landed a job at NASA.
And um at that point I was doing Java and I I really didn't like it.
Nothing against Java, but strong typing often just drives me nuts.
And so uh um I I discovered when I started working there that oh wow, Cold Fusion is is pretty awesome because it's you know it's Cold Fusion.
Uh because you know it it this loose typing is so wonderful.
And for those who don't know, Cold Fusion's typing is not that far off from like JavaScript or PHP.
It's very loose.
You can combine objects without there's not too much casting, too, too many problems when it comes to casting.
Um and of course, but I wasn't e happy either with Cold Fusion.
I was thinking, well, maybe programming isn't for me.
And in the summer, while I was there, I met this guy named Chris Shenton.
Uh and he said, um, oh, let me show you this thing called SVN and track, which is based off of a language called Python.
You should also consider learning Python.
And uh what happened then was a few months after that, I I finally had a little bit of free time.
So I was like, oh, I'm gonna download this Python thing and try it out.
And I was like, wow, this is this is awesome.
It it checks all the things that I really, really like about you know programming.
And I wasn't doing web stuff at this time, or if I did, it was just like little bits and pieces.
So then a few months after I started to play with Python, I was on this project where we were using Java.
And at that point, um the Java naming directory index, Gindy, I think it is, uh, which is how you connect with to LDAP and X500.
Uh I are those things used anymore?
I guess
they are, they are.
Okay.
But uh it could not connect to another NASA agent, another NASA center's uh X500 database because they had um rolled their own cert, their own SSL cert.
Right?
Right, okay.
Which, you know, you you're you know, back then you're warned, don't do this.
And this was actually even not even for actually it wasn't for LDAP, it wasn't for X500, it was for Microsoft Active Directory.
And so they had rolled their own cert, and um Gind D couldn't handle it, and we needed to connect to this.
So it was part of this project, and we were we were running up to our schedule, and we were trying to figure out, you know, how can we make Gind D work with it?
Um, and then Crescenton said, Hey, I got it working with Python.
And so then we created this little bridge script between Java and Python, you know, to try to make them talk together, and that wasn't going so well.
And we worked on this for I worked on this for months and I saw a deadline coming up, and then one day it's like, why don't I just rewrite this whole application in Python?
And mind you, like building the application in the first place and Java, this is enterprise Java back in the day.
Java's quite a bit different now.
Um it taken us taken me weeks to put it together.
And 90 minutes after I said, hey, let's get this working, I had it working, right?
So 90 minutes compared, and so I was like, oh my god, the productivity boost of this is incredible.
So it's not like Cold Fusion, which I I don't know about now, but back then it was very limited, and Java, which just wasn't working.
Um this just it worked, and it and the speed difference because of what we were doing was pretty inconsequential.
So at that point I was I was totally sold.
And uh Crescent was like, yeah, I got another one, because he was the only one who liked Python at at our NASA center, which was headquarters.
And so then, but the thing is is it wasn't really accepted because it wasn't one of the the big three languages that we use, which were Java, Cold Fusion, and uh anything in the Microsoft stack.
So then this is my favorite part.
So we we started using it surreptitiously.
We called ourselves the Python Underground.
Well, we had
there's nobody noticed the dot py.
Yeah.
Uh so um we started using it surreptitiously, and we found that all these project managers who had all these little scripts and actions that they needed to do, um, you know, found out that Chris and I were the two people who could get these little scripts and uh done for them.
These little like we'd come up with Python executables, I forget the name of the tool that we use, that would work on Windows, you know, and uh we we would put it on their desktop and then they would point that at spreadsheet data, for example, and it would um like uh pull, you know, it would it collate the data as they need it, or it would hit the X500 or LDAP or um active directory systems that we're often interacting with and grab their
data and clean it up.
So rather than ask someone to do it and set up this big project where they have to go get funding, they just go to Chris and I and say, Hey, can you can you do this?
Because it wasn't an accepted language.
There's it would have been almost impossible to get clearance.
And yeah, over the course of about a year, that start that that reluctance to use Python changed.
Actually took several years, but within about a year, we we got onto an active project, and it was a Plone.
Project Plone is a older CMS in Python, it's the precursor to Django and a Flask in that whole environment, uh, or that whole e those ecosystems.
And um that is kind of my story how I got on board with Python.
Uh that's really cool.
That's really cool.
So we
were there.
I like the way you go ahead.
I I like your like oh, and you know, I had it working in 90 minutes.
Like it was my experience coming to uh Python simular in that I'd be like, oh, I'm I'll try writing this in Python.
And you know, no matter how complicated it was, it was always like just 150 lines and you know, fit in a single file, and it was like, this is nice.
Yeah, yeah.
Uh so that's that's my story of learning Python.
And then with Django, several years in, we were um, you know, we had launched a Plone site, we had a public Plone site, which might actually it got converted to Django, and then we um for for the project that I'd built in 90 minutes, originally I wanted to serve out the data using Django, but because Django wasn't at 1.0, in fact, none of the Python web application servers were at 1.0.
I wasn't allowed to use it.
So um we hid, like we made the mistake of talking to managers about the version numbers of the application frameworks that we're using.
And since none of them were 1.0, we couldn't use any Python web application server.
This is a very different time when if your software didn't have like version three or version five, you you couldn't sell.
And I know there are still places like this.
So what happened then is we didn't tell them that web.py was below version one.
We just didn't give them a version.
So my first application was built with uh web.py.
But a few years later, we were going to build a NASA social network um that we were gonna call Spacebook, and we decided we decided that we're gonna use um Django for it.
And uh because then there's a suite of tools called Pinax that was out there, and so we built it on um Django and Pinax, and that was Spacebook.
Uh the the problem there is that we were competing with several other, at least one other NASA social networking tool, and someone chose an enterprise Java one.
And this is like 2009 era Java, so it's not modern Java.
Java's really changed as a language, and also the whole I I don't know if EJBs and all that stuff still exists.
So it was the the the application that won was not the popular one, it was the one that where they had the pull with management.
Um nobody ever got fired for using Java, right?
Um no, I don't think so.
Probably not.
Um nowadays you can say that about Python, which is exciting.
Yeah, it's Django.
Yeah.
Yeah, I mean I I I still like the story of when I was flying back from PyCon last year.
The woman next to me was I was had the you know the the gear and she worked at a government defense contractor that used Java, and I said, Oh, are you switching to Python because it's better?
And she's like, No, we just can't hire anyone under 40.
So they're switching, as she said, just for higher ability for recruiting reasons.
Wow.
That's that's so awesome.
Yeah, I was like, Well, that's that's a change.
And then also I I asked her, you'll appreciate this.
You know, I was like, Oh, well, you know, have you heard of Django?
She's like, Yeah, I've heard of that.
I think people use that.
I was like, oh, you know, how would someone learn that?
And she said, Oh, and she pulled up, you know, corporate subscriptions to O'Reilly, uh, you know, the big three, what is it?
Um, you know, so she pulled down it's uh so it's Safari, um, lint lynda.com and plural site.
And she said, Yeah, here's 60 courses.
Um, and I was like, but how do you know which ones are good?
She was like, so that kind of broke my heart, but I was happy about the Python thing.
Anyways, digression.
Yeah.
Well, I mean, at least there's 60 courses with Django that she can find quickly.
Yeah, it was something it was some huge number, and um you know it was a good insight into the corporate realm of like, oh well, we need training for this.
Like, here you go, and um in a large company's HR makes that decision, and they want to, you know, they'd rather write one big check than lots of smaller ones and give autonomy to employees to make those decisions.
Um that's pretty good.
Yeah, we've we've danced around the subject of um doing um O'Reilly's Safari for years.
And um we we might do it this year, we'll see.
Um Yeah, I mean I'm not slamming those those platforms.
There's I think they make they can make a lot of sense and there's fantastic content on there.
Um it's if you're in the indie bucket, which you and I are, right?
It's a little it's you have a different perspective on it.
But I totally get how for large companies they don't want to I I wish they would just say, here's a budget for your employees, you know, X number of dollars for professional development.
But aside from GitHub, I think almost no one does that.
Instead, it's here's the corporate account for for whatever.
Yeah.
Um, well, one that part I guess my issue with it isn't so much the platform, it's having to go through O'Reilly.
I I'm trying to convince um Bill Pollock of No Starch Press, which is awesome, awesome company.
Um I I think I'm gonna go and try and convince him.
Hey, can you can can you talk to O'Reilly about this?
Because I don't want to try and go through that process again.
We tried actually last time and it was just they started to make us jump through hoops, and it's like, we're we're indie authors, why are we having to jump through hoops?
So um it was kind of weird.
Do you are do you work with no starch?
I thought you were self-published.
No, we're we're we're thinking of going and asking Bill of No Starch to um to be like, hey, can you can you represent us with O'Reilly?
We'll we'll figure out some way to make it worth your while.
Yeah.
Well, I I mean I agree, no starch seems to be at the very top of technical book um publishers, and certainly there's a lot of.
They certainly pay the best of of the I I believe they do.
They pay the best.
In royalty rates?
In royalty rates, yeah.
Yeah.
Well, they're public about it.
You can go and look it up.
Yeah.
Um which I think.
That's that's why I'm pretty certain that they're the they're they're the best ones, just because you can find the royalty rates and then they're they're pretty high.
Yeah.
Well, it is true.
I mean, we don't I'm sure you and I could talk about the you know the issues with self-publishing.
I don't think people really care about that, but there's a lot that goes into it.
So it's certainly often a appealing idea to have someone else team up and handle distribution and all of it.
Uh-huh.
And you because I think it's so maybe we can segue to um to two scoops of Django.
So when did um because I remember you, I think because you and Audrey were hand um mailing those back in the day.
Maybe can you talk to how you you both came to to write that book and do all that?
Sure.
So uh let's step back in time to 2012.
And we weren't married yet.
Uh uh, we were engaged.
Um and we were running this consultancy called Cartwheel Web.
And we're also doing a lot of open source work and community work.
Uh that was the year that um she and six other women founded Pie Ladies.
Uh, and and this is in Los Angeles.
Uh and so we had a we had work coming in, but collecting the work often was hey, fix our Django project, which did the consultants, the people that we hired, um, started to work on and and left.
Um and so it was like these, you know, rescue projects.
That was almost all of our work.
And our new work coming in, um trying to get people to actually pay was really, really hard.
Um, so where the money was was coming from was these rescue projects.
And again and again we saw the same mistakes um where the people started projects and then just through in you know, just through not knowing how to build applications in Django, um they made design and architectural mistakes that made it really hard to finish their projects.
And so what would happen is you'd have people who would, you know, the entrepreneurs or investors would scrape together what of what money they could, give it to a developer who just because they they they didn't know how to finish the application, they would get bogged down and then they would quit out of desperation.
We saw this pattern again and again.
So after the um and the these projects were exhausting to work on.
If you've done software work and you come into like just a horribly engineered project, it's it's it's draining, it's not fun, and and we prefer building new things.
It's horrible to um not horrible, it's difficult to keep it working whilst you'd make the changes, right?
Yeah, so you're constantly up against, you know, this barrier where you're like, you can't break it, but you need to move all these bits around here, and how can you pull that apart?
And that kind of mental exercise is just ah exhausting.
Yeah, and then a lot of times the people who would hire us to do this, their budget was nearly blown.
So they they wouldn't they would be struggling to pay us and they would pay.
Um, and then for these new projects, um just, you know, we we we couldn't get paid.
Like we'd do some work and then they would stop paying us, which put us into a financial bind.
After I remember this one day where um we went and we talked to this company who um they decided to go with someone else and they told us who they were instead of us, this is for a new project.
And it was someone who we had rescued two projects from in the past.
And and and this is on the Los Angeles area.
And I was just like, oh my god, like it, you know, we're we're gonna end up picking up their leaving again.
I was so angry.
And so I was like, I'm tired of these rescue projects, I'm tired of you know, uh these people coming to us who are now broke saying, Can you fix our project?
I'm tired of um these engineers saying, Oh, this is why we should be using Rails.
And uh and so I was really angry and I started to and and I went to um I was hanging out with Randall Daggs, he's a friend of mine, some other people at a the local Django group in in Los Angeles, and on the way back, uh Randall had just released this book called Heroku Hacker's Guide, which is like this brilliant book.
Yeah.
And we we stopped to get something to eat, and it was at um an ice cream place.
And because I was like, I'm just gonna get ice cream because not on the diet, but I didn't care.
And uh because I was angry, and we were talking, and and somehow the discussion evolved to you should write a book about Django if you're running into all these same problems again and again.
You you know this, you've worked with core Django developers.
Uh uh, you should you know write a book about it.
So I was like, oh, okay, I'll write a book.
So I started writing two scoops of Django, actually, it was originally called real world Django out of anger.
I was so just and uh uh so I I was like, okay, I'll be like Randall, I'll write it in a weekend.
Because he wrote Heroku Hacker's Guide in a Weekend.
It's a smaller book than two scoops of Django, and Django's a bigger topic than Heroku.
So the book kept growing and growing, and worse, I kept getting stuck.
And so I'd look to my fiance, Audrey, and I'd say, Can you help me with this?
I'm stuck.
And so she'd help me out, or she would rewrite a section.
And then after about the fifth or sixth time, I was like, Why don't you become my co-author?
And she said, I would, but you're you're too angry.
I don't want to have my name associated with something that's angry.
You have to make it happy and funny.
And I was like, that's so weird.
Uh and so I was like, okay, we'll we'll we'll make it happy.
And uh then she's like, all right, well, we need to have a good topic for writing code examples for because you know, these code examples that you have, like they're just switch topics all over the place.
I want to have a consistent topic.
Yeah, and so we brainstormed and then we came up with ice cream, and uh, because you know, that was once a week I broke my diet and we would go get ice cream, and uh we noodled, you know, we brainstormed some names after that, and eventually we settled on the silliest name we could come up with, which was two scoops of Django, because there's two of us scoops, ice cream, Django.
It it kind of all worked.
Uh so that's that's the story, the name of Two Scoops of Django.
Yeah, I didn't know that.
Yeah.
Can I ask what
started in anger?
Well, you have um I do want to stick a stick on two scoops, but in uh Django Crash course, your new book, you have a lot of cookie examples where you I was curious where those came about.
You mean cheese examples?
Oh, cheese.
Wait, yeah, cheese.
Yes, you're uh I've I'm only the beginning part, but you're um it seems like there's a cheese theme running through it.
Yes.
And I love cheese.
I've never had a cheese I didn't like, so I approve.
So we've I guess we have a fixation on dairy products.
And for the listeners out there, we we do want to say we recognize you can make cheese and ice cream out of non-dairy products, and we've had some really good ones, so we we don't want to disparage uh cheat, you know, non-dairy versions of these things at all.
Uh so we we really like cheese, and um on our trips we we that you know, we've had the chance to to travel a bit for for work.
Uh we've oh whenever we go someplace we try two things.
One is ice cream, uh just because every place does it slightly different, and the other one is cheese, that uh there's pretty much every culture in the world that at least that we visited has cheese.
And if they don't have cheese, they're working on it.
So, like uh for example, we discovered um the last time we're in the Philippines that there is in the highlands, that's up in the mountains, uh, where the temperature is cooler, there's a growing um blue cheese movement that they have, you know, that their livestock, that they're they're um goats and and sheep and stuff like that that they have up in the mountains where it doesn't get warmer than 65 degrees any time in the year, they have these her
ds of sheep and goats now that they are cultivating cheese, and it's it's pretty good.
I mean, we tried it in t early 2015, it it actually was shockingly good.
So, um, yeah.
So anywhere on the planet now is getting into cheese.
And can I just ask, um, I think did you and Audrey meet at a PyCon conference, right?
Isn't that Yes?
Do I have that right?
Yes.
We met at PyCon US 2010 in Atlanta, and we met in James Bennett, he's a old-time core Django developer.
He was running on the book.
He's on the Deborah.
He's on the board.
He's on the board.
Um uh we met at the end of a Django tutorial that he was teaching there.
And uh yeah, that's we I was sitting next to someone who she who Audrey recognized, and so Audrey came up and said, Are you so and so to that person?
And then um I turned and I was like, Oh my god.
Yeah, so for me it was it was nearly love at first sight, but it was a professional event, so I I like was respectful and not right, yeah.
So that but that's where we met.
Awesome.
I I I think I'd I'd heard I'd heard that, or you had mentioned to me.
I I love that a little bit.
Um, but so so two scoops.
So you were just at the point where uh she was gonna join as the co-author once you adopted the ice cream theme to make it happier.
Yes, so uh yeah, so she joined and she ha has written over half of it.
So I am the vocal one.
Um you're the I'm the one you tend to see on social media, but she is the the power behind the scenes.
Uh and not to say that I'm stupid, but she's smarter.
Uh and I have a similar dynamic, so I'm familiar with it.
Yeah.
Uh and um when the first edition was a few weeks out from being delivered, she stopped writing one day and started doodling.
And I'm like, what are you doing?
And she says, I'm doodling and I'm I'm drawing, I'm drawing.
And I'm like, but we we have like so much more to do.
And um, and money was getting tight because we weren't working, working on that book is a full-time effort in in any edition.
And and I'm like, but we we have to get this done.
And she's like, it if if I don't do this, the book isn't gonna sell.
And I'm like, I I thought she was crazy.
And she started Audrey is is uh a visual, amongst other things.
She's a visual artist, she does sculpture, she just does painting, and here she's doing these cartoony style doodles, and um, you know, she kept showing them to me, and they're these cute little goofy drawings, and and I'm like, what are you doing?
And so she um she said people need a break because even though we're trying to make it funny, um it, you know, technical material is dry content.
We need to break it up with humor.
And so I was like, fine, and so I humored her, I'll admit that.
But then once we started putting it into the pages, it started to make more sense.
And um that is where you know she started do to do those, you know, those illustrations in the book, and um, we know that makes a difference because people send us screenshots of those from around the world.
So we're I'm pretty happy she did it.
And um, yeah.
It was super.
I wanted to ask what was the first edition?
Because I was looking through my gum road the other day, and I I saw in my library a 1.5
that is that is it.
It was for 1.5, and um, you know, we had this funny thought that uh we would do a new edition with every release of Django.
Yeah, why not?
Uh why not?
It's it's easy, right?
Um we can just we'll put out a new book every six months.
And uh the the the scope of work involved in updating this particular book is outrageous because it's not well, one updating tutorial books is hard.
William will, I'm sure, can talk for hours about that.
Yes, I try not to, but yes.
Um uh with two scoops of Django, it is harder because we have to refute everything in the book.
It's would refute be the right word?
Uh, but we have to double check everything in the book.
And so every package, every every statement, everything that was a fact at the time a current edition was released, um, is just so much work.
So yeah,
it's a big Jenga puzzle, is how I describe it to people.
You think one little thing, but
but you do that, you do something quite hard as well, which is you recommend packages, third party packages from the ecosystem.
And that's brave.
Yeah, you know, yeah, that's
I do it too, but very reluctantly, and I always get hammered for it.
The same as whenever I show how to do something on Heroku or SendGrid or Stripe, inevitably they change it faster than Django changes.
Yeah, and also there are people who want to have their package featured in your books.
Yes, yeah.
And so sometimes you just, you know, it's why we will often explain why we chose something.
Um, but yeah, that's we've we've certainly made our share of people become our enemies in the past.
And um the thing is, is we have one, we have to be a bit opinionated because that's part of what the book is, um, because uh that is actually it's not number one, it is the the fact we have to be opinionated because people will base serious bus business decisions that affect not just a company but um whether or not they get paid based off of what we put in our book.
So we have a responsibility to our readers, and if we make some enemies, I'm I'm so sorry.
And maybe maybe we don't always handle that gracefully.
We try to, but um uh yeah, it's it's a hard one.
So I you know I remember you reading your choices, and I remember being like, Yeah, great, great, brilliant, brilliant, brilliant.
But those packages come out of day and to keep to remake those choices each edition is like you have to verify that this is still the best option.
Yeah.
Yeah, and it's easy to get colored by uh your friends.
Um, and so uh if a friend has a package that they maintain or that or or that they just believe in, it's like okay, we we just can't, yeah, it's it's tricky.
Um well in a in a minor way, I have this issue with Awesome Django repo um that's two years old now that only has it has like a fraction of the stars of Cookie Cutter, um, but it has I think almost 2,000 stars, and it's largely a curated list of third-party packages.
But I I you know I everything you said, like I'm starting to really feel it, right?
Where people just put in pull requests and sometimes I know them.
And a lot of the times it's like, well, if it doesn't have a lot of stars, and or I haven't used it, and I always say, like, this is just my opinion, and like it's not meant to be canonical.
That's that's kind of what I like about two scoops, though, is that you you and Audrey tried, and I think basically succeeded in saying, you know, as we write this book, this is these are best practices in the community because people want to know those, and you know, maybe there's in total agreement, but largely there is, and someone needs to kind of say it and have the expertise to back it up, I would say.
Yeah, I I've wondered about those awesome Django um lists, how how those are maintained.
Well, they're not so yeah, the so there was one before, and then I think two years, three years ago, and then what the problem is, I mean, what always happens is they just blow it out of control and you get endless PRs and you just go, oh stuff it.
Um and so my way of dealing, so there was so the my way of dealing it is I just I try to be very public on like I'm just gonna look at this periodically and it's my choices.
Um, but it's you know it's unpaid, right?
So at some point you're like, I don't need the negativity here.
Um yet there is a value in curating things, right?
But then but you constantly it's I mean, usually it's helpful.
People do PRs saying, you know, Django Rest off switch to DJ Rest off hosted by Jazz band and all this stuff, but it's it just becomes a a lot and it's like a lot.
So and then there's the personal stuff of right if I I feel bad rejecting things that from people I know or or just in general, but there has to be some sort of baseline on it, otherwise what's the point?
So that's what happens.
That's I think that's that's what I see with awesome repos.
They bloat out, people get tired of it, they stop maintaining it, and then someone forks it, and that becomes a new one, and then it repeats every three to five years.
Yeah, right.
But at this point, at this point, we have to bring up um the project for which I first came to know of you, Danny, which is Django packages.
Because haven't you got exactly the same?
So Django packages a site where you can well, okay, but this this is the question, right?
Um, you know, it's this great site where you can go and browse by, you know, you need something for authors, circuit authors and it'll show you the packages, how many stars they've got, how many.
I mean, how did you manage the same problem there, keeping that updated?
People just submit or um
user generated.
Um because it started in a hackathon uh called uh it no longer exists, called Django Dash, which is run by Daniel Lindsley.
Um, there were some early design decisions made, you know, on no sleep that make it a bit harder to maintain.
Um and then there have been some pull requests accepted that shouldn't have been accepted.
Uh we're we got better at that.
So it's it's a hard project to maintain.
And at this point, Audrey and I um were pretty much stepped away from it.
We've we've tried to hand it off um several times uh for various reasons.
Some of them related to us, some of them relate to other people.
That's never really worked.
Um, so we we have a few trusted volunteers working on the source code.
Uh the primary one right now is a guy named Vibaev Jane, who's in India.
He's awesome.
Um, but uh main, you know, we yeah, it's it's a critical project.
And uh I don't know, I can't remember.
What's the question?
I'm on like no sleep.
Well, just like how do you so the the issue?
Why create Django?
We just talked about the challenges around third-party packages.
Yeah, I mean, and keeping the lists up to date of what are the third party packages, you know, because we start with two scripts of Django, and then the same issue is um with the author Django repos, and then it's Django packages.
Like, how do we Django package curated?
Right.
Django packages is a mix of curated data maintained by the users of the system.
So if you're listening to this and you have opinions about Django packages, you can enter your own data there.
But it also pulls stuff like GitHub stars and PyPI downloads.
I think it still grabs that.
I I'm pretty sure that data is available.
Um so it grabs a mix of hard and soft data so that way people can make an informed decision.
And we don't let people uh and there are constraints, like there's administrative tools that we visit.
So when we find junk data on there, we we strip it out and we block users.
And if but um like listeners quite often say, Oh, how do I get involved in these kinds because there's Django packages or Django snippets, which has got a new maintainer now, and you know, there's other other um kind of sites in the community which are built with Django.
People if people want to get involved, can they do that?
Can they become a a a trusted contributor?
Um I mean obviously you have to build the trust, but
yeah, you have to build the trust.
Um for us, um we because we do not visit Django packages, what usually too often, um basically when Vibe or one of the other people who currently work on it ask us to get involved, that's when we get involved.
Um but what I suggest if if you want to get into these projects, um uh you know, it can start with triaging issues uh or submitting pull requests, and then once um uh once the people are currently working on these projects get to know you and you can build that trust, then perhaps you can get core maintainer rights.
Um it is not a quick process.
And with popular projects, even if they started out relatively simple or beginner friendly, uh Django packages started out pretty beginner friendly.
Um, it is old enough now that it is not beginner friendly.
Like if you're just starting Django, um, there's enough weird things in Django packages that it's probably not the project for.
You need to have a solid grounding in in Django and Python to be able to contribute.
Um so I hope that explains that question.
I'm not coming across too sleepy or amped on coffee.
No, no, no, no, no.
Okay.
No, you have to find it.
Well, related to mature packages, I I want to ask about both cookie cutter and then Django Cookie Cutter.
Or Cookie Cutter Django.
Do I have that backwards?
I'm I feel like I'm slightly dyslexic when it's like lacking sleep.
People switch out one all the time.
Okay, so Cookie Cutter, um, Audrey started that one.
Um she uh wanted a she actually was working on static site generators and um she wanted to be able to she came up with one, but the boilerplate that sh was required to get it working was a bit much, so she decided to come up with a um template manager for it, and that that prompted the creation of Cookie Cutter.
And then for some reason she she got fixated on several things.
One was she only wanted she didn't want to have any classes in the project, those any that exist in the code there were added, like defined classes were added after she pulled away to do other things.
Um, and then she also wanted it to work on every operating system, uh, so that Windows users were first class users.
And thanks to Paul Moore, um, go ahead.
I was gonna say that's very prescient.
Yeah, because now you know when Python support on Windows in the last few years has just you know blown blown you know gone gone on leaps and bounds.
It's now a great place to do Python.
Yeah.
Um well we have stories about that.
Um so thanks to Paul Moore, who's who's an awesome guy, he helped that out in the early days.
Um it it got to a point where Cookie Cutter worked on Windows.
Windows was a first class language.
Um there's still pull requests for Linux specific or OS X specific features, and um those are rejected just because we we can't.
Um uh so and then I wrote a blog post about it, and she you know, she I was like, hey Audrey, can you give me an image for a blog post?
And then she threw together the current logo in 10 minutes, and she's like, This is a placeholder.
And of course,
these horribly talented people.
I know, yeah.
And so coming up on seven years later, it's still the same logo.
Uh so um, yeah, so the the project has done really well.
Um it's you know, we know of all these companies who exist who use them some, you know, internally, or um if you are downloading their command line interface tool, a cookie they're actually using cookie cutter.
Um that's how they render out templates, that's pretty common.
And um the um and they pay us the uh that we actually make money off of it, and it's not enough to go to a fast food restaurant every month, but you know, all these companies um who who these billion dollar companies, they certainly do do pay us.
And we're we're very happy that um I think we're up to twelve dollars now a month.
So we're living large.
Is that GitHub sponsors?
Actually, I don't you don't have GitHub sponsors.
Um we've been slowly working on that.
We're we're yeah, um uh we're not it's funny people said, Oh, you're good at marketing yourselves.
Like, yeah, but we're not good at getting paid from our marketing.
So um we kind of we're kind of cynical.
We're kind of cynical that we'll make any money from GitHub actions.
We certainly haven't with Patreon or other open collective or other things that we've done in the past.
Yeah.
Well, I just as an aside, I mean we Django uh added GitHub sponsors the end of last year, and uh obviously there's attention using it in intermediary versus doing it direct, but it's so far has been a good experience.
So oh awesome.
Well, we the the thing is is Audrey and I are not uh you know, we only get involved in cookie cutter periodically and in a lot of our open source packages, just because the honest truth is is when you go for so long without getting paid, it's hard to continue to work on stuff.
So we've let other people take over maintainership who are getting paid by their jobs to to maintain these packages.
Um and that's that's really an economic decision.
And while GitHub actions might make it possible now.
Sponsors, right?
Because Actions is the um
Oh, sorry, GitHub sponsors, yeah.
Um that might make it more possible now.
Um we're we're involved in other things now.
Yeah, it's always a priorities thing.
Yeah.
But speaking of passing the batons on baton on, then we should quickly talk about Crispy Forms because you were one of the um creators of Crispy Forms, all the creator of Crispy Forms.
Yeah, I am the creator of it.
Um I was at NASA.
Uh we get I guess we're going back there, and we for Spacebook, the you know, this Django project that got killed at launch.
Um so we had 80 forms that needed to be made u accessible to users with disabilities.
Um it's it's a US law that we have to, you know, US federal government projects have to follow um section 508, which is for accessibility for people uh vision or um various vision disabilities in in this case for the web.
And fixing AD forms to work that way seemed like too much.
So I created a Django template tag and I I made it as an open source package.
Um uh that was um, you know, I threw that together and then it it grew organically from there.
Uh eventually, um, you know, with the consulting work that I had, it was uh too much for me to maintain that by myself.
So um I I got on another person to work on it.
And at that point, um the library that we're using, the accessibility library, was unmaintained.
Um it was like this HTML and CSS library called Uniform.
So we decided to change the name and call it Crispy Forms.
Audrey suggested that.
Um she never, I don't think she ever contributed that much to it, but she gave it the current name.
And so that is um, and at eventually we decide to move it to its own organization.
It just makes it easier for people to set up, you know, continuous integration and other things like that, if you're or to maintain those things.
I'm not I'm not being called in.
So yeah, that's the story of Django Crispy Forms.
Yeah, so what well but I like so I took that over, like so.
Oh you're
gonna do that.
Well, well, I'm well, this is the great story of open source, it's right.
You you began it, Miguel was there for a long time, and then uh around the time of 1.8, it was it was falling over.
1.8 was due to be released, and crispy forms wasn't going to be compatible.
So I was using it, and I'm like, well, you know, I'll jump in.
And I I took it over and kept it going, and you know, we added Bootstrap 4 slowly, with you know, because I I was doing it and you know it took a while for that to mature, and that's quite mature now.
And then recently I was I've been struggling to maintain it.
What with the Django work and Rest Framework and Django filter, and you know, working on trying to work on channels as well.
And crispy forms wasn't getting loved, so I last year I put out a sort of call for help.
I said, look, you know, if you're using crispy forms, we could do it.
Two or three people turned turned up and do it, and now it's got a brand new maintainer, a new release, and there's going to be another uh template pack for Tailwind, um, which is the new CSS package everyone raving about.
And so Crispy Forms is as healthy as it's been in in years, and it's you know, it it's like this long continuous past the baton thing.
And I imagine the people who've just stepped in, they'll run it for you.
I'm still there, I'm sort of offering advice when I I can, but they're running it, they're releasing it.
The recent release was the first one that I haven't pushed out in four years.
If someone else did it, and it was like
yeah, it's it's when that happens, it's like, yeah, and someone else has picked up the torch, like, but it's my baby.
And uh
but it's like so it's so good because it's like yeah, the button moves on, and you know, and then as I say, there's now there's now a few contributors working on it.
That's that's perfect.
Yeah, that's that's so wonderful.
There you go, that's a feel-good open source story, right?
Yeah, too often it's the negatives.
Yeah, there's
I've tried to to say positive in this.
Um no, that's that's the But the
the if the issue with open source is one person can't give hours and hours of volunteer time just in it c like without end, right?
And it is without end.
And so you do your you do your season and then you need to step back.
And if you if you don't come with the expectation that you'll do a bit and then step back, that's when you get burnout and all the real big problems that you know we've seen so many times in the community.
Yeah, I think Tom Christie has really um shown how to handle this because I think um you know with Jenger S framework, I know he's involved there, but he's he has um one, he's I think he's getting continuous funding that supports him and his family, but also he's gone and built other stuff like Starlet.
So I really respect what he's done, and I've at times I've thought maybe I'll I'll copy that.
Um, you know, that's we'll see.
I uh you know uh he he started with um a Django Rest framework, which is a critical package, so that that certainly worked for him.
Yeah, yeah.
Yeah.
I was waiting for you to add something, Carlton.
I mean, on uh I mean I know he's
it's it's it's the perennial problem, right?
Uh even he s has some struggles with that, but I think just as a developer, having that mix of a stable package that's widely used, and then he has his I mean he's rebuilding the whole Python stack async style and doing incredible stuff with Starlet and a whole bunch of other things.
So just as a creator, right?
He's not endlessly updating old Django books, right?
Speaking of burnout.
Yeah.
Um I did want to I I know we're we're going over on time, of course.
I want to ask about Cookie Cutter Django and then your um uh your the updates to two scoops and then Django Crash course.
So whatever order you want to tackle those three.
So alright, so I'll I'll try and cover that quickly.
Cookie cutter Django or Django Cookie Cutter.
Um they're you know uh it is it's still out there, it's still being maintained.
Um it is there's a day when it was all about bleeding Django, now it's all about super stable Django.
Um so the maintainers, you know, they'll they'll get around to supporting Django 3 at some point.
Um, but they have to make sure every package that they are relying on works with Django 3.
And um, and that's that's a bit challenging.
And and periodically when they come to me and they say, hey, this is you know, we're having trouble keeping this portion of it working, and I'm like, is is maintaining another version of Linux out of scope?
Like try always try to reduce the scope um because cookie cutter Django is so broad.
Um and in fact, when we started to um convert Django Crash course to be a book rather than a course, we um originally we were gonna do it in Django Crash or sorry, in Cookie Cutter Django, but um one that wasn't ready for Django 3 and 2, it was so broad.
Like the this since I've pulled a bit back, um, it's gotten really broad, which is hard on the maintainers, it's also hard on the users.
So um that is why Django Crash Course doesn't use Cookie Cutter Django.
We just needed something with a narrow scope.
These are the tools that we're using.
Can I ask why you you recommend Anaconda in the book?
Because um virtual environments are the bane of professional and beginner Python developers.
Um, but Anaconda was an interesting choice, so I'd love to hear your your reasoning on that.
Um it's to support primarily the Windows users.
Um uh not too long ago, I the the computer that I'm talking on uh was bricked for several weeks.
And so I I started to use Windows and trying to get binaries to work with virtual end was nightmarish.
And I had people say, Oh, just use Docker.
And it's like, but I I don't want to use Docker for everything.
Well, and Docker had a Windows-specific bug recently that my users were reporting, so even Docker on Windows, you know, it doesn't save use.
So by using conda and chocolatey, chocolatey is like the homebrew of uh or homebrew of Windows.
I know there's a competing package, but Chocolate for me was awesome.
Um, but conda also let me get past um all of the binary issues.
I just stopped having to worry about it.
And I know that conda has some things that experienced users don't like.
And honestly, um, and I think we might mention in the book, if not, it's it's on our to-do list.
We mention if you want to use a different tool chain, go ahead.
Um uh you, you know, for you, that portion of the book you you don't need to care about.
The use of conda is for um, for example, data scientists who are already using conda, um, because conda is so prevalent there, because conda makes installing all the data science packages trivial on Windows.
It makes installing um uh the yeah, tons of libraries are much easier to install on Windows using it.
And nothing against pip or poetry or other these other tools, but they are not um their focus is not making it easy for people to run binaries on Windows.
Yeah, I may like just open, lift up my visor a little bit and look out because I'm busy on Windows using uh pip and VM, no problem, and then realize that there's this whole world of folks out there that aren't necessarily in the web Django world but are using conda and you know it's very popular.
And they're like, well, what's a VM?
And do I have why do I need a VMware?
Or if they use PyCharm, which handles virtual environments, um or well, and even um so mini conda, the if you want to use a Chromebook, uh I recommend that approach.
Like I have a tutorial on that um because Chromebooks are starting to give access to just straight Linux and using uh what did I say, mini microconda is the easiest way to do that.
Oh wow, it's a good thing.
So on the install python3.com site, which I run, uh you can the Linux part uh part recommends that.
Because that's a big thing, is that Chromebooks are ubiquitous, but still it's hack city to actually write code on them, unfortunately.
You can do it, but installing Python is non-trivial and but you can yeah.
It would be nice if there was a sub thousand dollar machine you could do code on.
Yeah, especially
Raspberry Pi.
Well, everyone just uses replit and stuff instead, so they that's how they get around it for students anyway.
Yeah, I mean, especially um and the thing is students often don't have access to the funds that us professionals have.
So they are working on whatever machines are hand-me-downs that they can get.
Um, and they're often working in really disadvantageous circumstances.
So the use of conda is focused is for them.
Um another problem with having Docker on a Windows machine, and maybe this isn't the so much the case now, maybe it is, is that for them, Docker is uh, you know, it uses up a lot of processes.
Conda is just
on a Mac too.
Lightweight.
Yeah, on the Mac
Like someone just someone just bought a new MacBook and they're like, yeah, 16 gigs of RAM, I'll never fill it.
And I was like, are you using Docker?
Because that'll take up eight.
Easy.
Yeah, or they're they just have slow bandwidth.
And so um, whereas and and Docker, you're using Docker is oh my, you have to be on fast bandwidth.
Yeah, because you're putting these 500 mega megabyte containers or gigabyte containers all the time.
Yeah, well Python is Python standard library is a 700 megabyte image last I checked, for example.
Um but you you install it once.
So that's true.
No, on Docker you might install it multiple times.
So yeah, so that's that's another reason why we decide not to go with Docker, having worked with people in lots of different countries or just in the rural US, which for the most part doesn't have broadband internet.
Um, you know.
Yeah, no, I mean my my my most recent book rec uh uses Docker, Django for professionals, trying to avoid this problem of being specific to Mac, Windows, Linux, but it's I I mean I may switch that out in an update um because it is it's you know it's a beast.
But it's still there's it, I still struggle to have the oh, you're on this machine, boom, this is the way to get going.
The reality is uh all the pros I know do it slightly differently, and we all kind of struggle through it once and go, Great, I'm not touching that for years.
Um but that doesn't help a beginner, right?
Even for me, like if I have I got a new computer and I was like, oh god, I'm gonna have to like install everything again.
Like it took me like a week.
Um I was like, I'm gonna do it from scratch just to go through it, and it's still just like, oh my god.
So, but it's it's hard to tell a beginner, I don't know how you're gonna get through this, and you you're gonna learn about path variables, but when you join us on the other side, you can just wave your hands about it.
Yeah.
Um, so yeah, I mean we've we've gotten heat from people who don't like condo for various reasons.
I think it's uh mostly religious, it's not they don't have a really solid reason, um, or they don't like the fact that they might have to activate something.
I mean, um, but again, the if you have a strong opinion about it, that's probably because you're you already have your own preferences and you can just skip that version and use your own environment preferences.
And maybe we if we have an admonition about it, we just need to reinforce it and say, if you want to use poetry or pip and virtual env, go go right ahead and do it.
Yeah.
Yeah.
Um, so you do you have any questions about the upcoming release of two Scoops of Django?
Yeah, so that's the one thing we haven't really talked about.
You're updating it, right?
Yeah, so um uh there's some exciting stuff.
Um, we're finally adding a chapter on GraphQL, um, which is awesome.
We prefer that over REST, so we're so excited by this.
Oh, okay.
That well, that's gonna stir up conversations in the community.
Oh no.
In a good way about it.
In a good way about that.
Um uh so yeah, we we've got a GraphQL chapter.
Um, we also we used to have a chapter called Consuming REST APIs, and we're converting that to be really about Java JavaScript from the Django perspective, um, which is yeah um trying to reinforce that if you are doing Django, you should really get up to speed with modern JavaScript.
Um, especially because even and and it's not just the front end, it's also compiling assets.
Um, I I'm gonna here, I'm gonna set off a firestorm.
There is no better static asset manager for compressing stuff than what you get from the Node.js community.
Um sorry, Django compressor, I know that you are
Carlton won't take that personally.
No, I'm just gonna say, yeah, well, I help I help that.
But no, what's um what's the thing with compressor is you shell out to um you know NPM or whatever, or Webpack or whatever, or post CSS.
So so compressor is actually uh a wrapper around this.
And I you know, I've been using it for years and I do, and so I've gone, I've used React in it, I've used Webpack, I'm using Post CSS currently, I'm using, you know, and not never do I have to change the Django bit.
I just add a little compressor script, change the mead mime type.
It's awesome.
So but it it it's exactly that.
It's it it it defers to whatever other tool you want to use.
Clearly, it's been a long time since I've looked at some of the source code.
Uh uh because I remember back in the day we had tools that that you know where Python was doing the minification.
Um yeah, you there are Python libraries available for things like CSS min and J but why would you use those?
Like Yeah.
Okay, so I guess I'm not setting off a firestorm except for my own ignorance.
Um but the the the point is though, is that people often equate the front end with um CSS and style and and design and nothing and those things are great, um, even though I suck at them.
Um but really it is you know having even a an basic understanding of modern JavaScript is it's so important and so useful it you know for debugging stuff.
Not everything, you know.
I I certainly am tempted to do, which is to hide behind the Django and the Python and the back end stuff.
But um, you know, that this is one of the the shortcomings I see, especially with a lot of senior Django people that I interact with from time to time.
They're like, oh, I don't I don't touch the front end.
Yeah.
I mean if you have professional teams, you don't need to.
Yeah.
Yeah.
And but what's funny is these are the same people who will tell you, well, you have to understand deployment backwards and forwards, because otherwise, how do you debug or analyze issues?
That they will they, you know, these people invariably tell you that.
And it's like, look, I'm not asking you to become full stack.
I I can understand the reluctance there.
I I don't like the term full stack so much, but um at least under you know, at least get cognizant it because it'll help you debug stuff.
I mean, no disagreements here.
Yeah.
Yeah, no, totally.
So is it gonna be um so the previous versions were 1.5, 1.6, 1.8, I believe.
So 1.11.
Oh, right.
1.1.
I mean I've I have all of them.
Are you is this gonna be 3 3.1 or 3.0?
What's the because you've you have talked about sticking to LTSs in the past.
Right.
So we're we are calling this uh 3.x.
It is covering the entire three series.
Uh what that means is we will not print it until um uh 3.2 is on the horizon.
And that way the links inside the book will go to 3.2, which is long-term support.
And it also gives us more time to polish it, because um uh as as William knows, once you send a book off and then people get a print version, it you can't update a print book.
Uh yeah, I liked, I mean, I've I've obviously with with interest seen how you've handled Crash Course where you've had the with all the different alphas and um there's there's something to that because it is yeah, there's just so many little things that crop up and and yet people still I mean so for me, like partly I think if I just had everything online, you know, I wouldn't have to deal with this stuff, but a lot of people still do want a physical print book, um even for even for framework stuff.
Absolutely, and and I love print books.
Um, so yeah, the point of 3.x is so that way we don't have to wait until Django 3.2 is around the corner to get the the book out there for people, which means that um so one of the things that I've seen in a lot of forums and um places is people um starting to adopt um either asking questions that are answered in our books a lot or in two scoops of Djang
o a lot, or they're starting to embrace anti-patterns because they just don't know, you know.
It's one thing to use an anti-pattern if you understand the potential issues with it, but if you're recommending it without any caveats, that's dangerous.
This is where you get into failed projects.
Like, you know, the Django world is a lot different now in 209 2020, I guess or in 2020 now than it was in 2012.
There's uh the tribal, you know, we uh you know, to to pat our our backs, we started to capture the tribal knowledge that is out there for Django, and we wrote it down and and some of it's gotten into core, and then people have re-blogged what they've read in our books.
Um but because it's been long enough with two scoops of Django 1.11 having come out in 2017, and also because of Django versioning issues that I know William and I have talked about, um as soon as you come out with something for LTS, you know, you jump a whole version number for the next Django release.
So people will tend to ignore resources.
So part of the reason why we've released this for the entire three spread is to fight um the the lack of knowledge.
Does that make any sense?
Or my um
that makes sense.
I think I mean I I mean I've I've come to try to view the in a situation with Django where it keeps moving forward, and as a content creator, that's hard to keep up.
It does winnow the field because very few people will update their books, and if you're not gonna update it at least annually, it's kind of no point other than maybe I mean it's a harder thing.
Um so I try to view it as like it's a forced you know reconsideration on a monthly level of the content.
Um but yeah, so I think yeah, having the three three dot x and and then waiting till three point two to go to print, so then you have the what I guess two, three years until 4.2 would come out, something like that.
You know, the schedules online.
Yeah, and then basically our determination as to when we go to print is when Django 3.2 uh gets documentation links for us.
Oh, so before it comes out, but when the links are
yeah, that is that is our plan.
Um so since you just
be the alpha period.
So that'll be the you know, three months before we release it, do the feature freeze, release the alpha.
Um that's that's when you'll get links to that version.
Yeah, that's when we get it when Django is an alpha.
At that point, too, scoops of Django 3.x will be really solid.
And um we should have a better understanding of how asynchronous views are gonna be used within the community, um, which I'm very excited by.
Um and so we can really write to that.
I mean, yeah, because like the async views nobody knows anything about right now.
You know, we're gonna see how they're using, you know, what the patterns, what the good patterns are, what you know, all of these kind of things.
So it's been an hour.
I I didn't get a chance to ask you about your fiction writing and all that, but are there any is there any last things you want to mention to listeners about about your work?
Um let me think.
What what about also about my work?
Um so yeah, um uh we are at Feldroy we're coming out with not just books but products and one of the things that we're working on is a tool to write books.
Um I could use that one so if you want to write fiction or um or technical books you'll be able to use a platform and we hope to have that out and ready in the next few months and uh you'll be able to either work through our interface or use um Google Docs or connect a a Git repo um we're gonna try to do both GitHub and GitLab.
So that is that is another thing that we're working on.
And while the front end that people will interact with may not have any Django I assure you the internal tooling has Django.
Just to track jobs as you're doing the build book building process we we needed something and Django Django's admin tool was was such a you know win out of the box that we're going with it.
That's exciting yeah there's I mean there's open source tools that are quite take quite a bit of wiring um and then I use lean pub which I believe is the only kind of popular SaaS ish tool for that but it would be great to have another option.
Yeah and we've used Lean Pub in the past and we think that they're awesome um uh but our focus you know they do they're both a publisher and a book renderer uh and they even provide their markup language um we're gonna focus entirely on the book generation so for ex I I believe you could use our system maybe to publish on Lean Pub if if that doesn't work then you can certainly um use our system
to create stuff to be sold on Sendal or Gumroad or Amazon where you know all these different platforms for selling
that sounds really exciting.
So um I'm trying to think if there's anything else I want to say oh yeah so I'll I'll give you people say what's you know um I'll people ask me two questions.
One is um you know what what's how do I become a writer like a a professional author and two is how do I get better at code um and I'll give my two quick answers there to become a writer you you just have to write um and writing a blog post is all infinitely easier than writing a book um but uh I wouldn't wish book writing on my enemies not that I have any but if I did I wouldn't want to risk book writing on it but on the other hand it is such a fulfill
ing process when it gets out the door that um it makes all the agony worthwhile and then to become a a better coder you you just have to code you just have to practice um if you're not practicing you're just watching tutorials so
I think that's exactly right and I I because I came from the the book world before the coding world the challenge I find with improving coding is that if you want to be a great writer you need to write but you also need to learn how to read and
read good stuff.
And with code it can be harder to do that because you have to work a bit harder to find good code bases.
A lot of times they're more advanced so having a linear progression I've I found I still find is more challenging than with you know fiction or nonfiction where it's just there for you.
It takes a bit more work to find a you know intermediate level still best practices code that you can learn from.
Yeah it's it can be hard to find good intermediate code I agree with you there.
Yeah.
Well thank you so much for coming on we're gonna have links to everything in the show notes and I I I'm currently reading Crash Course it's great.
I'm looking forward obviously to two scoops I know everyone who listens to this is as well.
Thank you so much for coming on we have links to everything in the show notes uh what's the best way if people are want to get in touch with you or or Audrey about your work do you have a preferred method?
Uh sure I mean I tend to be more responsive uh via social media um uh Twitter is a good way to get a hold of me um if you really have to you can use Facebook or LinkedIn email um I get so much email I will probably there's a good chance I will miss it.
Um so um yeah I just get a lot of requests and stuff like that.
Sorry everyone um so those are best ways.
Um Audrey is a lot less responsive than I am so often um people who know us well know that often the best way to get a hold of her is to get a hold of me.
And it's not like I'm gatekeeping really I'm not it's just that um she just likes to be she's a very focused person and um just doesn't respond much to things.
Yeah she's wise I aspire to that well thank you everyone for listening we're as ever at Chat Django on Twitter DjangoChat com and we'll see you all next week bye bye.
Join us next time bye bye