Calvin is the co-founder of Six Feet Up, a Django consultancy that also runs the upcoming online Python Web Conference. We discuss ideal developer environments, Apache Airflow, Kubernetes, testing, and more.
This podcast does not have any ads or sponsors. To support the show, please consider purchasing a book, signing up for Button, or reading the Django News newsletter.
Will Vincent 0:06
Hi, welcome to another episode of Django chat podcast on the Django web framework. I'm Will Vincent joined by Carlton Gibson. Hi, Carlton
Carlton Gibson 0:12
Hello Will.
Will Vincent 0:14
And we're very pleased to welcome Calvin Hendryx-Parker back on to the show. Welcome, Calvin. Hey, well, hey, Carlton,
Calvin Hendryx-Parker 0:19
how's it going?
Carlton Gibson 0:20
Very well, thank you for coming back on going.
Calvin Hendryx-Parker 0:22
I'm excited. Yeah, here,
Will Vincent 0:24
this has turned into an annual thing. So lots of talk about Python Web Conf, Django, cons pi cons. Maybe? Like, what's been new the last year for you? Right? There's a lot of things. But what, what's top of mind when someone asks you, What have you done for the last year professionally?
Calvin Hendryx-Parker 0:40
What were the highlights professionally, we've done a lot recently with airflow. So I'll be giving a talk this year at PyCon, on scaling to 1000s of DAGs with airflow, which is Django Under the covers, which I feel is appropriate to bring up on this podcast, that it's a really, really cool product. For those of you who have not gotten into orchestrating, like your ETL loads, or we use it for other things, too. We've actually used it to orchestrate on manufacturing floor processes, you know, robotics, like interesting, like kind of crossovers into real world physical things. And then we do also use it for some traditional data loading ETL type activity as well.
Carlton Gibson 1:22
So I used airflow a little bit, the thing I think is really exciting that I could perhaps get you to riff about is the DAGs the the way you define the task dependencies and keep, perhaps explain that for folks, because I think it's really interesting,
Calvin Hendryx-Parker 1:36
right? So basically, you can think of airflow is just a really, really glorified cron, or if for those of you in the Django community, I mean, it's like celery, you could do asynchronous tasks, and have it run these various things in some sequence. That sequence though, is super customizable with Python. And so you can define task A, B, C, D in some order, or those can branch. Now the whole thing with a DAG, it's a directed a cyclical graph, which means it can't cycle back onto itself, there's no loops in a DAG, technically. So you're actually going to be making decisions about what paths to follow. And like there can be failure situations and recoveries and actually run certain tasks in parallel. So you may have a thing that starts, but the next step may be highly parallelizable. So you can actually take it, split it up into 100 separate processes that can all run simultaneously. And then as they all finish, they kind of report back in. And then they can kind of come back together and run the next set of steps and things that are on there. And there's a couple ways you can actually define DAGs, you can use just plain straight Python, put it in the DAGs folder inside of your airflow instance. And it'll pick them up, it looks every so many seconds to refresh that folder to see if there's more DAGs have been dropped in there. You can also define the dynamic tags. So DAGs that are like dag factory, so it basically can dynamically instantiate and generate your 100. Well, I'll say hundreds at this point, because 1000s really isn't realistic. That's actually a limitation we ran into with a big project we were working on. And that's what I'm talking about, at Pycon this year is the fact that as those things scale up and dynamic DAGs, you run into timing issues that the scheduler looks for new DAGs, the the dynamic tag starts building a dynamic set of tags, but if those two times start meeting, that's when you run into real, real trouble, because basically, the schedule starts looking again, and you're not done generating dynamic tags, especially if you've got an order of 1000s. And then that was the case we had which was 10s of 1000s of DAGs in a single airflow instance. And I told this to some people who were in the data world, and they were like, that can't be done in airflow. I go, we did it. There's an interesting workaround. And then if you want to post a link to the blog post on our site, we actually posted how we did it. I mean, there's no there's no trade secrets here, we want to help the community. But it's pretty cool. And that's what I'll be talking about and just kind of giving some insights into. There's some cool workarounds with Python that actually helped in this case, where we actually have one, we still have one DAG, but we aren't using the dynamic dag factories, we actually have a process that comes through and writes out names of files that are all symlinks, back to that single file. And based on the name of the file, we basically substitute in new configuration, new sources of data, and actually can now scale this to still 10s of 1000s. Because the the reading in of single Python files on the file system is fast that that part's superduper fast. So it's really not an issue is when you get into the dynamic DAGs and trying to generate 1000s of them in memory and dynamically. It slows down considerably. That's really cool.
Will Vincent 4:36
Can you talk about how you like the progression to getting up to airflow was this like, Project read? Did you start with celery and then you went to airflow like how do you reach for airflow? That's always my kind of question.
Calvin Hendryx-Parker 4:49
I guess it depends on the problem space in this case the the customer was using another they were using a different orchestration stack called it was a PowerShell when DOS, you know, orchestration tool that was kind of a glorified getting glorified cron, but they had bent it in, in awkward ways that were very hard to maintain. And they were also looking to basically get in line with best practices for big data. And which seems to be using Python, or, you know, there's a few other kind of common Java couple languages that are in there. But they wanted to be on Python, because they think it's going to be the easiest way to onboard new data engineers, you know, people coming out of school people who can jump in and actually be productive pythons awesome choice, obviously. So that's that was the reason they came to us was really to actually, first review some of their Python notebooks, they've done some Jupyter notebooks that were running in data bricks as part of the ETL process. And they wanted to code review them, see if they're up for best practices, and just kind of start digging in and seeing what was actually going on inside their whole architecture, we realized really quickly like this can be done with some open source tools, they probably can actually minimize the reliance on some proprietary licenses. So spend more money on their own people getting them up to speed on Python and, and notebooks and things like that, as opposed to spending money on licenses for big proprietary pieces of software that are that are actually hard to configure and use in an automated fashion. Those are a lot of point and click drag and drop, no kind of analyst were type tools, where they wanted to be able to check this in, have it be all automated, have CI CD process, actually do continuous integration, have tests on their configuration files, so that they can detect problems? Before they even go into the dev environment?
Carlton Gibson 6:32
I think something you mentioned there is that about the hiring process, because if you use like, you know, so there's that paper about using boring technology. And you know, Django is always a boring technology, or Postgres is a boring, but, you know, Django is cool, Postgres is cool. But in this sense, they're boring and that they're the known commodities. And airflow, I think, actually is made its way into that category. Now, it's a standard tool that's reliable known by the community. And if you're using that tool, a you can have less dependencies, less sort of niche, niche bits, which are custom and bespoke, and needs special knowledge to run. But you can hire someone new, you can say, hey, we're using Django, we're using Postgres, or we're using airflow. I think that's a
Calvin Hendryx-Parker 7:18
great idea. And I think it's worthwhile to link to that article, that blog post, I go back and read it every couple of years, just to remind myself that all the new shiny things aren't, you know, always, there can be trouble in those waters. It may look like greener pastures, but it's the boring tools get the job done. Well. Now, I believe in instead of doing bleeding edge, I do believe in like leading edge. Like I feel like we want to stay on top of what is the best practices, and Django absolutely sits there. In that leading edge. Still, best practices is boring, but it's productive, and it gets the job done. And it can scale and it can do small things, and it can do big things. And then people have taken it to build awesome tools like airflow.
Carlton Gibson 7:58
My analogy with surfing at times it's surfing, you don't want to be in front of the wave, because you know, you're paddling. It's a lot of hard work. And if you're behind the wave, well, you know, you sort of just stopped going anyway, you've got to be exactly on the wave. Right, right.
Calvin Hendryx-Parker 8:11
Yeah. Yeah, it makes sense. Well,
Will Vincent 8:13
I mean, the also the version of that, I mean, because Silicon Valley loves that analogy is, you know, you can be the best surfer in the world. But you got to wait, you got to be on the right wave, right? Because it's frustrating. You see someone else feel like they're, they suck at surfing, and they're just like, killing it. And it's like, wow,
Carlton Gibson 8:28
gotta finally got a Malibu longboard, and they're just going. So that guy, Can I Can I ask you about the psychology of the the catnip, the the new? And that because it's part of it as a programmer is like you always want the new tool. Do you always want to play with the latest this laser? What's your thought that because how do you resist that? And?
Calvin Hendryx-Parker 8:50
Well, it doesn't affect everybody. I mean, there are probably 90% of the developers in the world who are sitting happily doing the work they're doing day in and day out, and maybe not even looking to the sides like what's going on. But not That's not me. That's not a lot of people I hang out with so maybe you just kind of you're always you know, birds of a feather flock together. And maybe we're all just hanging out together, Carlton, because that's what we're really trying to do is like
Will Vincent 9:10
your consultants, right? You're consultant to I feel like, I think you're sort of interested in a lot of variety and the new thing anyways, right? Like it's not, right, like you get air dropped into cool stuff. You're not maintaining, like, my iteration questions, assume that you built it from scratch, whereas you get brought in when they're like up, things are broken. Like you kind of want a consultant to be up on the shiny new thing and to have a take.
Calvin Hendryx-Parker 9:33
Yeah, that's true. People do rely on us to kind of vet out those shiny things to make sure that they're not making the mistake down, you know, a couple years down the road because everyone would love to be able to build a piece of software and just launch it and be like, Okay, looks cool. We're done. Like it's awesome. Like, that's not true. Like you build software and then you have to maintain that software. You're now jumping on the treadmill with your your product and hit the key you have to keep putting work Get into it to make it still working day in day out. Now the back to the kind of shiny question I think we do a lot of in house like, show and chairs like, you know, kind of a kindergarten like bring bring your favorite toys to school and show it off. So a lot of every developer kind of gets an opportunity now to show off or look at some cool stuff. And then everyone gets to see it and talk about it and discuss, like, what their thoughts are on it. So we've gone back and forth a lot on especially JavaScript technologies, because we're historically been more of a Python shop. And that's, you know, things we've always done have been Python. But there's no ignoring the importance of JavaScript and now TypeScript in our, our, our day to day work. So understanding what's our approach? And like, what what do we care about in these various technologies? How do we want to actually like, code code for them, but in linters, like, where are guardrails for doing a new a new piece of technology? Those typically come out and those kinds of tech show and chairs.
Carlton Gibson 10:57
Yeah, and I think in JavaScript, managing the tech stack is all the more difficult all the more like, pressing, it is tricky.
Calvin Hendryx-Parker 11:05
I would I would definitely agree with that.
Will Vincent 11:07
I think that's, I mean, that's great to have to have that internally. Because that is I think, in any field, you know, if you're like a musician who plays, you know, rock and roll, you probably want to do jazz or like, if you're doing some big project, in programming, it's nice to just spin up a greenfield thing, like, you need to keep that beginner's mindset and that playfulness, which you can always maintain if you're only working all the time. And something does. I mean, I remember when I was, you know, in a previous life, I was a book editor. So all I did was read, but reading with an ad, I guess, as an eye to something as opposed to reading for fun. You're like, Why the hell would I want to read for fun when all they do is read, but like, you lose something. So like, building that into your company, I think is, you know, really important, because otherwise, you just get stale. And yeah, well, there's
Calvin Hendryx-Parker 11:51
a certain passion people have to have for the craft that they're doing. Actually, that's one of things we look for in a developer who would join our team is going to be a profile we call a craftsman, they've actually renamed it since then. But we use a couple of assessments and tools to look at the whole person that we're bringing into hire or interview. And one of the criterias, there's some indicators and markers from some specific assessments, they're not the end all be all, whether we're hire a person, or even interview a person or not, they're just one more piece of data point that we can actually look at. And knowing that they're in that craftsman. Arena, means a lot because they've got just kind of certain motivators in their life about, I'm excited about technology, or I'm excited about the craft of it, or I want to build, as opposed to the other people who have different skills and different like passions, and they suit better into different spots.
Carlton Gibson 12:42
Good. Nice. Just ask one more question. Are you talking about hiring then and teams and craftsmanship? Do? Do you have like, a kind of standardized tool chains and standardized processes so that people can switch between projects? And that, you know, the tooling is the same or
Calvin Hendryx-Parker 12:56
we are absolutely working on that? Yes. So we there's, some of that depends on the client, because we are consultants. And so some clients have, maybe they're on Jira, and we want to use Bitbucket or YouTrack, or GitLab, or some other tools. So one of the things we're working on right now is really the developer experience at six feet up. And taking that developer experience and applying it to the client in a way that they see a lot of value in it that they may adopt that best practice, we think we feel like is a best practice in software development lifecycle. So absolutely being able to use, well, everyone kind of picks their own IDE, but things like pre commit hooks, you know, having those setups so that everyone's running black, everyone's running eyesore, everyone's running pretty fine or prettier on JavaScript, so that those common guardrails happen before they even hit the CI pipeline, that helps like get everyone in the same, you know, rowing in the same direction, when it comes to their development tools and stacks. They can use whatever IDE they want, but the code they're going to submit, it's going to kind of comply to some internal standards. And then using tools like we're really rapidly adopting Kubernetes. And we'd had adapted, you know, containers because that actually leveled the playing field for folks to be on a Linux, Mac windows and actually be just as productive in any any of those platforms. Now, the next step is actually adopting Kubernetes. So that the process of deploying and developing almost looks identical. There's just you know, different versions of the container you may be using for development that has the Dev Tools installed, or the PI Dev D extension. So you can do remote debugging. But when you're releasing that container into production, that whole process, the whole stack, doesn't look unfamiliar, because it may look unfamiliar now if you're developing locally on Docker Compose, but releasing into Fargate, or some kind of Kubernetes. The developers like I have know nothing about the deployment process is there's zero attachment other than the fact there's a container that runs my code.
Will Vincent 14:50
Sounds nice, Carlton, right. Simple deployment.
Carlton Gibson 14:52
It does sound lovely, sounds lovely. I mean, you know, I think the key bit there is keeping the dev and the deploy, looking similar. looking the same like you,
Calvin Hendryx-Parker 15:01
we've always strived for, like our QA or staging environments to be identical or as close as possible to production. But bringing that a step back further into the development environment without it being so onerous to run, I think a lot of the issues before is if you wanted to run a full stack of stuff locally, and you were doing a Django app, but you want to be able to have the nginx and load balancing and the Redis cluster and the postgres cluster and all these other kinds of pieces running, well, you either had to install them from like homebrew onto your Mac, and then maybe you had a slightly different version that was within QA, or there's some always these little rooms for strange edge cases to sneak in, because of that. But if you start using these Kubernetes manifests, you're using the same manifest, but just define different environments. So there's the same versions of all the containers being run same versions of the database, same versions of Redis, same versions of everything now, it seems to be a lot more reliable, and, and repeatable to do those deployments.
Will Vincent 15:55
Well, that's that I want to ask you about your bootstrapping, local Python environment talk, actually, because Carlton and I were talking about this before he came on, but it is true that like, my three books, the third one just uses Docker, because I'm like, okay, like, you know, containers, you're all set. But that's not, that doesn't work for beginners are all edge cases, even though maybe in a more professional setting, it's just like, just containerize it.
Calvin Hendryx-Parker 16:22
And that's what I get to at the end of my talk. So we could go ahead, Carlton
Carlton Gibson 16:26
will know, because it's, it's not necessarily for me, it's not necessarily about professional versus amateur, it's about sort of the kind of complexity of the team and the complexity of the stack. So, you know, if it's like a small startup, you know, 555 people in a team, you may not have the ops chops to take on something like Kubernetes. Whereas if you've got a 20 person team, you want to have that ops person there, who's making sure that those 20 people are all doing the same thing. And it depends if you're just running, just running Python, and, you know, you've got a hosted hosted Postgres, and you know, maybe you've running Redis, that extra opscode complexity doesn't necessarily pay for itself at the small scale. But if you've got a bigger team, then sure. It, I think it
Calvin Hendryx-Parker 17:13
does, I don't think it precludes you from using containers. In either case, even for small small scripts, we still use Docker locally to run a single python script, because you can guarantee the version of Python is gonna run on a guaranteed like user space inside that container, it just narrows it keeps everything so much more sane. So I even even now, and there's one thing that got again, I got to at the end of my talk at Pycon last year, was that Docker was really the way forward I think for especially developers who are across a heterogeneous environment of OSS, versions of classes, versions of Python, how they got installed, where they, you know, you don't know where that Python came from. When you type Python, the command line, I can know, I know how to guarantee I know where that Python comes from. When you wait, Docker run my image.
Carlton Gibson 18:03
So So what's your answer to how do you bootstrap your Python? By
Will Vincent 18:06
the way? Sorry, I want I want I want I want him to do that. I just want to make Okay, well, I'll just cuz I've had, I've had this, I've had this conversation a lot with readers. You know, and so one of the one of the major things I hear from from people around Docker is, you know, you need a nice laptop to run it. A lot of you need a lot of RAM, or more, you know, so it is a barrier, someone, you know, who doesn't have a lot of money, who doesn't have a nice, you know, fast laptop, Docker sometimes is a non issue. So
Calvin Hendryx-Parker 18:44
well, that's that's the reasons we moved to Kubernetes. Which sounds odd to say, because, yeah, explain that. The reason we've started using tools like Kubernetes is actually if you're running Docker and Docker Compose, you can run a docker instance remotely on some other machine and actually, like you know, from your local machine, control that through the Docker, control plane, or even compose now the issue as a developer is you want to be able to bind mount your source code into that, that container when it's running, so you can debug or change the code and have it auto real hot reload, like Django or the React code, have it hot reload for you. That's that's almost impossible to do on a remote machine. If you're just using straight up Docker and Docker compose because of the whole bind mount limitation. Now tools like scaffold and Kubernetes changes that model can actually no actually scaffolds faster it syncing files into a container or running container. Then Docker is at bind mounting because of the IO complexities that Docker brings to the table. Now they they fix some of these performance issues in Docker. It used to be terrible. I don't know if you've ever developed kind of few years back on Docker, where you're buying running in there and changing or had a large project that was bind mounted into a container but the IO was terribly slow. But you get around that if you start using alternate tools, like for example, I mentioned scaffold, which can synchronize it watches for filesystem changes, synchronizes just those changes into the container for you, and then you get the hot reload capability. And now you have the ability to actually dev locally work on local files using your IDE and all your, your standard developer tools that have those synchronized into anywhere, you could have a sidecar like, small little Intel tower, sitting deskside or, or could be cheap, you know, droplet in Digital Ocean someplace that is actually running micro, micro Cades, or mini cube or, you know, you've got some lightweight, single node Kubernetes option for development. And now you can spin up for the couple hours, you may needed a day to work on that specific project for pennies, like all the ram you want.
Carlton Gibson 20:54
I mean, related there, I've recently become quite a fan of the Code Spaces integration to GitHub, because I've just taken to that pressing Yamo and a repo just pressing the full stop and it convert, and it just flips over to this GitHub doc Dev, and I've kind of vs. Cody type thing loads up and then you think, Oh, actually, I need I need a an actual I need natural computer here. So you, you just go Oh, load this into a code space, and then it refreshes. And then you're like, Oh, do you know what in the browser, it's a bit of a pain, I'm going to switch to VS code on the desktop. It's like, that's quite nice. And I've been I've been a skeptic for a long time, because I, I really love local development. For all the convenience,
Calvin Hendryx-Parker 21:37
it makes developing on an iPad, a reality, like the iPad Pro. Now, with the new especially with the new stage manager, when doing the difference between a MacBook Pro and an iPad Pro is becoming very, very slim. As far as the user experience and usability. Sorry, you can hear my dog in the background there. Yeah, this, we liked the dog bring the dog more often. Yeah, he's quite cute. But I love that portability. I want to travel with just my iPad, but I still want to be able to jump in and fix a problem if I need to. Although my, my leadership team would tell me, I should stop that and actually rely just on my team instead of me doing those kinds of things. But I still love to tinker, I still want to develop and be able to do it from an iPad wherever, you know, hooking up a keyboard, and I've got a mouse. And now I'm in code spaces or some remote compute environment. There's ways that way I should the iPads dang fast. But it's so much nicer to have a cluster of machines in the cloud someplace that I can resume into. So if I was at a coffee shop, pick up, go back to the room or whatever, and then sit back down again, like nothing, nothing happened. Like I've just I'm back into flow again.
Carlton Gibson 22:44
And it gets over that limitation of the you know, the the iPad OS where you can't run. You can't you can't really run a Python interpreter or you can't run a grass compiler or you can't run a you know, anything. We're No, it's all on some box somewhere in the you know, Ethisphere
Calvin Hendryx-Parker 22:59
Yeah, I think for developer experience, it's, I think it's a big advancement for let's kind of roll back to those developers who are not the bright, shiny lovers, they want to just come in, do their work, go home. I think for those developers, this is a great innovation for them is that the people who do like the bright and shiny can set up the most amazing development environment and now share it like a rubber stamp to everybody in the whole team. And now they can all share in those same productivity tools that the you know, the one person who's super passionate about getting all the power tools in their environment, their dot files are 1000s of lines long, because they just love tricking out every aspect of it. That might be me. But I can now set this up for everybody and be like, check this out, like here's during a show and share, show them all the cool new few superpowers that are available to them on their command line or in their IDE or in their editor. And that just goes a long way because some of them be like, Oh, that's cool. I would use it if it was easy set up. Those are things aren't always easy set up, but they can be shared with others easily. Yeah, so
Carlton Gibson 24:00
that dev can take the approach. That's yeah,
Will Vincent 24:03
well speaking, I want to maybe we've already covered some of it but your PyCon talk about bootstrapping I noticed your command line. You've got that nice little timer thing for commands like a little hourglass I was because I mean I'm not fully tricked out but I you know, it's fun to do, but I was like, Oh, I hadn't seen that before when you're doing some commands locally. So yeah,
Calvin Hendryx-Parker 24:24
so I used a camera with what phase on my computer that so I'm again I'm a tinkerer hacker I love fiddling my my laptop all the time. For a while I was using the bullet train go command line, but that got it went kind of unmaintained and I finally graduated into power line 10k Or I think it's what the current one I'm on. I've been really happy with it. It's but it's infinitely configurable. You can spend a couple of days running through dat files. If folks aren't curious. My dot files are on my GitHub so you can actually just go to github.com/carbon HP slash dat files and see like the my configuration I use for the powerline 10k stuff. And it's, it's, it's so nice. It's nice to have all that extra data right there available to you, especially that time, which more valuable than you think. Because as you are running commands and doing things throughout the day, you pick oh shoot, how long did that thing take to run? Or you know what time was I working on x, because maybe I needed to jot it down into my like time sheet or whatever, I can definitely scroll back through my buffer my terminal now and see oh, that was at like 1015. And it took 10 minutes to run and just provides all that additional context, especially the virtual environments, but to like, knowing what the system Python might be, or what the virtual environment you have activated, actually is can save you a lot of mistakes. I don't know how people will go with a prompt that just has the dollar sign. Like mind boggling like,
Will Vincent 25:45
well, that's yeah, I mean, you need at a minimum, you need to have the get the good stuff to let you know, if something's changed at least a
Calvin Hendryx-Parker 25:52
minute. You say minimum that how many people have you're, you're seeing like, open up a terminal. And you're like, who Oh, boy, we got some work to do here. Like there's they're just, they're writing pretty stock. However,
Will Vincent 26:01
I try really hard not to immediately judge them. Right.
Carlton Gibson 26:06
I'm trying to judge.
Will Vincent 26:09
Because, no, but it's, you know, it is it's like it's like site design, right? It's like Simon Wilson's site, right? It either like their terminal looks like that. It's like they're either Simon or they're not. You know, that's immediately I'm like, it's an extreme here. That's what I think. All right. Wait, wait, wait. So I mean, so your your talk, though, local Python is a challenge. I thought, actually the best job I've seen of laying it out. I did want to ask you, though, you I think you punted a little bit on like, how do you recommend people install Python, because you mentioned there's like,
Calvin Hendryx-Parker 26:43
I 100%, recommend Python for installing a version of Python. Any other Python can be as untrusted and possibly incomplete. That's been a huge pet peeve of mine, that fact that you can install Ubuntu, or be using an Ubuntu container, and you won't have necessarily PIP available or you won't have some some of the standard library modules will not be there because of some opinions that the OS makes. But And most likely, they made those opinions to protect the OS. They don't want you randomly PIP installing something into the global environment, which is a good thing. But it means that you really need to be installing Piave. So you can control which specific version of Python you want. And I recommend installing PI M with the virtual env extension. So you can just from right, right from one command line, create the virtual items, activate them. And now when you go into those directories, or out of those directories, it automatically activates and deactivates those originalists. I'm never typing, activate, I'm never typing work on, I'm always just relying on the dot Python version file, it's in my path that just picks up what I should be doing wherever I'm at. And I'm moving from project to project a lot, and may not be common for most people. But it's actually far more common in thing because you probably developing side tools that you're using as part of your course of your work. And those should be in separate projects from like the main project you're working on. And they maybe have different requirements than the main project you're working on, you may have a different version requirements that you need to pin specifically for that side tool, as opposed to the more stable project that might be running on an LTS version of a library or a project.
Will Vincent 28:16
I like to in your talk you mentioned or you recommended PIP X for, you know, global global things like black and stuff that you want.
Calvin Hendryx-Parker 28:26
Yeah, for folks who don't know PIP X kind of takes a lot of that headache out of the way. And also, I think you get more recent versions of some of those pieces of software. So you could brew install, black or I sort I think those packages may be available in homebrew. But they're not going to be as up to date as if you Pip pip installed them from pi pi. Because those maybe the latest version is maybe the Homebrew maintainer hasn't gotten to updating the entry in the Homebrew package catalog. But PIP x gives you the best of all those worlds where I can now PIP X Install black, it installs and it creates a virtual environment behind the scenes in a dot directory that you don't see. But then it also puts the tool into your path correctly. So you don't think about it, you just type black, and it's in your path, it's going to work, it's going to always be pinned to the right versions that are used for that version of black. And you can install, you can inject other dependencies in there. For example, if you're using like the markdown tools, and you want to install pigments into that virtual environment, it's it's very possible, it's absolutely possible to now inject the pigment Smith's library to that version of the markdown virtual environment and use it with your pay marked up by the markdown man, but have a different version of pigments. You may use standalone from the command line because they're in two separate environments.
Carlton Gibson 29:38
So the case I have is with sphinx because you always need extra, you know, plugins and things would think so that so there's one environment, it's got all the Sphinx bits in and like Yeah,
Calvin Hendryx-Parker 29:51
yeah, and I've been I've been checking I've been using chez moi for my dot file configuration management. So that that tool allows asked me to actually have a chez moi and nit bootstrapped command. So basically a text file design defines on the very first run of this dot file manager, run these commands. So it basically goes installs, homebrew installs, Pip X installs all my standard utility so that every command I expect to use now will be available. And that's a big complaint people had about customizing their doc files and customizing your shell is you log into some random shell to debug something and half your stuff doesn't work. So your muscle memory is all broken on your keyboard. You know, memory is missing. For me, I log in. I literally do shame one NIT Calvin HP because it comes from my GitHub. It knows to look and GitHub to get the dot files to run that first bootstrap command. And maybe it takes 30 seconds to a minute, but everything now just works. Yeah, that's
Carlton Gibson 30:51
that not having a tool when you log into a strange box. That's kind of why I keep my my setup quite vanilla is that
Calvin Hendryx-Parker 30:59
there's no reason checkouts.
Carlton Gibson 31:03
There is I'm old.
Will Vincent 31:07
Speaking of speaking of being old, Carlton, can we tease your PyCon Italia keynotes because it's out? Yeah,
Carlton Gibson 31:13
yeah, you can. So I've been I've was invited to keynote at Pycon Italia. And I'm doing a keynote called open source for the long haul, which is, you know, about what it says. And but the kind of the, the relevance of being old is it's kind of the, the counterpart to the growing old gracefully talk I did five years ago when I in Heidelberg when I started following, and now I'm finishing fallowing, and I'm doing a kind of talk. Okay, so, and, yeah, this is the reflections. It's not explicitly a reflection on that. But as I'm writing it, it's a reflection on okay. That's what I said five years ago. What would I say now? I'm quite excited about that
Calvin Hendryx-Parker 31:54
article. Watch. I'm quite interested, I followed your journey from the beginning as a fellow so curious to see what the wrap up is. The post mortem. We're not dead.
Carlton Gibson 32:07
Now, but you I mean, part of it is you've got to be able to step away before you become so
Will Vincent 32:15
well, segue to conferences Python web conference. Coming up. Yeah. In a couple weeks, March. Right. Yeah.
Calvin Hendryx-Parker 32:22
March 17th. Through the 23rd. I think that's, that's, yeah, we'll have we'll have a link. Right, I'll be in trouble. But
Will Vincent 32:30
we'll put a link but it this is, um, you know, speaking of watching things grow over time. I mean, this is really, yeah, up and up into the right. Fifth year, but I mean, the speakers and the number of people and everything is really impressive. I saw actually, you did some videos, you did one with Al Sweigart. But like, you know, even teasing out you know, guests now. So it's really impressive to see there's more
Calvin Hendryx-Parker 32:53
of those coming. I think tomorrow, I'm actually interviewing Anthony Shaw, who will be one of our speakers from Microsoft. We've got two speakers from from Australia, who are joining us. I mean, that's the dedication, the the excitement level that the speakers have about this this conference is that they're willing to come at like three in the morning their time, and give their talk live to the crowd. But it has grown a lot over the past five years. We started this in 2019, as a virtual conference before he was hipped to be virtual. And it will always be a virtual conference. So one of the things I always love to tell people about this conference is is really meant to be accessible to those who may not be able to make it to a PyCon, or regional conference of some kind, we want to make sure that fills that gap. And the other part is I want to make sure it fills in where I feel like some other conferences may be lighter on the intermediate content. I think there's definitely a space for like the pike ons and the regional conferences to handle a lot of those newer intro talks to get people spun up into the Python community in a nice gentle way. We're really meant to bring some heavy hitting talks not to I would dissuade you from coming if you don't know anything about Python, but you're gonna be in a more advanced group of speakers, and guests and people who are attending the conference. It's really a lot of very professional folks who are doing a lot of cool things with Python. I had a kind of intro talk with or conversation of one of our speakers yesterday, they're talking about the state of fusion. So those of you who are kind of following the the fusion story right now that we finally had in the last couple of weeks, the first time that more energy was produced by fusion that went into than to make the fusion process happen. We have a speaker who's gonna actually get to talk about where Python is playing a role in that science. So I'm really excited. They're super passionate about, you know, obviously this topic. I know very little about fusion. So I'm looking forward to hearing about this.
Carlton Gibson 34:43
This wasn't the speed ups in python three point 11.
Calvin Hendryx-Parker 34:46
No, no, no, no, no, I don't think they use it in that lab level where the performance actually matter. They've got other things they're doing. But when it comes to data and accessibility and getting people on boarded, to be able to process all the data and actually come up with it new insights into what's going on in the science. Python is so hard to be, it's a great tool because it just provides people with so many superpowers, I mean, the batteries included, and then you layer on top of that, like pandas and matplotlib. And in all these great libraries, and just give people superpowers without having to do much work to kind of get to that point of having all those things at your fingertips is really a powerful story for Python. Yes. So that's what you would expect come to expect to see at Python web conference here, we're going to be five days, half days, East Coast time, we will have a keynote speaker kick off every day and a keynote speaker to end every day. I really love hearing inspiring speakers. So even though we are a virtual conference, we are having 10 keynote speakers as part of the standard program. And that will never change because I love having just big thinkers get up on the in our stage and actually talk about the things that are going on in their lives. And those talks range from technical to I've had some speakers who had barely ever used zoom before, who are non technical, give some amazingly moving talk. So if you look, last year's talks are online. There's a talk up there by a Nobel musica talking about the flower and it'll bring you to tears. But it'll move you to action and whatever that passion may be inside you. And that's what I'm gonna draw to people. And Mine just happens to be Python in the community. And that's just where I get a lot of energy. So I want I want to join me for Python welcome. suka.
Will Vincent 36:25
I don't Carlton, you know, with all your posts fellow time. Yeah, 2024. Carlton will be everywhere. Let's see, we were just talking about this. Yeah, actually, we were you might appreciate this. Calvin, I was sharing a quote about, you know, marketing, right. tech people famously don't like to do marketing. And it was saying that, you know, it's seem self involved to market, but it's actually more self involved to think just building it, people will come to it. Because Why are you so important that people care? Like,
Calvin Hendryx-Parker 36:58
it's so true that it's so many times people think that you'll build it, they'll come? How are they going to know about it? Who are you? That's going to bring them to it?
Will Vincent 37:05
Right? I mean, I try to think about this. Like, like movies, right? Like Tom Cruise, right? He spends, I don't know, six months making a movie, he'll spend a year marketing it, like Tom Cruise, right? Like, it doesn't matter how big you are? Because they know what's up, right? Like, if you bite, you know, the hard thing is you think all the time is spent on the making. And really, it's that long tail of, of, of marketing. So anyways, I thought that was good. It's like, Yeah, cuz it does feel a little icky to self promote, but it's like, but if you don't self promote, like, how does anyone know anything about you? So
Calvin Hendryx-Parker 37:37
yeah, that's definitely been a problem in the open source community, I think there's been a lot of resistance to people making money. You know, they feel like they should all be doing it for just the good of the projects. But these projects like Django wouldn't be around if there wasn't money to fund the initial seed of the project or the fellows to make sure they can kind of steward the project into better directions, or the companies who are submitting back the pull requests for bug fixes and security fixes. Because they needed them. There's still money involved. And it's not a bad thing. We shouldn't be upset about talking about that. And we shouldn't be upset about marketing yourselves as, as awesome developers out there.
Carlton Gibson 38:18
Like Eric Mathis was putting out some more content. And he was like he said on Macedon or fostered on whatever we call it. And I'm a bit shy about saying it's like, no, Eric, we want to know, we really like this easily. This is why we're here. Yeah,
Will Vincent 38:33
he does. He does have a sub stack. Now. I think it's mostly Python. So Right. But even even, you know, even the top Python book author. Yeah, feel feels that way.
Calvin Hendryx-Parker 38:43
So there's a lot of good people to emulate our model out there. I mean, Simon is excellent at sharing every idea and thought he's having in his head, and I love it. I want to hear more about the things he's dealing and he shared all the time.
Carlton Gibson 38:56
His talk that they gave at Django Con this year, was part of it. It was one small part of it, but was that the every commit needs to have like the documentation with it. And every project needs to have the blog post that goes with it. And
Calvin Hendryx-Parker 39:11
readme updates, the whole entry into the project is really important. And if
Carlton Gibson 39:16
and if you're not doing that bid, it's not done. Right. It was his kind of line. And I really liked that. It's like, yeah, okay, so I've got to write the docs here. And I've got to actually tell people about it. Well,
Will Vincent 39:28
Jeff Bezos, Amazon's famous for his executives, like you kind of like write the press release first, and then you figure out how to do a new project. So just that idea of like, yeah, working backwards, right. As opposed to like, let's just jump in and figure it out. It's like, you know, of course, which is what we all kind of do, but it is helpful to be like, and how are you going to describe it to someone, you know, it's like, Well, it's complicated. It's like near looks like zoning out immediately, you know, versus you know, I think it is good guardrails for yourself like what you know, as we see like, you know, squirrel, squirrel, squirrel of like interesting things we want to chase like, what, what, what's the guardrails that we impose on ourselves for project?
Calvin Hendryx-Parker 40:03
Anyways? It seems like there's been multiple attempts at like document driven development that they should never really caught. It's that's a hard leap to make to go directly from, well, I'm gonna write the docs first. And then I'll end up in tests, and then that'll end up in actual code that does it.
Will Vincent 40:20
Yeah, Doc test driven development. Yeah. That's pretty black belt level, to be able to do that.
Calvin Hendryx-Parker 40:29
I've never done it. So
Carlton Gibson 40:32
I mean, well, so I occasionally will write the test first. But normally, it's when I'm, I've got like a complicated algorithm or complicated process, and I've got I just wrote that little bit, then that would be one step in Okay, so I'll write a test for that one little bit. Okay. And then I can write the bit and then okay, I'll write tests for that bit. And then, in that circumstance, I'm writing tests. I'm doing test driven development, but very, quite often, it's the other way around. It's like that builds out some code. And now I'm going to write some tests. The other end. I'm saying the docs normal. Normally the doc start right now about wrote some books. Yeah.
Will Vincent 41:07
Yeah. Well, I can't and I wanted to ask you, I was Carlton, I were also talking about testing in that I got a reader asked me a really interesting question, which was, like, she is there a canonical encyclopedic guide to Django tests? Which I don't think I just, I wonder, like, internally, do you have something like that? Because it like, what is the point where it's like, okay, like, yeah, you test your models, views, templates, URLs. But like, for a beginner, it's hard to know, like, what's core Django? What's new? You know, where's that line where things become custom? And I've, you know, I don't I have some testing tutorials, but I don't have a great, you know, pie chart of like, here's what you need to make sure you have you have coverage other than, you know, running coverage. So I'm just curious internally, how do you think about that? Because I'm like, Yeah, I would love if that existed. And we could all agree, you know, like, here's, here's the 8020, right. Other than, like, when there's a new page, you should test, you know, test all the pieces of it. But
Calvin Hendryx-Parker 42:06
right now, that's really driven internally by the developers, you know, love of testing is going to determine how good the output may be. Luckily, on our side, we've got some great new developers who have joined the team recently that are very excited by, you know, test driven development. And so we do see more test coverage in our projects. And prior to that, it was just, you know, it was all new, or people weren't excited about it. But I think that there has to be a culture, like you have to start bringing in folks who are who are excited, they'll give the demos, they'll, you'll see the test coverage creep in or start happening. And with CI pipelines, when you have a failure, and you get a nice little email saying you you broke the build. That obviously is a nice peer to peer pressure driven development that encourages you to go fix and or add, you know, test coverage, because maybe you've got a rule that the coverage has to be x or that you're committed can't go through.
Carlton Gibson 42:59
Do you have the rule that whoever broke the build last is in responsible for running it maintaining it?
Calvin Hendryx-Parker 43:05
We do I mean, that that, that I keep seeing sometimes broken builds stay for a couple days, I'm like, come on what's going on here? Let's get back in line, had to go have a conversation? A couple people.
Carlton Gibson 43:15
I think if I was the beginning, I think he targeting for beginners, I'd say, like half a test, at least on the sort of main functionality of every bit like, you know, check that your homepage loads or check that the login button actually submits or or something. And then if you run that with CI, then if you break it, you know that you broke it, and you're like, okay, and the other thing, the other, you know, 100% coverage, well, that may be a bit too much right for but if you've got that kind of basic coverage over the core bits, it's like a smoke test that Oh, actually, I broke something.
Calvin Hendryx-Parker 43:45
I think there's value in writing those what seemed like silly, silly tests, like you're like, Oh, this is obvious. This should always obviously work. Well, if it should always obviously work. You might as well write the test for it so that when it obviously doesn't work, you'll know. Yeah,
Will Vincent 43:59
yeah. I, it's hard when someone you know, again, this is what I spend my time with someone who's so new, like someone who's saying, okay, because I have tests and all my books, but like, I can't write an entire book on Python. Well, I'm writing a book on Django, and they were like, Okay, we're using setup, test data, like, what's this class method? It's like, okay, well, like what are classes? You know, and then why am I using CLS since like, oh, Pep eight, you know, so it's, it's this tension that I'm, you know, I enjoy this challenge of trying to be like, I want to explain things. I don't want to have magic everywhere, but like, how deep do you want to go? Like sometimes just, like, just trust me on this, this is the best practice and like, you know, here's some links if you want to knock yourself out, but it is it is completely overwhelming because you're just taking it on faith. It's like, oh, I copied these tests and it seems to work and I I kind of understand why but like,
Calvin Hendryx-Parker 44:48
you should just put a little footnote go see Brian Dawkins book if you want to like dive Yeah,
Will Vincent 44:52
yeah, no, exactly. But you know, there is a tension there between the kind of person who wants to understand everything, but also Oh, it's just turtles all the way down. And so some, I see that these people get really hung up, right and that and sometimes that leads to like, I'm just never gonna grasp all this, it's like, you know, it is fractal like you do need to put limits on stuff and just be like, you know, have a list of like, I'm gonna go learn those things. But you know, at the same time, like if someone was, you know, someone could read the Python docs and like, read about class methods, but there's no way they're gonna remember that until they need to use it. So it is kind of like you kind of need to use it to learn it. And then there's, I have empathy for these things. And even for me, too, I'm kind of I'm like, oh, like, oh, yeah, I'm like, I know, we use that. Like, why do we use that like, Pep eight? I was, I was like, I was like, why the heck do we do this? Do it this way. It's like, oh, yeah, it's a pep somewhere, we have that
Calvin Hendryx-Parker 45:43
tension, even internally in our team is like, we're a team of senior developers who are constantly wanting to learn new things. But there's no point in going and learning some new technology piece of technology, if you're not going to go apply it right away. Yeah, you'll just have to give six months, when that project does come around where that technology is actually warranted, you're gonna have to go brush up on it again, anyway. And so a lot of our learning is really on the job hands on, when a project comes about, you kind of we track and I guess, kind of A skills matrix or inventory of what people obviously what they're good at, but what they want to learn, so that we can actually match them up with some projects where they would want to actually expand on a new skill set, that's really
Carlton Gibson 46:23
wise, because I've seen so many times a developer in a job who's a little bit bored, start going experimenting with some new tech, because they're a little bit bored. And the way around that, of course, is to preempt it and know that they want to use that and assign them to the task. So that's, I think that's, it's obviously a better one learning.
Calvin Hendryx-Parker 46:48
It's free tip for the day.
Will Vincent 46:52
Well, I think also, bugs like, this is maybe less as a consultant, but more when you're in internally working on something, you just have this big, long list of known bugs, and figuring out how do you how you deal with that, because, you know, you can't just fix bugs all day and have perfect code, because you're never going to ship new features. But on the other hand, if you never fix any bugs, developers are all going to eventually leave and get frustrated. So I've said this before, but I think one really nice way is to have like bug squashing days, you know, every month, every whatever, so that it puts the onus on the developers, so it's like, okay, there's 100 bugs, like you take ownership for deciding what are the 10 You're gonna handle? And it's a way to kind of off. You know, it's like an escape valve for like, yes, we are we are fixing these things, but not right now. Because we're doing something else. But it's not, you know, an indefinite, like code is all crap. I
Calvin Hendryx-Parker 47:43
think if you look on our site, we over the years, we've done an activity internally called FedEx day, it's now called ship a day. And actually, it's kind of more recently morphed into what we're calling Tech Tech debt relief week, where, like, what at least like the first week of January, everyone's kind of coming back from the New Year, and they've been on for like a week or two. And we'll be like, we're not gonna do any customer work. This week, we're just going to focus on tech debt relief, or a new process enhancement. And so it just kind of came about that that was a great way to give people that outlet to clean up the little messes that have been made. And sometimes we do it more than once a year. But usually, once a year, we spend a few days not unbelievable work, but actually fixing up and scratching those itches and come up with new innovations and ways we can improve our workflow.
Will Vincent 48:27
It feels so good as a developer. I mean, it's hard to describe to someone who doesn't do this kind of thing. But it's like a cleanliness thing. It's right. Like,
Calvin Hendryx-Parker 48:35
there's nothing worse. I mean, for me, picking up an old codebase. And we thought we were doing best practices at the time. And this was maybe a couple of years back and looking at and going oh my gosh, I got so much to clean up here first before I can even be productive. Like my, it's like having a clean desk before kind of getting started on some creative work. It's hard when you like just you just see little like issues here and there. And they're in there. It distracts you from solving the actual problem. Yeah, at least for me, I'd say most folks are like that.
Carlton Gibson 49:04
One. One analogy I've seen for this kind of environment, you know, this kind of discussion about tech debt versus shipping features is that, you know, okay, if you just should work on shipping features that in the short run, you'll ship more features, but sort of velocity falls over time. And, you know, in the medium to long term, you're actually going slower, because you didn't prioritize. Would you agree with?
Calvin Hendryx-Parker 49:24
I would agree with that. No,
Will Vincent 49:25
take the drag and the friction coefficient? Yeah. Yeah. Well, obviously,
Calvin Hendryx-Parker 49:29
in the beginning of a new product, there's a lot more new features to build to, because there's nothing if nothing exists. I mean, we're, we're experiencing that with the loudspring platform that we host Python web conference on is we actually pick it up in a couple times a year. If folks are not busy on another project, they will get assigned to do some cool new stuff on lads warm, which is actually really fun. That's been a great platform for us to experiment with new technologies like a lot of the WebSockets work we've been doing a lot of the Kubernetes advancements in our development develop ever experience have all come out directly out of us innovating on the platform platform.
Carlton Gibson 50:04
That's cool. I love lateral because you've digested the Django cons for, you know, the whole of the corporate period. And since as well, but I remember last time you came on you were talking about fargate, and containers on fargate. And now you're talking about Kubernetes, I see that
Calvin Hendryx-Parker 50:20
you can still use fargate. With Kubernetes. If you're using Eks, on Amazon, and you don't feel like you don't know what your capacity is going to be, or you want to scale closer to zero, it's possible actually to spin up compute in fargate. fargate, works on ECS and Eks, just as equally as well. So you can actually define your pods and your your resources to pull from fargate ad hoc serverless resources. Sorry, a little plug there for Amazon fargate. But I do find fargate to be a great option when you just aren't sure how much resources you need, or you don't want to be maintaining the ECU instances that would be hosting those resources. Yeah, no, perfect. Yeah. So many pieces, so many moving parts to
Carlton Gibson 50:59
our playground to work on it in is
Calvin Hendryx-Parker 51:02
helps a lot. It brings people up to speed on like CIC pipelines and TerraForm and configuring CloudFront and all the like caching pipeline. And, you know, how do you split off WebSockets into the separate like pods of like, resources that are servicing just those kinds of requests? Like there was a point came up last week or a couple weeks ago where people are asking, how did the front end get deployed, like the CI pipeline would run and it would deploy new fargate containers for the back end. And there would magically be a new s3 bucket synchronized with the latest front end changes. And people were like, We don't know where how those get there. So we had to go check it down. And it's actually kind of clever is that we actually had fargate tasks that when the fargate release would happen, obviously a new task definitions will be generated. fargate picks those up, and then replaces the old containers for Django, but the same time it runs the Django migrations, it does the collect static, and then it synchronizes as a task that's then runs and stops all the front end to the front end of the s3 bucket. So it means eating into a new release. You're sure the front end always matches the back end. Because they were tagged at the same time. Yeah, lovely.
Will Vincent 52:13
That's nice. Coming up on time, our previous guests was Maurice fleece. Yeah, we were talking about Django, 4.2 and 5.0. So my question to you is, are there new features you're looking forward to? And like, what's your current Django wishlist? If you just, you know, make it so what what could Django add that would improve things?
Calvin Hendryx-Parker 52:36
I think the the async story is, is ever improving. And I think that's really important to Django being a viable player. There still, I think a lot of people may see start to see Django is getting long in the tooth. And being a still a synchronous web framework. And obviously, it's hard to kind of bolt that on. And we've had, we've taken a very measured approach to getting async capabilities into Django. And I think that's, that's a high priority. I think the to make sure that Django and Python as a framework, Python as a language for people who are doing work in the web, it has to be async.
Carlton Gibson 53:11
So 4.2 brings in an async support for streaming response, which is, if you pass it an async iterator, and just running under ASCII, you can, you know, do long polling, or, you know, Server Sent Events, just recall Django. I think that's kind of quite exciting. Yeah, that's quite exciting. And then with the psycho PG three, I've talked in marriage about this today, I want who's I like, you've got to put this example together. For me, our show, we use psycho PG three is async client to listen to a notification that came either from a trigger or you know, save event or whatever, and then tell the listening client from a streaming response that it needs to fetch the latest state that kind of real time updates, all in native Jango. And then so that giving streaming responses, making eight string responses async compatible, that's kind of like the outer limit, I think in terms of features that will be in Django core, but now through 5.0, it's like, okay, can we flesh out the decorator support for async? Can we, you know, this get async signals? Can we, you know, flesh out some more stuff inside the ORM can we, you know, these these richness of the async support now, so over the next over the five point, next cycle, it should mature, you know, continue to mature and all those, all those gnarly bits will start to smooth out and give you that Django experience that you want, right.
Calvin Hendryx-Parker 54:33
For people to pick up and actually be productive. They need that Django batteries included. Pythonic way of of working.
Carlton Gibson 54:41
Yeah, I think I can't remember who we were talking to might be Michael Kennedy, who's saying that. You know, Python is a full stack language. And you know, it's important for it to have async because you don't need you don't want to have to just jump to rust or go or whatever, just because you need high throughput. It's the same with Django is that they'll always be split actually stating frameworks that are, you know, more advanced, but you don't want to change your web framework just because you need a streaming view or just because you know, you need that. So it's coming on nicely, I think,
Will Vincent 55:11
well, that's, that's some of your post fellow. Open Source work is around async, as well.
Carlton Gibson 55:18
So yeah, so I'm not leaving Django by any stretch of the imagination. It's given me a career, and I've given back to it for this period. But now I'm going to step back to the back benches, but to continue maintaining the channel's projects and have a bit more time for them, in actual fact, and I want to continue working on the async stuff in, in Django itself. And then, you know, there's things around the request object in terms of modernizing that and bringing in JSON request parsing that I want to add. And then the really sort of next one is to improve is the refresh Django serialization story. So this is something that I want to work on. And well, Andrew Godwin just released his little API framework that's very fast API inspired that was in his, what's it called? The Macedon client. It's called something the name escapes me. But he's released this hatchway project as a proof of concept there. And it's it's quite exciting because it takes pedantic schemers, and pulls them pulls the request straight into the requests the request handler and then it will serialize back out for using pedantic again. That's, that's where the future is gonna be. That's where it's like, okay, whether it's identical, whether it's at us or whether it's, you know, something else. That giving jangled, better story or any fresh story, there is something that I'm really excited about over the five point next cycle.
Will Vincent 56:48
Speaking of airflow, we should ask Andrew to come on. Yes, he works. He works on air flow.
Carlton Gibson 56:55
Yeah, we'll have to get back on you.
Calvin Hendryx-Parker 56:57
Should I agree
Will Vincent 56:58
by any is there anything? We didn't cover? Calvin? I know. No, I
Calvin Hendryx-Parker 57:02
think make sure you come to Python web conference, you guys. There's a discount code that you all can share in the show notes. For everybody's brilliant. And that gets you really excited. Come hang out with me for a week. It's a lot of fun. Yeah.
Will Vincent 57:21
Yeah.
Carlton Gibson 57:23
But you don't have to watch all the videos live, right? You can you can catch you can buffer them.
Calvin Hendryx-Parker 57:27
They're available immediately after the talks, which is a beautiful part of like, the loud swim platform is that you can watch any video that's happened already. Like within 10 minutes of the talk. You can also pause and go get a drink and come back and pause it or come in.
Will Vincent 57:41
Rewind to be like, yeah,
Calvin Hendryx-Parker 57:43
you can totally do that. That's, that's one of things I love. I didn't want to create this platform that just matched reality. I wanted to emphasize the features of being a fully virtual platform. And one of those is definitely like, I missed the first five minutes of talk. I'll just slide the slider back and watch the talk live from five minutes ago.
Carlton Gibson 58:00
Yeah, well,
Will Vincent 58:01
I just yesterday, actually, I was doing something trying to explain async to someone which is like rough because I don't fully understand async and I was looking at Carlton's talk again from Django con, which I've seen twice. And I was like, Oh, God, like, you know, so I was definitely rewinding and sliding. So it's, it's, it's very necessary to have that. Yeah, struggle is very real. Well, Calvin, thank you so much for coming on. We'll have links to everything. On webcom We'll have the discount codes. Really, you know, I like to say every you know, we we see you, you know, Django cones in between, but to catch up on what's happened last year is really interesting. Yeah, it's
Calvin Hendryx-Parker 58:39
always a great conversation. Thanks for having me.
Carlton Gibson 58:41
The thanks for coming on again coming.
Will Vincent 58:43
So Djangochat.com. We are on Fosstodon and we'll see everyone next time. Bye bye.
Carlton Gibson 58:48
Bye bye.