Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 204, recorded October 14th, 2020. I'm Brian Okken. I'm Michael
Kennedy. And we have a couple of guests, Will Vincent and Carlton Gibson. Hello. Hello. Hey,
guys. Happy to have you here. No, thanks for having us on. It's really quite exciting.
Before we move on to the first topic, people may already know you. You guys are Django famous,
I hear. Tell people about your podcast real quick. Yeah, so I'm the Django fellow,
help maintain a framework there. And with Will, we run a Django chat podcast. So and Will does some
other things. What do you do, Will? Yeah, well, when we started the podcast,
I was just a book author, but I'm a Django Software Foundation board member now. So I have a hand in
coordinating with Carlton in an official capacity. But mainly I teach Django through books and
learndjango.com website. Oh, and I have a Django news newsletter as well. So I keep piling things on.
We don't have two podcasts like both of you, but maybe we'll get there.
We haven't got time for two podcasts.
You start with one and then you just get another one. That's how it goes, you guys.
Okay. Like children.
Brian's going to start a third one, I heard. I'm going to start a Rima for him.
I'm going to start a third.
Yeah. Oh, yeah. Why not?
I just should jump to four. I mean, binary, right?
Exactly. Hey, Brian, we talked about Jupyter a bunch the last couple of times. Like,
don't let us down. Like, keep it rolling.
It's a great thing to provide a tool for people. And then we get a whole bunch of people calling
or getting ahold of us and saying, Hey, there's, there's more stuff you should know about. And
this is the case this time. So Marco Gorelli, I think his last name is sent us a, also I have
to say, he said he was a long time listener and he's a Patreon supporter. So thank you,
Marco, for being a Patreon supporter.
Thank you, Marco.
Very cool.
So he said, you guys should know about MBQA. So MBQA is quality assurance for Jupyter notebooks.
So it also can run black. So you can, one of the things, if you just want to run it like a black
thing to run black, one of the benefits of using it to run black is that you can run it on an entire
directory, not just a single notebook, but a whole directory full. There's some modifications with its,
its use of black so that it keeps diffs fairly minimal for the diff set. And then there's,
black will take off trailing semicolons because in Python, they don't really mean anything
and they look ugly, but in Jupyter notebooks, apparently they mean something they mean to
suppress the output of the notebook or suppress output. So that's the black version or the MBQA
version of black will turn that, but leave those in place. And also supposedly supports a standard
magic commands and magics are kind of a big part of Jupyter thing. So another thing I want
to mention, it doesn't just run black. You can also use MBQA to run ISORT and mypye and
FlakeAid and Pylent and even PiUpgrade and Doctest. So that's pretty neat.
Yeah, this is really cool. I think it brings so much of that code formatting, code analysis,
cleanup to notebooks, which I think have been really lacking.
Yeah, some of the standard practices that a lot of people are using now,
as well as the configurations all in a pyproject.toml file. And you can hook it up with pre-commit so
that you can have all these things running when you check stuff in, whatever.
Yeah. And you can even run it against a whole directory, not just one notebook, which is sweet.
I'm definitely going to check this out. It looks really fun.
Now, one thing I wanted to mention, I checked out the source code for it and it's 100% covered and
covered by pytest, of course. So nice.
Nice.
Little chip.
Will Carlton, what do you guys think about this?
Well, I was thinking I use all those tools, but I don't use them in the notebook format. I have to
say I sort of potter with notebooks, but I'm not a big user there. So it sounds super, but I recommend
all of those.
Yeah, absolutely.
Ditto. And I would, whenever I think of Jupyter notebooks, I'm always reminded of, I think the
finest tech talk I've ever seen is, I don't, was it I hate notebooks?
Yeah, by Joel Bruce.
Yeah, Joel Bruce, which is, but I mean, he's not just slamming out the whole time, but it's
a very educated talk. And I think that's a high bar for sort of complimenting and pointing
out issues on a framework or on a project that can be improved.
Yeah. Well, I think that actually a lot of the complaints are starting to get addressed with
things like this, right? It's starting to get a little bit better. There's also some other
cool ones called JupyterLab-LSP for language server protocol or provider or something like
that, which also does a bunch of things that make it a little bit better. So yeah, it's
getting there. It's pretty cool.
Just one thing, the ultimate for general web developers is if you could take a Jupyter notebook
and just snap your fingers and have it be a Django site, you know, you can't quite do that.
But if I take off my technical head and just what would change things, like I'm surrounded
by a lot of scientists that turned a Jupyter thing into a website with standard crud, I feel
like it's possible one day, but we're not quite there.
That would be really fantastic. And we're going to hear like five ways we could do it that
we didn't know about from listeners, which is great. The one thing I would really love
to see in Jupyter notebook and maybe someone out there knows about it is I would like to
see collapsible sections. So I've got like a report and it's got like some markdown and
then some code and then a graph it's generated and then some more like maybe a picture and
then some more markdown. And the code in there is really awesome to have. But if you're
going through it as a report, you don't necessarily want to see the code unless you want to like
dig into it. So it'd be great if you could say these column or these cells are collapsed.
I really would love to see that, but I don't know about that yet.
That's opposite direction of what you're looking for. That's making the notebook more of an
article, less of a website. All right. So the next thing I want to cover is the PSF yearly
survey. Have you guys taken your yearly survey for 2020?
I've done it, sir. I've done it. I already got my homework.
Well done, Carlton. Well done.
I have not, but I've done it past years and I will. And we actually in the Django world,
we're inspired. We had our own survey this year, the first time in five years, because
I don't think Python does as well, but Django doesn't track anything. So we actually don't know.
No installs or usage.
Right. Okay.
And that's obviously helpful to fellows and technical team.
Of course. And I think basically the extent to which they track that is the analytics that come
out of PIP. Like pip was run on this operating system. This package was installed this many
times. It was this version of Python that did it. Beyond that, I don't think there's much
tracking in the Python world either. The broader, broader.
We have PIPI, but that's not completely accurate in terms of popularity.
All the Docker rebuild stuff that's happening all the time, like that counts, but it's not legit
and so on. So yeah, for sure. So if you haven't taken the PSF survey, I put a link in here. It takes
about 10 minutes. You should go do it. This is the fourth time they're doing this developer
survey and it's the major, a major, the major, I'm not sure, a major source for sure about the current
state of the Python community. So what editors do people use? What web frameworks are people using?
Are you a data scientist or are you a web developer, et cetera, et cetera? Are you just getting into Python?
And if you haven't seen the analysis of this before, I linked to the 2019 results, which were put
together by JetBrains and they did a really nice job of like making a compelling story to be told out
of it, right? Yeah, no, it's really nicely done and presented. You're like, oh, wow. Yeah, it's super.
That's why, you know, it's worth putting into because it's the production value at the end is great.
And so it's a valuable resource. I felt bad for a second that we didn't have that on Django, but
instead I just, we're not JetBrains. Yeah, we're not JetBrains. That is the gold standard. I was like,
oh, it'd be nice to have that. And then I was like, or I could just make it a Google form.
Well, you guys should reach out to the JetBrains team and see if they want to partner up.
Yeah. Well, they've probably got the resource in place. You know, they've got the infrastructure.
So maybe now have they always done prizes? I don't remember that they have,
but they have them now, right? Yeah. So that's cool.
Yeah. So they announced that a hundred winners, completely random. If you've completed the
survey, we'll receive the amazing Python surprise gift pack, which I have no idea what it is because
that would ruin the surprise. I saw some good Python socks on Twitter today. I hope it's got Python
socks in it. Oh my God. I love socks. Like that's half the reason I go to conferences. Let's be honest.
Got my Twitter socks. I got all my different socks. I got my MongoDB socks.
I've used to go just for t-shirts, but now I kind of like the socks more.
I do too. We've added a official Django merchandise store,
and there's some items on there and that's been helpful with the virtual conferences,
but we don't have socks. So the, you know, there's a lot of inspiration we can take for
having better official gear out there.
Absolutely. Get your sock game on.
Yeah. And then stickers, right? It goes t-shirts, stock, socks, stickers,
I think in the hierarchy of swag.
That's right. That's right.
Okay. I have to up my game. I'm just giving out stickers usually.
I'm an enamel pin man myself.
Oh, enamel pins.
Oh yeah.
I should mention JetBrains, which is doing that. That survey is a big sponsor of Django. We do a
couple of week long thing every year and they're a major corporate sponsor of Django. So shout out to
JetBrains.
Very nice. Yeah. Very nice.
And one of the things I'm really excited about is we have a new sponsor and it's another podcast.
Yeah. So that's pretty cool. So this episode is brought to you by tech meme,
right? Home podcast for more than two years and nearly 700 episodes. That's amazing.
The tech meme right home has been a Silicon Valley favorite tech news podcast. The tech
meme right home is a daily podcast, only 15 to 20 minutes long. And every day by 5 PM Eastern,
it's all the latest tech news, but it's more than just headlines. You could get a robot to
read you headlines, but the tech meme right home is all the context around the latest news of the day.
It's all the top stories, the top posts, the tweets and conversations of those stories,
as well as behind the scenes analysis. It's like a TLDR as a service. The folks at tech meme are
online all day reading everything so they can catch everything up for you. Search your podcast app right
now for right home and subscribe to the tech meme right home podcast, or just visit pythonbytes.fm
slash ride to subscribe. Yeah, it's like Python bytes, but just for general tech. Every day,
though, these guys don't mess around. That's incredible. Yes. All of us who are podcasting,
we're like, Oh my gosh, that's insane. Yeah, we all wince a little bit hearing 700
promised by 5 PM. Sounds like a burnout algorithm.
It's well done. But yeah, cool. Thank you guys for sponsoring the show. Will, what's your item?
Oh, so my item is from prototype to production in Django. So this is a common thing where you get a
little familiar with Django and you say, well, what's the there's this big chasm basically from
building a CRUD app locally and deploying it properly without being hackable.
What do I do? I run it as a root. I leave the debug setting on what else do I do?
That's important. Yeah. Well, it's sort of like you don't know what you don't know. And then the
older you get, the more scared you get because you've seen it all go bad. But when you're starting
out, you're like, what could go wrong? Yeah. But as soon as it works, it works.
Yeah. So specific to Django, I think like most web frameworks, it has to, it focuses on local
production. So when you run, you run a start project command and it creates some scaffolding for you.
And then specifically, it has a settings.py file. That's kind of the global config. And that's set
for local development. So works great locally. But if you just dump it into production, you're going to
be wildly insecure and easily hacked. And so it's a quick list of things you want to change. And Carlton,
please jump in here as the Django fellow if I missed something. But debug is a setting that is you want to
switch to false that provides very nice error message. But it also has a roadmap to hacking your
site if it's left on. Right. These are in settings.py generally. In settings.py. So it's all about
settings.py. Basically, there's a secret key that Django that is 50 character long string randomly
generated. You want that to be secret because it uses a hash throughout Django. And of course,
what happens is you do one git commit and then it's out there. So you need to change that or really put
it into an environment variable, which I'll get to in a sec. Are you familiar with shgit? No, I'm not.
shgit. So this is super scary. This is a, oh my gosh, it's live right now. I can't believe it.
So I think it's at shgit.com. But there's also the open source version that you can get. You can see
it on GitHub. Let me just read you this title just to like point out how seriously this should be taken.
Shgit finds committed secrets and sensitive files across GitHub, GIST, GitLab, Bitbucket,
and your local repos in real time. It does this by subscribing to the like commit stream on GitHub
and instantly post the secrets like AWS secret keys and stuff. You can see if you go there like,
yeah, I see six for Django right now. And it's all just got two more. Yeah, I just got two more,
three more, five. I just got five more. I mean, it is insane. If you think my repo is not so popular,
it will be fine. It may not be so fine.
But this is the thing with security, right? Is that it doesn't matter how small you are,
because the people who are attacking you, they're using automated scripts. So they're checking every
port on every addressable server with every known weakness. It's not if you'll be hacked, it's when.
Now setting the stage how frightening this is. Carry on why we shouldn't put that in.
Well, I think it just reinforces that the settings up PY file is where most of the action is in Django.
And you want to be careful with it. I mean, I remember GitHub back in the day,
you could just global search for AWS keys and stripe and everything. Now, at least you can't
global search for that stuff. And they'll even ping you. So for me, like I have some secret,
I have some projects in my books that are on GitHub. And there's a secret key there. And they
bug me all the time saying, Hey, you have a secret key exposed. I'm like, Yeah, I know I do. I don't,
it doesn't matter. So it's gotten better. But yeah, it's still all out there. So secret key,
keep that secret. Allowed host is probably the last big one. These are the hosts that can come in.
Django will prompt you to change that. So if you're using Heroku, and it's myapp.heroku.com,
you want to set that host to be only that host, not all hosts can come in. Database is the next one.
So by default, Django has a SQLite database, file based really easy to use.
Fantastic for production, large scale, Facebook uses it.
You know, it can be.
No, I just do.
If your workload is read only. So say you're running a content site, and it's just you editing
it. SQLite will go all the way with you. But as soon as there are more than one editor in it.
It's incredibly fast. It's in memory, right?
Yeah, you can have it in memory, we can have it on the file. But on read only workloads, it will go,
you know, right out there.
Sorry, I meant in process, in process, not in memory, but it's not like a separate server, right?
Exactly. It's just a file next to all your other files. And it can it can hold,
you know, terabytes of data without a problem. But as soon as you've got multiple users logging in at the
same time, or that kind of thing, then you need, you know, something like Postgres or MySQL can
handle that kind of concurrency.
Yeah, so you probably want to .gitignore your SQLite file. But also, you definitely want to use
whatever using in production locally. So Postgres, MySQL, MariaDB, and Oracle are the supported
databases. What else almost done here, you configure your static and media files. So static would be
images, JavaScript, media refers to anything that's user uploaded, you definitely want to be careful
whenever you have anything from users can't trust them, you want to use Django forms, you probably
want to use bleach to sanitize and you want to have that on a CDN, not on your server. Two more to finish
up. So the admin Django has a famous admin that's very powerful, which is at slash admin, you should
change that away from dot admin, because to Carlton's point, there are bots searching for Django sites at
slash admin, and they will come in and hack away at your site. There are a number of fun technical things
you can do to honeypot it or this and that, but you should just change it away from dash admin.
I'm tempted to know there's a very famous Django site that still has slash admin, but I won't mention it
publicly. Carlton and I both use it though, for our work. And then the last thing is user registration. Django
comes with login, logout, reset, but it doesn't have a signup. So you can roll your own or most people would use a
third party package called Django all off that's fantastic that has social support. So Django has very robust third party
ecosystem that over time, the most popular ones, or the strongest ones are rolled into Django. But there's also
separation because it's too much for Django to maintain. Django all off is not is a third party package, but
it's, in my view, effectively part of Django for most people. So those are the big ones are the key things
I mentioned there environment variables, it used to be with the settings file that back five years ago,
you'd have multiple settings files, you have a base settings file. Carlton still doing that?
I still have multiple settings files go with those files. I mean, you have environment variables too,
but multiple settings files for the win.
He's a Django fellow, he doesn't know what he's talking about. You need to use environment variables
for this, because then you have one settings file and you load it into, you know, local staging or
production. I've much easier.
Spaces.
But it works for Carlton.
Spaces.
And there's a number of third party packages that will help you with that. I like environs,
which will be linked there, which also has DJ database URL, which is a nice feature on environment
variables for databases. It just means you have single settings file, and you switch
with environment variables. There's also Django has a handy deployment checklist, which I think a lot
of people don't know about. We have a link to that you can run Python check --deploy.
And it will check that all the things I mentioned, plus a number of HTTPS things are actually
configured properly. So you don't want to deploy your site. If you don't pass most of those,
if not all those. Yeah. And that's, you know, there's testing, logging, performance security,
you can go on and on and on. I wrote a whole book Django for professionals on this. But those are the
highlights. And there's a check, there's a good doc on the Django docs for deployment checklist,
which, you know, you should open that every time you review.
Yeah, the hard thing is, there's like a couple of must haves, like the ones I listed there. And then
there's a lot of, it depends, nice to haves. And that's where it's harder to make generalizations.
This stuff is so rewarding when you get it right to see your site up and running, you know, 99% plus
uptime and people using it. So fantastic, highly responsive. But soon as you see like something go
wrong, it just your heart sinks. And so most of those things are because like you both have hinted
out there's some kind of bot that's looking for some vulnerability and like a known thing.
And just make sure you don't put those known things in front of the internet.
Yeah. And I should say, actually, there used to be a site called Pony Checkup that has,
that you could put in your URL and would automatically just test a lot of this for you.
It's actually someone has taken that over from the original maintainer. So it's now DJ Checkup
slash Pony. So you can type in your URL and check. That's kind of a good way if you're a beginner,
if you're not sure. There's nothing like going to a webpage and seeing security issues in your site
or others to kind of scare you into doing something.
Yeah. Yeah, for sure. Awesome. Well, I'm glad you covered that. And Carlton,
it sounds like the one that you got is a bit of a...
Similar topic, actually.
Similar, yeah.
So I've been thinking about, but I think it must be Django chat. Every week we,
it seems, we have a guest on and we end up talking about deployment and it's massively complicated.
And Will's just gone through a whole list of things and that's only the tip of the iceberg kind of thing.
And the thing that I got thinking about was that there is this deployment gap. So I imagine someone
finishing the Django tutorial, finishing the REST framework tutorial, or finishing Will's Django
for beginners book. And then how on earth do they get their app online? And it's like, you know,
unless you're going to dedicate a week or two weeks full-time researching and trying and following
tutorials online, it's like this chasm. We can't do it. And so platforms as a service like Aroko or
App Service or App Engine or DigitalOcean have got their new one. They look like a great starting point because they're
kind of easy. But in a way, for me, they're a kind of cul-de-sac. You go into them, you get to the end, and then you
kind of have to go back out again when you want to do something more advanced. But then on the other hand, you've got this
do-it-yourself option of provisioning servers and setting up firewalls and virtual private clouds.
It's just way too much. It's scary, right? And then you read some blog posts and it's saying, well, you've got to do it
with microservices or you've got to do it with this container orchestration platform. And no, no, no, it's too
much for me. So I've been thinking about this and trying to come up with a story of my own for it,
and which I'm launching next year. It's going to be called Butter, and it's going to be a little tool that just
wraps it up and tries to take some of the fuss out of deployment. So that's not ready to go yet,
but I wanted to mention it because it ties into what Will was talking about. And you can sign up
for early updates on btn.dev, button.dev, btn.dev. So that's my topic.
That's a great topic. I think I personally struggled through this, right? I started out trying to run my
websites in Python on some pass place that was very simple and easy to get started, but there's just,
there's a ton of downtime and things weren't working the way that I was really exact, you know, hoping.
And I ended up having to do a lot of things anyway. And so I finally bit the ball and figured
out how do you run micro WSGI safely? How do you keep these things up? How do you do zero downtime
deployment? How do you do continuous? So there's just so many.
And how do you keep updated, right? How is it? So, okay, you get it set up and it's fine. But then
six months later, there's a security patch, which you don't quite know how to apply without bringing
your whole site down and rebuilding your server. It's like, how do you deal with those problems?
They're not something you can learn quickly or easily. Yeah, absolutely. Brian, you got to deploy
things? I have before. And that's why I don't anymore. I mean, yeah, last time we talked about
DigitalOcean's new pass service and you're like, I'm all about this. Like, yeah, yeah. Like for instance,
for me. So you did your own like Python bytes and talk Python, you did those applications, right?
Talk Python, Talk Python Training and like 10 other like little APIs and stuff that I'm running all
those. Yeah, right. So I've done I mean, I've built websites before, like in the way past like decades
ago. And then when I wanted to do a podcast, I did a Python. The testing code started out as a,
as just part of my blog. And it was like on WordPress or something like that. Now I will go with a
fireside thing. And I don't, I mean, fireside is a good service, but it's not, I mean, it's not ideal.
It doesn't, it isn't perfect, but I don't have to think about it. What I want to do is podcasting.
I don't want to maintain a website. So there's a lot of things where we do need to build these custom
websites. And I'm glad that there's some attention given to this because yes, I can learn how to do a
Jenga website, but going from there to a live site is horrifying. So yeah.
I literally just spent an hour this morning, maybe hour and a half before like up to 10 minutes before
we started recording, deploying my first FastAPI endpoint through G unicorn, UV a core and behind
engine X and all that stuff. And a lot of it was the same, but that's the first time I've done it with
UV a corn and the settings are a little bit different than say micro WSGI. So I can run it with some basic
stuff. And I'm, I kind of lived in that world of like, I got a, what is the config key to make sure,
or the config settings that make sure that it runs as a different user, not root again in this server.
And just like, you just go through all these things and having that like really automated would be
great.
Oh yeah. I mean the other day, my site went down for half an hour and it turned out to be the DNS in
the end, but I never thought the DNS would go down. How often does that happen? So I log into the server
and I'm checking the application server. That's fine. So I checked the local engine X instance. That's
fine. I checked the load balance. So that's fine. And I'm like, it is, it's the DNS. And then by the time I've
worked this out, the DNS comes back up and the site's back up and it's, ah,
and what I want to do is put all that fully automated, you know? So I just run the diagnostics
and it goes green, green, green, green, green, red. Ah, there's the problem. Okay, fine.
That's awesome. Let me know when you got that. I'm excited.
21 btn.dev.
Okay, cool.
Yeah. Well, and Carlton, I think your cul-de-sac analogy, which I haven't heard you say before,
that's exactly right.
Yeah.
Because it sounds, you're like, oh, this will solve my problems. And then you learn
everything and then you kind of come back with a different problem. I mean, part of the problem
with doing server stuff, I think is that it's, it feels good to an engineering mind, right? It feels
good to be like, you know, drive manual and tweak things, but then you've lost weeks of time and
your app looks the same. And, you know, so there is a danger there in terms of, I feel like you kind
of need to do it once or twice and then be like, okay, okay. I'll just have, like, I'll just have
Carlton handle it for me. Like I trust him more than.
This is the via media, right? This is between the sort of the platform and service, which perhaps
doesn't cover all your need cases. And then the over-engineered, you know, I'm using container
orchestration for a Microsoft thing and I've only got one server and a thousand hits a month, right?
It's, you know, there's a middle way between that.
AWS will never be bothered to make it friendly to small people because they don't care. I mean,
they have this, you know, big clients. So yeah. Yeah. Yeah. Very cool.
I also like the cul-de-sac thing. So you think it's an on-ramp, but it's really a cul-de-sac.
Yeah. You're just in an infinite loop of...
But that's the thing, especially somebody who's in that deployment gap scenario that I talked about,
they go down the platform and service route because that's the only thing they can do. But
at the end, they're like trapped there. And I want to do more, but I've got to go all the way back
down here to learn this other stuff, which is so hard and so scary and so overwhelming.
Yeah. Well, I want to talk about something that's easy and well, it's sort of easy. It's
contributing to other people's open source projects.
That's not easy.
You're just petting Carlton's beer.
No, I'm really excited about this topic.
So I ran across a thing called all contributors. And actually, we talked about NBQA before.
And that's where I got this idea because they use this tool called or the service called all
contributors. And it's sort of a service, but also just a spec. So I'm just going to read it. It says
this all contributors is a specification for recognizing contributors to an open source project
in a way that rewards each and every contribution, not just code.
The basic idea is to use the project read me to recognize the contributors of members of a project
community. The idea is like, there's a lot more stuff going on than just code. There's things like
documentation, design, writing examples, doing maintenance, writing plugins for things, doing
podcasts, giving talks and all that stuff. And it'd be cool to recognize all these people.
So they've got this spec for kind of how to do that. But then there's even more. There's a cool
emoji key, which I love this.
I love the emoji key part. It's so friendly.
Yeah. So it has recommended emojis to use for your contributors list that includes things like a
little laptop computer for code, a little thing for documentation, design, examples, all the sort of
things you'd want with like fairly good. You don't have to think them up. They thought them up for you.
So it's nice. Yeah. They also have like this bot that you can attach to your GitHub repo.
So you can just add comments into somebody's pull request or something to say, hey,
all contributors, please add this person to the contributors list or something. And it just does
it. So.
Okay. That's super cool.
We're looking into that with Django. A few weeks ago, I've been reading, I was reading,
Will was reading, other people were reading the working in public book. I, for the life of me,
I can't remember the author's name this moment, but.
It's Nina, I think.
Okay.
Eggbar.
But it mentions this all contributors thing. And one thing we've got with Django, we've got a
massive contributor base, but we kind of only historically recognized that the sort of 30 or
so people that were in Django core. And then over the course of the last couple of years,
we've kind of tried to restructure the governance and we've managed to do all of that. And now we're
in the position where we want to try and recognize all the other people that we translate the docs
into however many languages that that translation team gets virtually no recognition. Let's recognize
them. There's yes, there's code commits, but there's also all the people that help triage
and review the tickets and review the pull requests. And, you know, those people need recognition.
There's the people who organize all the Django cons. Those people need recognition. We really want to
try and show that like Django isn't just, you know, I committed to Django Django. It's the whole ecosystem.
So I think this all contributors thing is great tool.
You said you're reading the working in public book by, would you recommend it? Is it good?
Yeah, it was amazing book. Like just the first few chapters, it's just like describing Django to a T. It's like, oh yeah, this is the challenge we face every single day. Like a couple of years ago at Django con in San Diego, I gave a talk about your web framework needs you. And I put up a graph of contributors. And in the first chapter, it's this exact same graph. I mean, it's got different numbers and it's for a different repo, but it's the same power law shape. It's the same problem. It's like, this isn't just Django. It's every open source project out there. It's got the same issues. And it's the same time.
Do you grow in on yourself and get smaller and more enclosed? Or do you open out to the community and welcome contributions and find a way of doing that? And if you can, you can survive and flourish. And if you can't, well, you'll weather and die.
Yeah. I mean, I literally took screenshots of the book because I was like, Carlton, you should read this. He's like, and he's like, okay, okay. It's exactly my thing. And this all contributors is so relevant because the most Carlton mentioned at Django, we're changing around what Django core refers to. And I literally have a,
huge spreadsheet with all the various people we're trying to categorize that this would fit in perfectly for. So I'm going to potentially use this.
And it has a GitHub bot, which is fantastic.
Yeah. What can be done manually and you know, five minutes can be automated in an hour. So that's right.
Well, Michael, what are you going to finish this up with?
Well, you know, I want to keep us on the move. Don't sit still, you know, rolling stone gathers, no moss sort of thing. So pandas is a super popular library in data science, right? And there's a bunch of visualizations. One way to work with geospatial data is with geo pandas, which is cool. So there's a library called moving pandas. And the idea is if you give locations plus time, you can map all sorts of interesting things.
things and analyze all sorts of interesting things. It's cool, right? And this project, as it should, has a bunch of animated GIFs.
So yeah, that's what we need to tell exactly what it's about, right? Get in there. So it provides trajectory data structures and functions for analysis and visualization. It started out as this QGIS plugin, but they decided it made more sense to just be its own thing. So it's its own thing.
Basically, it takes a geo pandas geo data frames with timestamp points, and it converts them into moving pandas trajectory collections.
And you know, properties such as speed and direction, you can turn continuous observations into trips, like, I was here for a really long time, and then I went to the store, and I was there for a while, and then I came back, right? That kind of stuff, I think.
It'll aggregate them into flow maps. So instead of, I went exactly from here to here, you can say, here are the nodes where I spend time and the paths I take between them.
Almost like graph theory type of stuff. And work with it is super straightforward. So you can just go create a pandas data frame, pass up a geometry, and a time, and you convert it to a geo data frame.
And then you just say, give me the trajectory, and you can plot it. And that's it. Like, incredibly simple.
That sounds super. Their website's really good as well. I was just clicking on it to see the animated GIFs and whatnot.
Well, it seems like that would overlap with... So, I mean, Django is a big framework. There's a whole geo Django area, which Carlton and I have discussed.
I mean, that and the ORM are the two parts of Django. I kind of don't really know, to be honest.
But they're very powerful, and people use them, so...
Cool. You can also get, like, graphs of kind of derived data. So, like, speed over time, rather than just position. You can get these other analysis in there.
And, you know, I can see lots of interesting places. You know, I had Kane Replical on Talk Python to talk about how they're using Python on the race teams for simulations and stuff.
And, like, those types of analysis, this seems so perfect. Go spend a day on the track, collect a bunch of data, throw into these types of things, and look at the curves and whatnot.
Yeah, and Pandas is almost like the kind of data transfer format now. I mean, you know...
Yeah, absolutely.
So, to be able to integrate there sounds super useful.
Yeah, that's cool.
Awesome.
All right, well, that's the last item. Brian, you got any extra stuff you want to share with people?
No, just working and plugging along.
Yeah.
How about you?
I do have a few things. First of all, I was talking to Hugo Bowne-Anderson from Coiled, and he asked,
hey, when is the transcript from our recent show going to be out? I'm like, eh, I don't really have transcripts at the moment.
The company I was working with to generate them stopped generating, stopped doing that kind of stuff, and I haven't figured out what to do.
He's like, oh, you should check out otter.ai. I'm like, yeah, but isn't that, like, for your phone?
And, like, you're going to have conversations. It's cool.
But what I realized is I can upload files to that, our old episodes. It'll convert it to mostly correct transcripts.
Like, pretty good, actually. You know, it'll get, like, AWS, right, and things like that.
And then just wrote, yeah, I just wrote some automation to turn that into transcripts.
So, I added, like, half a year worth of transcripts back, which means that feeds our search engine, so search should be better as well, and stuff like that.
Yeah, I think it's the top one. I think Wes Boss was also asking something, and I was tweeting with him saying, yeah, otter, I think, when I checked, is by far the best one.
It's not really designed for transcripts. It's designed, I think, for, like, meetings and groups, but it works. We've been using it for a year.
Yeah, that's awesome. And you guys like it? It's been good?
Yeah, as you say, it's, I mean, it's the most accurate out there, and usually it gets almost everything. You can kind of have custom things, like AWS, if it gets it wrong.
And, yeah, I mean, usually I run it through and give it a quick scan. Maybe there's a couple things to switch, but, yeah, it's a no-brainer.
Yeah, it's got, like, a nice editor that, like, plays and highlights the words if you were actually going to stop and edit them.
I also have automation, like, for my courses, I have automation through AWS Elastic Transcribe, or just Transcribe, whatever it's called, to generate those and then hand them off to people.
But otter's looking nice. I'm not sure if I'd switch the courses over. But, anyway, maybe we have a bunch of transcripts, Brian.
Yeah, so I've never really done, I started doing testing code transcripts, but I was actually just paying somebody to do them, and it was getting expensive. So, yeah, let's check this out, too.
Yeah, it's worth checking out.
It's the SEO that really matters, I think. That's, like, the killer feature.
Yes, exactly. That's why I first created them, and I thought, okay, I'll make them searchable so people can also get some value out of it.
But my original reason for doing it was, like, instead of having three paragraphs of content for an hour conversation, let's have the real conversation.
Right?
Yeah.
But then, you know, someone will find that, and that will be useful. And, you know, they'll be like, ah, this is, you know, even if it's badly transcribed, this is roughly what I'm looking for, I'll listen to the episode.
Right, right. Yeah, let me listen, here's the timestamp, and they can get some value out of it. So, hopefully, yeah, that's the idea.
Nice.
All right. Also, I'd switch from Google to try to live in DuckDuckGo land, just using DuckDuckGo.
Oh, join us, yeah.
Yeah, are you guys doing it? Are you liking it?
I've been there for three years exclusively.
Oh, God, I'm still on Google, but I did install a pie hole this week, so, you know.
Oh, yeah, yeah, yeah.
Swings and roundabouts.
Carlton's like, I see your DuckDuckGo usage, and I got to...
I'll raise you a pie hole.
This is what I have to deal with, guys.
So far, I'm liking it. I mean, I've been using Firefox with all sorts of privacy stuff for a long time, but I figured just one more thing.
And I just want to point out, if you're trying to be, like, slightly less connected to Google, they have Google Takeout, or you just want to back up, right?
If you use Google Drive and you sync your Google stuff, it'll give you just a link to the spreadsheet or whatever on Google.
Well, excuse me, if you use Google Takeout, it'll actually convert, like, say, your spreadsheets to Excel, so you actually have them.
Anyway, so that's part of that.
And, like I said, I got to deploy my first FastAPI app today, basically.
And I'm just... I'm really enjoying it.
I feel like it's bringing in a lot of these ideas.
I'm hoping maybe you guys can just comment super quick on this.
It brings in so many of these new ideas into the web space, like the async and await stuff feels super natural.
You don't have to do anything to make it work.
The type annotations mean things.
I just feel like there's a lot of interesting sort of modern Python stuff coming together here.
Like, what's your Django perspective?
Well, so FastAPI is built on top of Starlet, which is by Tom Christie, who's Django REST framework creator.
So from the async side, that's what we're trying to build into Django now.
And we have async views in 3.1, and, you know, we're working on the ORM next.
And then from there, it will spread out.
So there's a PR came in this week about the cache layer.
So there'll be async, third-party async cache backends for Django soonish.
An async, fully async framework like Starlet, it's always going to be out there.
You know, it's going to be ahead of where Django is.
But we'll wrap it up and give it that nice Django feel where you define your class-based views and all these things.
We're not there yet, but that's what we're aiming for.
Then the other thing that FastAPI brings out, which is quite exciting, is Pydantic, which is the type hinting used for the serializers and for the validation.
That's kind of really cool.
And at the moment, we don't have a story there with Django.
We've got Django Forms.
We've got REST framework serializers doing the same kind of thing.
But we've got our eye on that, and we'll see how it goes.
I know you guys are definitely thinking about these things.
It's very exciting.
Yeah.
I mean, but what's really nice about the current, particularly the ASGII world, where all the kind of ASGII is the standard, is there's an amount of interoperability in that you can kind of nest your ASGII apps inside each other and wrap window bears around them.
And it's just another ASGII app.
And so, actually, there's a lot of interop things.
So it's a really rich and fertile time for Django web frameworks.
Yeah, awesome.
I don't have anything to add, Carlton.
I defer to Carlton.
Other than it's sort of wild that, you know, I mean, from Tom, we've known about Starlette that FastAPI is better known than Starlet.
It's a little strange to me, but it makes sense.
Because Tom's been busy rebuilding everything in async the last couple of years, kind of on the side.
Well, the thing also, the thing is that people touch FastAPI.
They just live on top of it.
Like, they live on the shoulders of Starlet, but they touch FastAPI, right?
Yeah.
No, exactly.
Yeah.
All right, Brian, I put in two jokes that we can offer up today.
Let's shout out to some of the stuff that Will and Carlton are doing, though, first.
Yeah, yeah, absolutely.
Okay.
Well, we just, I'd say, listen to Django Chat, which is at DjangoChat.com.
That's our podcast.
It's fortnightly now.
That's a fancy British word there for you.
Check out Will's tutorials and books at LearnDjango.com.
And then, yeah, sign up for the early updates on Button, which is at BTN.dev.
Just did.
Super.
Welcome aboard.
You'll be subscriber number three, I think.
Well, actually, I had to tell Carlton, I was like, get up a page before we go on the podcast,
because he's been telling me about Button for a year.
Yeah, it looks good.
Well, it looks like a sign up form right now.
Well, yeah, that's what it is right now.
But yeah, 2021, it's coming.
Nice.
Yeah, great.
Okay, now a joke.
Thank you.
Thank you for getting us back on track, Brian.
So you've heard about give a person a fish versus teach them to fish.
There's a programmer version.
Did you know that?
No.
Yeah.
If you give a person a program, you can frustrate them for a day.
But if you teach them to program, you can frustrate them for a lifetime.
Yeah.
Yes, definitely.
Unless what, Brian?
Unless you teach them to test at the same time.
Ah, very good.
Exactly.
And speaking of FastAPI, here's a joke that I just saw that's relevant.
That's sort of similar to one put out by Sebastian Ramirez from FastAPI.
So somebody just failed a job interview and the verdict was delivered like this.
I'm sorry.
We're looking for someone aged 22 to 26 with 30 years of experience with Flask or Janko.
Yay.
Well, didn't he tweet about someone was looking for five years of FastAPI?
And he was like, even I don't have that.
He's like, well, as the creator of FastAPI, I would not qualify you for your job having done only 1.5 years of it.
Yeah.
Well, I don't think people realize that it's so new.
I mean, it's kind of taken over very quickly, but it hasn't been around for very long.
Yeah.
It's pretty interesting.
Anyway.
All right, guys.
Yeah.
Thanks for joining us.
Yeah.
No, thank you.
It's been a really cool chat.
I really enjoyed it.
Yeah.
Thanks for having us.
Yeah, it's been fun to have you here, Carlton.
Well, all right.
Bye.
Okay.
Bye-bye.
Thank you for listening to Python Bytes.
Follow the show on Twitter at Python Bytes.
That's Python Bytes as in B-Y-T-E-S.
And get the full show notes at Pythonbytes.fm.
If you have a news item you want featured, just visit Pythonbytes.fm and send it our way.
We're always on the lookout for sharing something cool.
This is Brian Okken, and on behalf of myself and Michael Kennedy, thank you for listening
and sharing this podcast with your friends and colleagues.