Transcript: Modern Django Development - Jeff Triplett

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

And this week we have again Jeff Triplett, who is a partner at RevSys, member of the Python Software Foundation, and has his hand in lots of buckets in the Django world, so eager to talk again.

Hi, Jeff.

I'm glad to be back.

Maybe you could just mention what that is and what they do, since I feel like a lot of what we do is talk about what the Django Software Foundation does, but there's a much bigger one for Python as well.

And so basically they're the fundraising arm of the Python organization.

Uh some of this has to do with PyCon, some of this has to do with fundraising for things like the Python Packaging Authority, or that there's there's a whole lot of trying to figure out like, you know, with with COVID-19 and trying to figure out like how to fundraise and how to support projects and stuff.

So um it's just a nonprofit that's been set up, so there would be no you know commercial interest to try to you know develop and promote events and education in the Python world for the Python programming language.

Even after being on for two years, I've yet to get that down right.

Uh you mentioned the Python packaging authority, and that's that's behind pip, right?

So every time you go pip install, you know, Django, pip install Django Rest framework, that comes from somebody.

Uh so that's who does fund that?

How is that funded?

How did how is it that the servers that maintain that run and run reliably for millions of downloads every day?

It's uh

Yeah, you all

Um so yeah, part of this has always been volunteer base, but the PSF kind of helps with some of the infrastructure, and there's a lot of donated infrastructure.

So I forget how many like terabytes of data it is a month, but it's a scary amount of data that goes through that you know when you pip install something, uh companies like CDNs and stuff, and I don't want to quote a company for lack of knowing which one it is, but that's all cached, and so you know it's a to me, it's a very, very scary world to talk about packaging and how this stuff works behind the scenes, which is why you need to get Ernest on to talk about it, I think.

He's uh yeah, I'll I'll ask him to come on.

I'm sure he would do that.

Um good question.

If I can find that link to that article, I I saw that graphic of usage and it was always high, and then it's really gone up as Python has gone up the last couple years in particular.

So I would just be doing it a disservice to try to explain it.

For some of you, you know, I'm a company, I'm using all of this.

I think, oh, I could sponsor someone there.

There's also been a couple of really large grants, and I I think Mozilla maybe gave some money towards it, and then the Chan Zuckerberg Foundation, which is from you know Mark Zuckerberg's Facebook charity.

And so they put quite a bit of money to help fund some of the projects and stuff.

So that's one means is that there's a direct fundraising campaign we can link up.

And then the second part is the PSF itself accepts money as well.

And any money you give the PSF, they can use for packaging as well as just keeping the lights on.

So you've got two pretty good options there if you, you know, only want to give for one versus you want it to go to both.

Okay, super.

Nonprofits are restricted to where they can use that money, so that money can only be used for travel grants.

So the PSF works in that way too.

So anytime you see like a specific fundraiser, when you give money to that, they can only legally use the funds for that purpose.

I didn't know that.

How does Django or really any um package or library fit into the Python world at the PSF level?

Because there's Django Flask, there's NumPy, there's all sorts of packages.

Does it come up at all?

Or is it really how does that fit in, right?

Because we're obviously Django Focus, the Django podcast.

Is it really to the side or is it kind of part of the discussions and debates about the community?

There are what 10,000 projects in Python.

So the bigger ones definitely get on the radar.

And if if somebody like if if one of these groups comes to the PSF and says, you know, we would like to have help with fundraising, or we would like to have help with where things are stored, then the PSF can kind of help them with that.

So maybe that's from a GitHub, you know, organization perspective, or you know, from a let's give you some advice and services because the PSF actually has some staff on hand too, that they're able to help some of the like sponsory.

It's called like the physical sponsory program.

And it's something they can do to help events, let's say, because they do have accountants on staff, they do have some legal help, they do have like resources that are able to provide.

So some communities have started taking advantage of some of this as well.

It's more focused for events, but we've also seen it.

I think like Black joined the PSF under the GitHub org, and there's some options there.

So, you know, it's really tough just because if you have something like Django, you know, Django set up its own foundation, its own nonprofit to kind of handle its money and to kind of help advance that program.

So a lot of organizations tend to do that, but if they need that help or assistance, they could ask the PSF to be part of the PSF or to have that project.

Like, you know, since the PSF's already a found a nonprofit, they could help manage money and donations to direct it that way and the to head towards projects.

They don't do as much of that, but they're not against doing that kind of work either.

Because uh a project, say like Black, like it needs community support and it need it's really important and it's becoming more so, but um, it perhaps doesn't have the scale to set up fundraising of its own.

And so to me, that's like I, you know, my philosophy is when it comes to fundraising that we should make it as easy to let people, you know, give money to these organizations while they have their checkbooks open.

And so, not to plug GitHub, but I really like GitHub sponsors because most of the people that I know, either their companies use it or they use it for personal projects, and some people already have their wallets open to pay monthly for things.

So supporting like the DSF through GitHub sponsorships is easy.

Uh the PSF I hope to see in that someday too.

And I think maybe I don't know if black is, but I feel like there's some other projects in the Python space that are more and more starting to utilize this.

And I just think it's easy because you know you're already paying your monthly bill, anyways.

Um, most sponsorship options are you know pretty affordable for most people.

Um, it's just a quick win, I think.

A lot of companies, a lot of managers will have a discretionary spend, you know, below you know X amount.

They can just okay it.

And if you can just put your credit card in and that that's that's a win.

Yeah, I hadn't thought of that.

I mean that's that's a good one.

Send in your entries.

So look, I had a question, which is um since last time you came on, you've there's one really big topic that's sort of come up that the two of you have been involved in, which is Django News.

Do you start this newsletter and I don't know, it's it's fantastic.

Every week it arrives in my inbox some someday, and there's more content in it than I can possibly read.

Well, I don't know.

I I I like lots of side projects, and this is one that we were talking about would be kind of a fun one to work on, you know, to collaborate on.

Um, I also do a lot of link stuff, like yeah, I don't know if you've all heard of Pinboard, but it's just a link sharing website.

Um, I I bookmark everything basically, and I know Will gets a pretty big volume of stuff through like awesome Django.

And so, and I think you know, Will's perspective of being more focused on people who were, you know, teaching and beginners and new to the community.

Um, we kind of thought it was a good parry and like I've been in the Django community for I don't know, like 12 years or something.

And so we thought, all right, you know, this is a good quick easy thing we could do.

Um, I hate to say quick easy, but uh it's just something that I felt like is a byproduct of links that we're already getting and resources we're already seeing.

And so we kind of had this idea to do just a weekly newsletter and at some point do you know more of like a an actual web presence or something for it could be neat.

And the cool thing was when we were talking about it, um essentially, I think it took like 30 minutes to actually do the project because in saying so, it's like we need a domain name, I can register the domain name.

Uh, Will already knew about this site called Curated that it's kind of like a link blog, anyways, newsletter platform.

And so one thing I thought was kind of fun was we took the energy to actually do the thing versus spending months and months to build something to not ever, you know, to run out of energy to actually implement the idea.

Yep.

And so, you know, this was basically a bunch of no-code tools.

I have worked on a Django backend for it, which we'll probably roll out.

I don't know.

It's been done kind of since December, but every week that I don't take the 20 links and put into it, now we have like hundreds and hundreds of links that I need to go and scrape and put back into the site, but functionally I think it's it's there.

And I mean, Jeff is sort of one of my primary resources just on Twitter and other things for new projects, so it's sort of what we are already doing packaged up.

It's just

There's a couple tools, and was like, well, there should be a Django one.

Um and you know, so you'll note uh some people have noted that so curated uh.co, which we use, is written in Rails.

Uh so some people were like, why aren't you doing your site in Django?

Uh which I was sort of sort of like, well, if you could see that it's it says pretty clearly that's curated, it's a hosted thing.

But anyways, that was a question that came up.

But we resisted that temptation, though Jeff does have this pretty cool dedicated site, which will which we will roll out at some point, um, which has also been fun to to see.

I've done a couple PRs, not that many, but just to see how Jeff does projects.

I mean, that's one of the things I really like is working on stuff that has a real world purpose but doesn't have all the like money and stuff involved.

It's really nice to have discussions about like I've asked Jeff a lot of questions around well, why'd you do it that way?

I mean, because that's very educational for me.

Um, I think for any developer to collaborate on projects like that.

So um, I mean, well, and what's maybe in particular.

So GitHub Actions, Jeff, you're sort of famous in the Django community for your advocacy of GitHub Actions and you're using it in some interesting ways on the non-launched, well, not publicly launched site.

Do you want to maybe talk about some of those?

Uh sure.

So if you're already using GitHub, you get CI rolled out for free.

Um, it's also super fast.

And so I've got PyTest and PyTest Django.

Every time you commit a pull request or you merge code, those are going to run.

If the build passes, then I'm gonna build a Docker, uh, a Docker image, and then I'm gonna push that to GitHub's package registry.

Package registry is another fun GitHub tool that I don't think a lot of people have used yet.

But basically, you can either push your Docker um your Docker images to like Docker.

Um, I used to use GitLab for theirs, but GitHub is just super fast and it has good caching.

And so, you know, we push the image to GitHub, and then I've got a digital ocean set up that pulls for images, and anytime it sees a new Docker image, I use a product called Watchtower.

It's another free open source tool, and it just it's it's like intelligently reloads the running image, and so it it manages the containers for us.

So it's pretty slick.

It only takes like maybe two to five minutes to roll out any updates to the website, which is is good enough for what we're doing.

So I have to rely on you for Docker help.

Yes, I got a Docker zing in.

Okay, fine.

It's okay, it's okay.

Brilliant, awesome.

So, you know, I want to run uh post GS, this ver GIS version, this one, that, and okay, quickly.

Docker pull, Docker run, do it, super.

All of that's just amazing.

What I see is a lot of people go jumping through a lot of hoops to turn that into a full containerized deployment environment where it's it's just not necessary.

And I think for um my sort of objections aren't anybody's doing it and having fun with it, brilliant.

But I see a lot of beginners, intermediate sites, small sites using totally inappropriate technology when they you know they should just be spinning up a single instance and deploying, you know, nice and simply the old school way.

And so I think you run into this with every service.

Like I get that, and when I take like a Docker Compose file, it's gonna have a list of a bunch of services.

So maybe like for an easy project, I've got two.

I've got my Django app, I've got my Postgres backend or database server.

And so, you know, and some of the ones we use now, like I may have Redis, I may have Celery.

So I could, you know, maybe I'm managing five to six different services.

When I push something into production, I'm not doing a Docker Compose up to try to run all those on my virtual machine.

And that's where I think it's kind of a pain.

And, you know, people need to realize like Docker Compose to me is the shape of what I want my production environment to look like.

And it's managing those resources for me locally easier than what and I can configure stuff myself.

I just think it's a pain to keep track of Postgres databases and different Redis ports uh or different Redis database instances as well.

So whenever I push something to production with Docker, um I'm just I'm just shipping the image, and then I'm gonna be, you know, using uh like from database servers and stuff like that.

Like I don't want to home roll my database server either.

I want to use a managed server because there's a lot of you know, I would rather a company who knows what they're doing manage that stuff for me and I can check and make sure my my backups are working, and you know, I and I think that's a mistake some people make.

I think they ship that Docker Compose file and then they try to do, you know, load all the services up, and they're like, this is kind of a pain.

And you're right, it is, but yeah, I think you get a better level of service if you can use managed services.

It's like, you know, whatever, whatever uh dollar, oh yeah, I could run this.

I've already got an instance, I could squeeze my database server on that same instance and I could save myself eight bucks or twenty bucks or fifty bucks.

No, spend the money on the managed database thing and have the backups and have the updates and have the you know, all of that stuff.

That's the best money in the world.

But I mean, I see Docker as a packaging tool and a deployment tool.

And so it does help for local dev, you know, sure.

But that ability to package, it almost reminds me of like from a video game perspective, like I see a Docker container like you would see going and buying a cartridge or a CD image.

You know, like if you buy a game and it's on, I guess they're all DVDs now, but if you buy a game and it's on a DVD server, like I have that is like a press Docker image in my mind, and I'm putting it inside the computer.

And so however much RAM you want to allocate to it, disk space, maybe save game files if you're using like a PlayStation or something, that that's exactly that model fits my brain for how Docker works behind the scenes.

But I can add as many resources to it as I want to.

So if I'm having trouble with my website, I can just double the number of servers or virtual servers it's running on.

And and I it's just really nice.

Like the first time you migrate a server that has a dozen Docker apps on it, and you can just Docker up or Docker Compose up and run everything, it's just magic, and it's magic in a really good way of like wow, like I I still have servers that are probably seven, eight years old that are running outdated Linuxes because it's such a pain to try to migrate that stuff, and so that's what sold me on it.

Um and I have no problem with that at all, and I think great, more power too.

I then also see um folks who um are using or trying to use it because it's the fashionable thing or because it's got a lot of mind space when they haven't necessarily um pinned down that that that serves their requirements best.

Um, I may this topic came up because uh, you know, I made a couple of comments that uh, you know, how I'm not a massive fan of Docker, and I don't, you know, take the instant, take the example about spinning up a um an instance, and you say you've got Linux servers that are running outdated Linux, and you haven't yeah, absolutely.

You want to be spinning up new instances, new VMs, fresh fresh versions all the time.

But that's not an easy thing to do either.

So there's this

it I don't know.

Like that is a thing that takes 30 seconds to spin up.

And once I add my package registry to it, which again you can do with Ansible or Rsync, or there's many tools to do it.

And once I have my images, I can just use a config file and Docker Compose up on that, and I can run a dozen servers.

And it's that easy.

I mean, you need to install a firewall for one, so you need to have a little bit of security mind it.

But you have to do that anyway.

Right.

You don't have to set up, you know, you don't have to set up everything else on top of that you would have had to set up before.

So I don't know.

I guess it's it's it's easy to configure.

Well, it's not easy.

It's straightforward to configure Docker.

And I feel like it's fewer hoops to jump through than trying to set up um Python with Python path.

Like I know Will has a lot of headaches about this, and you've got sites dedicated to basically Python Path and different OSs and stuff.

There are certain versions of Python that you can't run on modern OSs.

And so you can do that with Docker through the magic of pulling the container and running it down, which it's not magic at all.

It's it's pretty proven technology.

And so that's the thing is like I know for a long period of time, the good old way, I was really restricted to what kind of software and libraries I could run on my servers because it wasn't supported by Ubuntu or it wasn't supported by Debian.

And that was a really bad place to be.

Like, go grab this TensorFlow library because you want to work on AI and you just done something with Jupyter Notebooks.

Now you want to put it on your server.

Oops, you can't do it because you know LXML or some library you need isn't supported on it, right?

That's where it really shines, right?

Is where you've got some crazy dependency set.

And this is why the example I use is um GIS, because to conf you know, GIS is it's great, it's lovely, but the different GDAL library and this, that, and the other, and you try and no Docker that put that in Docker because it's perfect and it pulls it in, it can you know wraps up all the dependencies, lovely.

But again, I come back to why I don't use it for my base app the deployments is because you know, to to to deploy a standard Django app into a known environment is not a difficult thing.

Like you've got a base VM that has that base environment in place and keep that that base image updated and refresh that on an ongoing basis.

The same as you're building Docker files.

Um, and then to just to put your application bundle onto the server is not the was never the difficult thing, you know.

You can just rsync it or whatever.

Um but then yeah, as soon as you like, oh right, I've got to run this Java-based thing.

Oh no, I'm not gonna install that then.

I'm not gonna install that locally because I don't want to put the libraries in place.

I'm just gonna use Docker in that circumstance.

Um, yeah, certainly.

That's where I do use Docker, and that's where I do like it.

And I think if anything, if if all Docker really accomplished was that packaging deployment stuff, that's fine.

But I think it gets everybody talking about the same way to deploy things in the, you know, because I've worked with hundreds of clients, and Docker is the only thing I've seen clients consistently do in similar ways because you have somebody who learned SCP files or rsync files or tar them and all kinds of weird, you know, and there's dozens of libraries in Python even in Ruby to deploy stuff.

And so it's kind of it's kind of the wild west, honestly, when it comes to deploying stuff before.

And now, at least with Docker, it's cool.

You have a registry somewhere, I need to be able to get to that, push and pull images from it.

And so I I think it makes a I think it makes DevOps quite a bit easier.

But and and you know, to your credit, well, as soon as something else comes out that's better than Docker that is stable and works.

I I have no love lost with technology when it comes to you know the way this stuff evolves and moves.

So yeah, so I may have a Docker hater shirt on someday, but I think competence gonna stay for a while.

But this is me, this isn't you.

I'm not pushing that on you.

So I don't have the Docker hater shirt.

I don't see the you have to containerize every project, every every app, everyone.

And I think especially if you if you know, I mean, what is DevOps?

You learn one way to do it, then you go, I don't want to look under that rock.

That's how many of us who are non-DevOps people feel.

And you know, you have your way of doing it, Carlton.

If someone already has a way of doing it, yeah, if you can avoid Docker, it's it's a learning curve.

If you're new to all this and you've never deployed before, I think Docker is as easy and as future-proof as any other VM approach, which is sort of more why I advocate it, and also I've had to use it professionally.

So um, yeah, it's good to have nuance on this, and it's it's fun to have something that needle you on currently.

I've had really good luck copying and pasting configs from one repo to another.

And I guess with GitHub Actions, it's workflows and jobs.

So I've had really good luck copying those jobs and workflows, and most of the time they just work.

I have never had that success with Ansible or Salt or whatever the Ruby thing was before that.

So and I I like kind of this config base.

I know there's a lot of basically these projects use YAML, and there's a lot of weird YAML hate in the Python world, which is kind of funny to me because a lot of people came to Python because they like to tab the eliminate deliver deliminations.

And um, it's funny going back to to YAML and seeing Python people complain about the white space and stuff is it's absurd, but

You know, uh irony is a hat worn on or shoe worn on two feet or something.

What is it, Carlton?

It's a British phrase.

Maybe it's hypocrisy.

Is a hypocrisy is a shoe worn on two feet, and irony is a shoe worn worn on two feet.

I think it's like Churchill or one of those

I think we've had a couple of um, I think we've had a couple of links in Django News.

There was a couple

It's so tough because so the segue, I guess, into DEFNA.

So there's not going to be an in-person DjangoCon US this year.

And so as soon as I can get off my dance card closing the conference for this year and getting through all the contract stuff, then I have time to write and have time to do stuff that, you know, with PSF stuff as well.

And I don't know.

I've got a lot on my plate.

So writing is the one thing that I want to do and strive to do more of, but I just don't have as many, I don't have as much time to do that.

I would love to, though.

And but

Perhaps it's already there.

So maybe this is relevant to anyone who uses awesome repos or wants to start their own.

So Jeff recently came aboard to help me because I was complaining to him about running an awesome repo, because I think there is this pattern where you you start one, it's fun, you get a lot of stars because people like the awesome ones, but then you get a lot of PRs and a lot of them are kind of questionable.

You know, maybe it's someone plugging their own package or a company, or it's you know, it it bloats out and you get burned out on it because it's something you do for free.

And so I was feeling that.

And usually what happens is someone lets it drop after two, three years, and then someone else comes in with a new awesome whatever repo.

So I was feeling a bit of that pain, and Jeff offered to come in and help me out.

So, Jeff, how is it joining the awesome Django repo?

I like seeing projects like this in Django because I think it's a good way to point people.

And I I find it to be really useful from a I need a tool that does XYZ, maybe I can't think of one, or maybe I've used five over the course of so many years.

It's nice to go back and look at them and have one resource to look and see like this is being maintained or this hasn't been maintained.

And and there's you know, there's neat new, you know, people who work on new projects and stuff may come and you know want to talk about their project on it.

So even if a PR doesn't make it, I find it to be, you know, pretty valuable.

Some of a a lot a number of the early Django news packages were ones that people had pinged me about for awesome Django, and you know, if they weren't they didn't have a lot of stars yet or something, or they weren't there, I would say, well, maybe not yet, but I wanted to plug them.

Uh but it is that curation is the problem.

You want a curated place to look for stuff.

I mean, Django Packages, which is part of the Django Software Foundation now, um, is a great resource and does some sort of ranking, but it's not as curated as awesome Django.

Um, though the con is that Awesome Django is whatever you and I feel is a good choice, which is nice to have that perspective, but you know, it's just two perspectives.

I think that's more I think that's what we're missing because Django packages is really good, uh, but it is a fire hose.

And they're, you know, every I think the point of sites like that is to try to catalog every possible option in the Django space, where awesome Django.

I wouldn't call a project awesome if I were creating this movement, but no one asked me.

But it is what it is, right?

But it's you know, being curated and being the cream of the crop, I think, is is val has value to it.

And so it was sort of a way I can point people to this and say, This is as of now what what seems like a good option.

And you know, and then there's some gray areas.

So, for example, uh for a CMS, like just yesterday, someone emailed me saying, I you know, want to do a CMS, I'm looking at Django CMS.

Um, what do you think?

And that's a chance for me to say, well, Django CMS is popular, it's been around.

You might also look at Wagtail.

Um, you know, I I don't have an answer for you, but I can make a recommendation and give a sense of you know curation where those are probably the top two that would come to mind for me.

So it anyways, I'm just remembering that's part of why doing the repo made sense, is because I get asked questions a lot about stuff.

So um it's a way to answer it and have people make suggestions too.

I'm sorry.

But the content piece is the one that's I'm not as sure of because obviously it I have a self-interest, though I try not to make that you know too much the the will show, but there's a lot of there's a lot of Django content coming out, which is great.

There's a lot of Udemy courses, there's a lot of books.

Um I have a you know, A, I have opinions on some of those, and I don't want to be negative to anyone who's done work, so I don't really want to be negative in public, and B, I don't have time to review every you know Udemy course, and there's qu quite a lot of them.

So that's the part where I'm not as sure going forward how we juggle that because you know a third-party package we can play around with or talk to people and get a sense, but content is content is harder.

Um though at the same time, yeah, you want to know what's what are the best video resources.

Um I don't know if that's as answerable a question.

And it's you know again, it's slightly not conflicted for me, but I'm aware that I'm not doing awesome Django just to plug my stuff.

But you know, I think it's okay.

So it should be on there if there is a content section.

That's my soliloquy on that.

Oh, okay.

So I'm I'm a sort of crazy man, I'll either just use Ubuntu or you know, like the Python-based um Docker image.

But I shouldn't be using that, right?

I should be using something better or slimmer or smaller, or what should how should I build my Docker images?

And what's this build kit thing I keep hearing about?

What's that?

So there's two questions.

A lot of questions.

There's two questions there.

I think that I think the base image is maybe based on Alpine.

And so when you when you use the Python-based image, you have options like Python base image, the version number, or maybe it's a you know dash version number.

Um, so Alpine used to be kind of the popular image to use because it's very, very small by default.

And then anything you install on top of that, you have to install like GCC and a bunch of other options just to get anything I feel like that's useful on.

And so Alpine takes forever because it has to, you know, it has to pull down a full compile chain.

And the image, so Alpine is great for I want to just run something in Alpine that does what I want already.

When you have to install everything, you're adding time on how long it takes to build your images, and you're adding a bunch of extra, you know, your image is gonna bloat.

You can start with Buster and Buster Slim, and your your final output is gonna take less time to build your image, and it's gonna be smaller.

And so Buster is the I guess bigger image, and I believe it's Debian based.

And so I'll normally use what's called multi-stage builds in Docker.

It's where you have one stage where you install literally the world, and then you will install like your pip dependencies and your Python packages and stuff, and then you have like another layer, another stage, and from that stage, then I'll go and copy everything that I compiled from the previous stage, and then that will be, and I'll base that on Buster Slim, and then that will be where I actually run my development tools or my my production image, and so there's a lot of value to kind of knowing what your image options are and what the final sizes are.

Um, a lot of this works better from a Go world because you have like a compiler, you know, C world or something where you compile everything into one binary.

Because if your final binary is just two megs, then you can take like an Alpine or something, compile everything, and then copy that that executable or that binary file into that image and just run it, and you have really small images.

Python doesn't compile down, so it is what it is.

So you're always gonna have you know 30, 40 megs of libraries and stuff to have to copy and use.

And then build kit is kind of the where, and I'm I'm a little confused by it myself, but I know at one point Docker was going through this existential crisis, and there's Docker and there's Moby.

And I think Moby is kind of the open source, what the company, when they decided to not do commercial stuff, or maybe they've I don't know.

Anyways, there's two confusing companies.

Moby, I think, is the commercial interest now, or maybe that's the open source, but they they have a new uh project called Build Kit, and that basically is some experimental features, and it's like trying out the new features that are going to be in the the release of Docker at some point.

I guess in the Django world, it's kind of like the minor additions or like the Django 3.1 and the 3.0, but when you know the LTS version comes out, then all those features will be final.

But Docker kind of does their own thing.

So build kit's kind of nice right now because there's a few experimental features that will let you run.

Um, you can build your images in a parallel mode where it'll pull all of the images separately, and so it just it speeds up your image creations, but worth

And so I like quick wins like that.

Sounds good, doesn't it?

Double the performance.

Great.

And you built this little visualization tool for it.

But I think it didn't capture maybe as much data or something.

There was some itch that it didn't quite do that I was trying to scratch at the time.

But um, yeah, I think it's nice to see because I think it's really confusing when people see, like, oh, here's Django 3.1 is gonna drop, but it's only gonna be supported ish for what, like nine months or a year.

Yeah.

So the point I if you if you're if you're jumping from minor version to minor version, you've got apart ignoring the LTSs, you've got 18 months, right?

Uh and then it's it's end of life.

So they you know, if you've there's two ways of going about Django.

You've got to either update every nine months and you've got to be committed to that, and you know, it's easy enough these days, easy enough, we say, but it's easy, you know, it's it's as easy as it's ever been these days.

But you've got to be on that update train, you've got to commit to it, or you can be on the LTS, is where you get three years, you get the double, you get twice as long.

Yeah, but the interesting thing I had never really thought of is they said from a book perspective, it's easier if like Django's LTS was maybe the 3.0, and then the feature branches come on top of that.

Has has Django Core ever talked about you know the this cadence and does it make sense to do

something like that?

Uh like the the current release cycle

But the the um I mean that kind of okay, so the current release schedule was set right back around the 1.8 days.

Um, I think uh I'd need to go and look it up.

Um but the idea was that the LTSs would uh if you if you can run without warning on one LTS, you should be able to update to the next LTS with only minor changes, you know, like you might need to some small copy and paste adjustments or that kind of thing.

And then the on top of that, the APIs would be stable so that we'd have the depreciations so that you know if a feature was going to be removed, you'd have time to update that and then you'd get the proper warnings.

Um I don't know why the point two ends up being the LTS, and then that was just what was decided back in the day when they were looking at, well, we'll make you know, we'll make this number 2.0 and this number then three 3.0.

It's it's a perspective I didn't I never had that perception before until you know talking to a couple of people.

This is uh other authors as well.

Yeah, it is.

I mean, and maybe someone could put that to the mailing list and say, well, hey, could we just adjust uh the the numbering system to make it you know more marketing friendly?

But the the interesting thing for me is like, is it does it really change?

I mean, from a marketing perspective, obviously you everyone wants to buy the book which is for the latest version, right?

And that's if your book is for 2.2 and now it's 3.0, oh well, it's out of date.

But Django doesn't change that much anymore, or does it?

I mean, you know, if you're re Will, if you're rewriting tutorials, does it

So it's I mean, I've come up tried to adopt the mindset of it's a positive for those of us who can do updates, that you know it's bet it's better marketing, I guess, to have an up-to-date book, though it's a lot of work.

Uh it's just confusing for people.

I mean, it's confusing because Python 2 to 3, they kind of go, Oh, is Django 2 to 3 a similar thing?

And changing the major release versions often, which is the plan going forward, people as you know, assume that there's something major every time when it's sort of the the cadence.

I mean, we've talked about it hopefully in this podcast to educate people, but I don't know.

It's the difference between someone who's brand new and someone who's already in the in the Django world.

It's not I mean it's it's a pretty it's as smooth a transition as any framework I've worked with, but it sounds scary and it will trip up a beginner.

Yeah.

And if you see like, oh well, Django 4.0 is the latest version, that I don't think the LTS necessarily and I need to relook at this, so maybe it's not as bad, but I I think that definitely trips people up if they go to try to find a four book because four is out and all they see is a three-two book.

It just feels like a psychological difference that we're not doing new people favors on that was less obvious to me until you know a couple months ago.

I do, I I would certainly agree that separate from the author perspective, it would be more friendly, but um it's not yeah, the main concern of core Django developers.

No, we do think

it's interesting though.

We do think about that.

Like when so there's a there's a discussion on the main list at the moment to change um request.get and request.post to something more Pythonic, to more, you know, like maybe query params, for instance, um, for request.get.

Um and I'm a bit like, whoa, that's a big change.

Because for as long as Django has been around, like that, those you know, capitalized get and post attributes on the request object, they've been I they've been the same.

And to uh okay, they'd work the same, they'd still be query dicks, and it'd still but if if those names were to change, then all of those tutorials back for the history of the project would just kind of need updating or be outdated.

And it's like, ah, that's a big that's a it might be nicer afterwards, but I'm a bit scared.

That's fine.

But yeah, that's that's what I see.

And it is weird because it's like request.get.get, but it's like shouting case get or something.get.

Yeah.

I mean, they took that from the PHP world.

One of the yeah.

One of the three.

Last thing maybe, Jeff, I want to uh ask.

So you have your morning routine written January 20th on your website, which looks very lovely and leisurely about dropping your son off at preschool.

And I was just curious how your productivity has been the last couple months work-wise.

What's your morning routine these days?

But yeah, it was kind of chaos there for a while.

I've got a two and a half year old who adjusted very well to life in this COVID-19 times.

But um, yeah, I would be my my partner and I you know split our time because we both have to work, and so I would have a two-year-old for the first half of my day through about nap time, and so he pretty much would dictate the schedule.

So he was a pretty good coworker though.

So he's got a little desk set up in here and he would watch, you know, YouTube and we'd play and you know, between like breakfast and lunch and stuff.

I mean, it was kind of chaos, but it was a good two months though that I'm glad that I had just from a I mean, I wish the world wouldn't be, you know, falling apart like it's been the last two, three months, but um I'm I'm I'm grateful to have the positive side of you know getting to spend that extra four or five hours a day with my son for you know two, three months.

So yeah, it's and you all I guess everybody here is a parent, so everybody has had similar impacts and stuff, but I did think about redoing that blog post or just posting an update just from the the COVID life, but I do have a draft of it, I just have yet to to publish it.

It's it's a problem.

My problem too is I'm dyslexic, and so depending upon what life is like for me, certain writing things are really easy for me.

And some of them, like the first year I did DjangoCon US when it was a lot of me writing all the blog posts and the tweets, um, I would obsess over that stuff for hours.

I mean, some of it I would just do quick quick drafts in the morning and it would take me a week or two of fiddling hundreds of times.

And so part of that's my dyslexia, and it's just the spectrum and it's a range.

So some days the words are there.

The next day I look at it and I'm like, what in the world did I write?

So I've used a couple of tools.

One of them I'm not super happy with, so I won't plug.

But there's some dyslexic fonts and there's some you know random tools that are helpful for me, but I never really know when I'm in it, other than writing just gets super, super frustrating.

And so I've tried like recording myself from audio.

Sometimes the dyslexia kind of like because mine isn't so much mine is letters and words, but it also you know hits like communication for me verbally as well, sometimes.

So I think it sounds like a stutter for me when it's kind of at its worst.

It's you know, is it video, is it audio, is it writing, is it I don't know, sk sketches like um Julia Evans does these um awesome the

Julia does

Where's the tooling for you need to build a static site generator before you can write the podcast, right?

And so, you know, and I you know, circling way back to the beginning, when we talked about Django news and stuff, I I you know, if if people only get one takeaway from the show, I think it's that like we're in the Django world, we obviously like our hammer is Django, we like to solve things with Django and Python, but you know, don't don't devalue if you take your time and put it into using tools that already exist so you can just get into your idea and communicate your idea.

That goes a lot further than spending like 10 years rewriting your blog engine, like I know so many people do.

Like it's absurd how many people tell me that they've been writing their own blog for five years.

It's like just go use Jekyll, go find a Python static generator, go use Django CMS, use Wagtail, you know, use a tool and get to your idea and you know publish.

It's easier to it's easier to build your own from scratch, from to take take sand from the beach and cast it into silicon than it is to read the documentation on Jekyll.

Yeah, yeah.

And so there was a weird kind of series of tweets, or maybe people on Reddit who I don't read or something were like, I just it was it wasn't a ton of vital hate, but it was a little bit.

And I'm like, you obviously don't know, you know, a lot of the people who help with conferences, they're still new to this stuff, and the barrier of using get and the barrier of using Django.

And I got really kind of frustrated before because I would see text on it, you know, like we'd see a typo, and then with Django by default, nothing against Django, but you know, you have all these great models, all these great apps.

But when you try to find text, you have to go and search five or six different applications to find that typo.

Then you still have to come back to GitHub, maybe, or get, and then get grep to try to find that typo.

So it could be in a template, it could be in JavaScript, it could be who knows where it's buried at.

And so when we made the decision to just use GitHub pages, it meant that anybody with a web browser without using Git could just go and make changes there.

And it just, I mean, we have like hundreds and hundreds of contributions every year from it.

And even like when we let speakers know they're speaking, we can send you a link to your actual you know presentation and you can go and submit to change your bio to be what you want to upload new photos and stuff.

It was really easy from that perspective.

And I wouldn't have yeah, waited through a complex Django thing to do that, probably.

Or a series of blog pages.

Or even you know, outputting from a Django thing to that stuff.

I think reading and writing from front matter is a should be a solvable problem.

Um I'm blanking out his name.

That where he he did this, um he built his own static site generator, except he's quite brilliant and prolific and he shipped it.

And it is a Python-based static generator that um it's basically that in Pelican, but Lector is quite a bit simpler and um and people are still working on it.

I think there's there's a I still get the emails from the the team, so uh you know uses Jingia too for templating um since he wrote that as well.

So yeah, I don't I'm not aware of a Django version.

I don't I don't really know if I there should be a Python one.

I find Pelican a bit complicated and Lecter I really liked when I was using it, but I just defaulted to Jekyll out of laziness.

So that's the one thing I know that's a little intimidating for people when it comes to like Jekyll and front matter is you know sometimes to to render your templates you need data to be in certain formats and places and stuff.

So and I think Django solves a lot of these problems too.

My other wish list for smart people is to take the DRF.

I would love to see DRF be part of Django, which you'll you can edit out of here, but

no, I think

But so um uh Django 3.1, I think it's 3.1, it might be 3.0, but introduces the first sort of steps towards um content negotiation in the in the request.

So we've got the accepts method now where you can then it will interrogate the request and tell you you know, does it accept you know this particular language or this particular you know response type or whatever?

And that's the first sort of stage towards content negotiation, which is what DRF really brings you, right?

Okay, the serializers, but that whole um multiple renders, multiple passes thing.

If we could you know pull some of that into the core, I think that would be a good project.

But that's gonna be over time because DRF does what it does very well, and there's no there's no incentive to port it.

And then Tom Christie has some really interesting experiments, like is it type system or something?

Is the I'm gonna pull serializers and forms into one thing.

Like I've used it on several projects and really like it.

And my problem with Django is when I go back to using form code, I miss so many features from serializers that it kind of makes me wish there was an easier, you know.

Like if I could take the serializers from DRF and add form abilities to it, I would I would live with that type system library, and you know, it's just so good.

Just melding those two together works really well for me.

No, I mean yeah, it's good stuff.

It's good stuff.

I think we're we're coming up on time.

Are there anything we didn't mention or that you want to plug, Jeff?

Um for listeners.

Early morning.

I should be better plugging.

Um, I mean, we'll have my website in the show notes, which is good.

Yeah, check out my website, jefftriplet.com.

Um, I'm Webology on Twitter.

Uh Django News, if you've got ideas and stuff.

I I really like hearing from people as long as you're not trying to pitch your product.

Um, tweeting at you know, Will and myself is always good because we definitely consider those.

Well, thank you so much for coming on.

Thank you, Super.

Oh, yeah.

I was gonna talk to you about Tailwind because

oh yeah.

Tailwind, give me some tailwind

love, Chif.

When I first got into web, the one thing that really annoyed me, and not all designers, which I have to I hate saying this and to start a phrase with it, but I I met some pretty profound uh designers who are known as the best in what they do, and they were really nice people, but I found everybody else around that community to be very, whether intentional or unintentional, gatekeepers to design and what the process was like.

And so I've always found anything to do with design, this weird process of you know, no matter what you do, it's like getting hit with a stick that you're doing everything wrong with design.

And so when SaaS came out, a lot of the same designers were like SAS is a bad tool for these reasons, and so I've just always been used to really negative experiences with design world, other than like personal designer, friend designers, you know.

And so frameworks have always been very unapproachable to me.

I think Bootstrap was the first project that I saw that I thought was very, you know, I could just take HTML and build things and it look okay.

And Tailwind is kind of the opposite of all of these frameworks, where it is a include your CSS, um, it has a defined kind of style guide, a guide sheet for how to like do grids and colors and different things, and you can just take those, drop it in line, and have something that looks really good.

And I really appreciate what the designers behind it have built because they have a couple of courses which I think are good, or a book that's really good.

That it just kind of teaches you like not only like these are the options that you have, but kind of sets you up so you can fiddle with the design, so you can say, like, you know, here's borders, but I don't know why this border doesn't look like or doesn't look right or why these colors are off.

And so Tailwind to me is the right level of fiddly that if this thing looks too dark, you can just you know drop it back 10%.

And they kind of teach you how to fiddle with your designs to get something that looks better.

And I really appreciate their you know approach to this as well.

But it seems like it's you know, because there is that like everything looks like bootstrap.

It seems like they're trying to have more options than just it looks like bootstrap, but still in the tailwind.

Do you like it?

Yeah, and I

For people who use bootstrap, there's nothing wrong with using it.

Um the worst thing for me is starting with a blank page with HTML and trying to figure out how to create something, like it is the most overwhelming feeling, and I have so many projects, I have hundreds and hundreds of projects, and so many of them I never got to the design part because it was just so intimidating to start with nothing.

And so I think bootstrap really does a good job of giving you a lot of the batteries.

The only issues I have with Bootstrap is when I want to create something that bootstrap doesn't do, the barrier to learn is really hard because you not only need to know SaaS or less that it's built in, you need to have a really strong fundamentals in CSS, but then you also need a strong fundamentals of how the bootstrappers particularly use their framework.

And so I just find it to be impossible to use.

Tailwind is pretty easy.

I think they're using post-CSS, which is just like wrappers on top of CSS, but you can you the code is approachable, it's easy to look.

Well, you can look at the code and see what's going on, and it's pretty easy to remix what they have.

And so I've really every hour I put into it, I feel like I learned something new, and I'm I'm actually learning design skills for once.

And so I just appreciate everything they're doing from that perspective.

So if you're a Django developer who have the same annoyances and complaints that I've had, then Tailwind is is great.

I've had, you know, similar experience with struggling to, you know, because obviously I'm a developer, I'm a backhand guy, you know, and not I don't claim to be a designer, but it's nice to be able to cut come up with something that looks presentable.

And then if you hand it off to someone who can make it look better than presentable, then that's great.

Yeah, and I think um and I think Tailwind gives you the tools for that.

It should be, you know, semantic, it should be based on your content.

And it's like, but you know, they're like, what are you gonna do if you ever need to change your text-red to some other color?

Maybe we change the title of our blog post from red to blue.

And so, you know, as a developer, it's like, oh, I'm gonna do a find and replace, and I'm gonna, you know, change text-red to text-blue, and I'm just gonna change it all and save it.

And they're like, No, you would never do that.

And it's just this weird set of rules that I, you know, I didn't probably articulate it well earlier, but I've just always been very eye-rolly about you know how hard it is to do design because of these unwritten rules.

And a lot of like things that I think Django does well is not doing the same thing to developers, and so and if we do, we need to cut it out because that's just not cool.

Glad we got that.

No, no, no.

I mean, with design, it's it it there is a lot of mystery, though it's it can be analytical, and it is true that I think when you when you're a professional designer, you have opinions on how to structure and architect CSS.

Um, but maybe you don't articulate that as well, and maybe it doesn't apply as much to just individual solo projects.

I've waited 20 years, I feel like

And it's I don't really care about those in the classes.

That's just such a good moment because I know a lot of I mean, I work with a lot of developers, and you know, it was soon in ever every designer completely rolls projects differently with the way they do their SAS and design stacks.

And it's so hard just to try to go through and figure out somebody's framework that works really well in their minds, but it's not communicated well.

And so I really love the tailwind.

You know, even if you don't know how it works, you can kind of figure it out by, you know, let's try changing red to blue and see what happens.

Okay, we must go.

Thank you so much, Jeff, for taking the time.

Um links to everything in the show notes.

Always a pleasure.

Thank you.