Deploy on Day One - Calvin Hendryx-Parker

Speaker 1: Hi, welcome to another episode of Django Chat. I'm Will Vincent with Carlton Gibson. Hey Carlton.

Speaker 2: Hello, Will.

Speaker 1: And we're very pleased to welcome back Calvin Hendricks Parker from Six Feet Up. Hey Calvin.

Speaker 3: Thanks. Thanks, Will. Nice to be back here.

Speaker 2: Welcome back on the show.

Speaker 1: So we were just discussing uh last time you were on, you were making the pitch for this um SCAF Kubernetes approach that you have that. Carlton is especially hesitant about. So maybe give us the context and then we'll dive in.

Speaker 2: I'm not hesitant.

Speaker 3: Like both feet. Here we go. Let's do that.

Speaker 1: So tell us tell give us a quick refresher of what it is and then we'll talk about uh how it's been going 'cause I think this was you know at least a year, maybe two years ago since you talked about it.

Speaker 3: I mean, this is this has been a journey since at least twenty eighteen for us, uh when we kind of started doing more Django based work is figuring out what the developer experience should be like for folks joining a team, getting on a project, uh starting from fresh. You know, what does a greenfield project look like for a Django developer? And there's been lots of attempts, I think, out there in the community and we've we've taken what we thought were some of the best pieces from here and there and combined them with our own opinionated framework for how we think Django development should be done. a developer to get a new, you know, MacBook or a framework laptop or whatever in the mail. And I'd love to see them commit changes within an hour of like turning it on.

Speaker 1: I mean this is a dream even anywhere, like every startup, every new company. Yeah. It's hard to do.

Speaker 3: But we I think we've done it. I I I I honestly believe that the the framework we put in place was Scaff. So Scaff is a scaffolding tool. It's been built on The shoulders of giants. Obviously we're using you know Django as one of the example apps in there, but we actually started um creating many different uh apps now that we've moved over to copier as a framework. So we're it used to be using um uh cookie cutter under the covers. And so it was a little more monolithic uh since we have moved over to copier in the last year and a half, and that that's allowed us to actually modularize and start building some other pieces alongside it that now give us the ability to do a AWS serverless uh scaff. implementation or a Wagtail Scaff or what we've been typically doing has been the Django full stack app, which is the one I talk about kind of the most.

Speaker 3: because it's got the most complicated sets of opinions built into it and it's kind of built towards developers who are working on maybe more sophisticated projects uh where you need You know, you've got a mail service. So we got mail hog on the back end for developers, but maybe when you're deploying using simple mail or SES on Amazon, or you want to use Mailgun or some other third party service where you've got an API and integrating uh mail into your app, or you've got you know, Redis Cash or Valky and now you've got Postgres on the back end. And so it's it's bigger than a a kind of one off, you know, toy that you've built. to to demonstrate something locally, but we want that same experience whether it's local, and you're in your sandbox environment or you're off into your production environment. That's been a key bit for us is how do we make you know, day zero

Speaker 3: really a deployable event that I could s you know s build out a scaff project greenfield and literally type Scaff deploy and have it build out that infrastructure into a target environment, whether it be Amazon or GCP or DigitalOcean, I don't care. And that that that I don't care piece for the where I put it. It's part of what drove some of the decisions behind choosing something like Kubernetes. And so I know I can see Carlton all already bristling a little bit a around that that choice.

Speaker 2: I'm nodding, I'm nodding. Everything you said all makes total sense to me so far.

Speaker 3: Because that that is levels of playing field. Some something to think about. Like I I've come from the same journey many of you have. Like I mean, I say many of you, I mean even the people who are in the audience. Like I was A person in back in the day who would build his own kernel because I needed to turn on some specific device driver. But today we don't think about the Linux kernel. I don't compile kernels anymore. Those just work for me out of the box. I or I use my Mac because it just works. Like the I don't care about the kernel my OS. Almost in the same breath, I don't care about the orchestration layer of my containers at this point because it blends into the background. There are really great developer tools right now that are enabling us to have that same experience, whether it's local. or in a cloud or in a machine sitting beside my desk,

Speaker 3: like Tilt, for example, has enabled a lot of that uh ease of use um for me in in the Kubernetes world. I I was resistant, very resistant to containers Up until about 2020. Uh and that's when well there was something that happened in 2020, some event, big things went on. But we we moved virtual and that's when we built the loud swarm platform to do Python Web Conference. as a personal passion project. And at that point I picked like how do I deploy as quickly as possible. It's my own thing. It's what Six V is building. We're not beholden to any other customers, you know, their processes, their policies, whatever it is. I said this we're gonna try containers. We're also gonna try things like serverless. So we deployed it initially on Fargate, uh using uh basically an AWS managed service for running containers. And it was wonderful because I didn't have to worry about how it scaled and and how it operated, but I was locked into a platform.

Speaker 3: And there were slight edge cases here and there. Um essentially, I always go back to Xenopython. And if you think about Xenopython, the simple is better than complex, but complex is always better than complicated. S these serverless platforms, these platform as a service pieces, they can get complicated. They seem simple on the outset, but you're learning some new CLI, you've got some set of constraints you don't know about because it's hidden behind some wall of abstraction. And even if you write plugins to like say, for example, Django Simple Deploy, you're now still dealing with different abstractions and different sharp edges along the way. I I find that complicated. Kubernetes, some people may call it complex, but it is the complexity you need now. And and it it it it and it fades away and becomes simple because of other tools we've wrapped around it.

Speaker 3: That that's kind of my my base thesis for this. And so I was very hesitant to go into containers. But I immediately saw the value of it. They they are the way to distribute applications in a repeatable way, and any place I want to put them, I can just throw a container. I mean in Amazon you've got 21 different ways to run a container And there's a reason why it's because it's a great way for developers and non-developers alike, data scientists, anybody who writes code, they know they can deploy code easily using a container. So then the next logical step is how to orchestrate those containers. And how do you do the the same thing locally that I would do in my production environment.

Speaker 1: Yeah. It does require I'll just say one thing and then you and Carlton can carry on the conversation, but it does require You need a good computer to run Kubernetes on top of everything else. Am I right about that? Because I recall, you know, Docker especially

Speaker 3: possibly.

Speaker 1: Docker like was like too you know, I I guess I'm really dating myself, but was out of reach for many regular laptops back in the day. Um so as much as I like got super excited about it, I realized for my you know, students, let's call them, a lot of them were like, I can't run I can't run Docker in a meaningful way. Uh

Speaker 3: if you've got four gig of RAM, uh you're having trouble in in any way. Like there but there's two things I think that that it in that that Kubernetes can unlock here on the local environment uh and it still requires Docker because you're still running containers in some way. So if you can run um w originally we we've developed Scaff with the kind Kubernetes distribution in mind. So for those of you who don't know, Kind is a way for Kubernetes developers to run a local Kubernetes in a Docker. con Docker containers using Docker's Docker Desktop or Orb Stack or whatever local container runner you want to use for developing on Kubernetes because it's basically a full Kubernetes distribution that runs as the nodes run as containers. And you can run a single node container very simply. And so that enables you to run a one-node, one container

Speaker 3: Docker -based uh Kubernetes distribution. There is an even lighter weight version of this. If you're familiar with the various distributions that are out there, when we deploy kind of full blown, we we use Talos Linux typically, which is like a full Linux distribution. that has no SSH into it, it has a control plane running and it has a Talos control plane running. You only interact with it over APIs. You cannot SSH into it. So again, limiting security vulnerability surface area. The TALUS is again a full Kubernetes distribution. It's powerful, it's great, and it gives you kind of peace of mind from a security standpoint. The other way we typically deploy Kubernetes is using K3S. So Kate's is a very lightweight version of Kubernetes that can meant to run on the edge, single node, multi-node,

Speaker 3: but it has made some concessions. uh around how it runs certain things. So for example, the control plane doesn't use etcd, it just uses a simple lightweight SQLite database under the covers. There is a K3D version, which is basically K3S on Docker. So run a single container with all these lightweight compromises, so you you obviously sacrifice high availability, but I'm on my local machine, I don't care What I care about is compatibility with the control plane, being able to run kubectl commands, being able to run tilt, and be able to run the same things I'm running locally that I would run in the cloud, but do it in a way that's not requiring so much system resources that is bogging down my system. I mean it can actually run live reload of Django inside Kubernetes containers. So as you type code and your IDE auto saves.

Speaker 3: you're automatically getting reloads, hot reloads in the Kubernetes cluster on your local machine. So it feels very local, feels very native to people who are like, I want to run just run server you know in develop mode locally, that that is what you're doing. It is and it runs very, very fast uh and with again less overhead. So that I think that approaches the resource constraint issue. The second thing I want to mention is that running something like Tilt and using Kubernetes means that parts of my infrastructure that I'm developing on could run on a sidecar machine. In another, if I had a desktop and a laptop, but my laptop was underpowered. I could develop locally on the laptop, run the Redis and the database and the other pieces on the other machine as part of one cluster. Uh or it could be running in EKS or in ECS on the cloud.

Speaker 3: It doesn't matter where these containers necessarily live. You can now extend your resources into places where resources can be paid for by the hour. That's com more complicated, obviously, to do such a thing, but it is possible.

Speaker 1: You're

Speaker 3: Yes, we are hiring. I'm looking for full stack devs, I'm looking for DevOps folks, I'm looking for people who are passionate about solving hard problems. Uh that is something that is like near and dear to our heart is actually going out there in the world and taking the vision of impactful dev impactful tech leaders and helping them solve these hard problems. And so if you want to to come play and have fun and uh do cool stuff with us, uh we're looking for people right now. So go to sixtep. com slash careers. That's the last plug I will give uh for the company that 's

Speaker 2: doing that again at the end. We'll do that again at the end. I mean you you do you work remote. No, no, no, no, no. We'll come back to that. We're doing the joke, we're doing the fact that Calvin's lying now.

Speaker 3: We are fully remote. We only have uh we don't have an office. We are fully remote first company.

Speaker 2: I've seen some amazing photos of the company get together, I don't know, where in the Caribbean, right, as well, no?

Speaker 3: Correct. We do a once-a-year uh company retreat. in Dominican Republic where we bring everybody together for a full week together. We don't do any customer work. We just work on building the better team.

Speaker 2: So okay, that sounds right. I might apply That sounds okay.

Speaker 1: Well, so my my question to you was, with all this complexity as a new hire, what is that experience of okay, so I'm sitting in Boston, get a laptop, what what is the experience for me, right? Because obviously all that work is to make it simple to do this same day deploy. What does that look like?

Speaker 3: So Scaff builds out a skeleton onto your file system as a greenfield part of the development process. You check that into GitHub or whatever your Git repository of choice may choice may be. As a new developer, I'm expected to get credentials for the O for our organization. So maybe I'm using Microsoft Entra or whatever it is, and I've got a GitHub Enterprise Organization. So I log into my GitHub, I clone the repo I should literally just be able to type tilt up as long as I've got a uh and actually tilt our our scaffold will check for dependencies. I mean really the bare minimum, you just need to have like kubectl installed. You just need to have tilt installed. And s another thing we've started embracing has been uh Nix for some of the d uh development environment. So if you're not familiar with Nix, that's a whole nother level of stuff that um it's not a

Speaker 3: pain I'm I'm fully sold on, but I see the promise of is that I can CD if I've got DureInf, if we've not played with DurInv, it's a lifesaver when especially when dealing with all these API keys and environment variables. I CD into my project directory, it will bootstrap the Nix environment and make sure that all my development uh tools are installed at the right versions expected for that project. The right version of black, the right version of rough, the right version of iSort, the right version of you name whatever tool. Poof, magic happens. I type tilt up, the cluster you know blossoms into life, and um I actually end up with a r running you know instance of whatever project I'm working on. I may have to go grab some data from someplace, but typically we try to have a scaffolding of of data, you know, just bootstrapped into the the local developer experience because we typic typically don't want to d

Speaker 3: develop with production data. We're typically developing with some kind of staging set of data that's already built into the project. Uh I go take a GitHub issue and I start working. Um because it's It's ready to go. I open up my favorite IDE. We don't we don't mandate any specific IDEs. We've got people who like PyTrun, we got people who like VS Code. We had someone ask for cursor the other day. I mean, it's whatever you want, whatever you're comfortable with. Like the the power of C

Speaker 1: developers. Carlton, shout out

Speaker 2: to CB edit.

Speaker 3: You could use PB Edit. I mean I was an old te old school Textmate user so at some point in time.

Speaker 1: Yeah, yeah. I like Textmate. Yeah, sorry, and that's relevant because um Carlton and some of the um steering council and board or just looking over the Django survey that's gonna come out uh at DjangoCon Europe and there's you know figuring out the questions around I there was one about BB edit, but Carlton, based on historical, it has to go in the other category 'cause it was less than one percent. But

Speaker 2: which editor do you use? And every single year I tick other BB Edit. BB edit,

Speaker 3: Now I mean I'm a longtime old school VI Vim uh user, but I I've I've shifted I I really do enjoy PyCharm. Um they they changed my mind a few couple a couple years back Probably when you saw me start doing some videos with Paul over there at uh JetBrains, but the uh the speed filing got to a point where I felt like it was reasonable. The VI emulation was very good, uh, so I felt productive. There was a there was a funny story 'cause there was a PyCon where I did a lightning talk. And at some point the the VI emulation mode got shifted off on my editor and I couldn't use my computer on stage. It just like my mind got broken and like I had to use a mouse and it just it got it got weird

Speaker 2: It just goes from worse to bad to worse, right?

Speaker 1: I mean I'll just say as one just as one thing, you know, being on the inside at PyCharm, it is it's non-trivial to do an IDE well.

Speaker 3: I would ignore

Speaker 1: there's way I sort of suspected, but there's so much more involved.

Speaker 3: But the idea's never been front and focused to like then the ID has never been the forefront of my ID my developer tool chain. It typically has been all the extras around the the the the the edges like the PyFlicks and the iSorts and the blacks and now rough. I mean It's just those things are just such lifesavers as developers because I can s kind of get to the root of the problem and not think about all the the outside edges and make sure that I'm still delivering well formatted good code. And you and I think that's even more important today with all the ID and a agentic AI tools as well, that I want them still to behave like like how I would lay down code. I don't think that'll always be the fut the way it will be, um, because I think at some point we will probably just not even look at the code. I think there's gonna that's gonna come a time. It's out there.

Speaker 1: I mean yeah, I mean maybe. I certainly wouldn't say no, but

Speaker 3: Yeah. Because we care about outcomes. We care about the the the what the the users, the end users, the the people who are wanting the value out of the software, we care what the outcomes are. They don't care what was written in the middle. We d as developers love our craft and I'm one of them. I absolutely love crafting fun, interesting code and and s solving a problem beautifully and elegantly has always been a priority or excitement in my life. That's shifting. Um and uh it hasn't gone away. Uh I still I'm I still enjoy I mean I'm using the tools I enjoy building, but it's been it's been a fun new experience and I still love guiding the tools into say the an elegant solution.

Speaker 2: Well that's the point, right? Is they can write okay code, like no absolutely no question they can write okay code. The the latest models and all the rest. And there has been a change in the last few months. They are much more capable. But you still have to watch them like a hawk if you want like good architectural decisions. Now When you say we won't look at the code at all, that I wince because I think but you know, I I will see them r make a change at an abstraction layer that's just totally inappropriate and you know that like six months down the road that Change if it's not dealt with here and then will be a

Speaker 3: that's why right now these these tools are so powerful in the hands of seniors because of exactly what you just said. you you recognize by by pattern when there's gonna be a a future problem coming to bite you later. Um but that's harder for people who haven't had that experience to to to grasp or to to code with. So there I think there's a lot of people out there creating tech debt today that can be of could be avoided if a good senior was in the loop. How do we train how do we instill like years of experience into a a new developer so that they can climb those ranks? I will I would love to be able to solve this problem. We don't have any juniors in our team. The the person with the least amount of experience is like 15 years in in our team. And so that makes a difference in kind of how we deliver and what we deliver. I I not I I still think it's a problem though that we don't have that there aren't juniors in the ranks.

Speaker 3: I don't know how we bring them through. Like I I'm I benefit from people going out and working in other places and experiencing all the pain along the way and then coming to work with Six Feet Up and and enjoying the senior life, I think. I don't know. It's it's it's kind of a wayward home for senior developers and open source people who love It's solving hard problems.

Speaker 2: There you are, there's your hiring out again.

Speaker 3: It it totally is, yeah. It totally is. Yeah. It it's true. I mean I've I've hired some of the most amazing people in the last few months that I never thought I'd work with. Uh and I'm just so ecstatic that they're part of the team now.

Speaker 2: I d so you given that you said that about um hiring seniors and that that you're all very skilled and um We'll come back to the AI question I think momentary, but I just want to cut back to Scaff because everything sounds wonderful and and th I love the setup and I love that you've got

Speaker 3: endorsement from Carlton for Scaff now.

Speaker 2: It's really changed the tune. Phil philosophically, it cuts like absolutely the opposite direction. I've gone. I've spent my entire career looking for a smaller hammer, a more precise and like delicate thing. And I love what you've done. And the example you gave was Loud Swarm and Serverless and and I know that when you're running all those different inst instances of um services and whatnot, absolutely the containerized Kubernetes approach, it all makes massive sense But when you're running your kind of small to medium sized Django app, it feels like you're deploying, I said to you when we talked b before about it feels like you're using a jang uh a jumbo jet when you you just want the two C to light aircraft, right? And you know all of the tooling that you've built and it's an amazing thing that you've got going there. And it it it it's like the sort of um

Speaker 2: full-on high-tech everything approach to the and it's it's a good solution. But the opposite end of the extreme is the is the the the the nice craftsman's hammer.

Speaker 3: I I I will agree with you the nice craftsman's hammer I also r I think this is I thought I thoug I knew this was coming. And I knew exactly where where this that that I would be confronted with this opinion uh on on the topic. And I I still believe that having that same set of tooling in that local environment as into a larger environment, it it it plays into the uh well I'll I'll go back to Xenopython again. the uh explicit is better than implicit. And and in many ways that the um I'll I'll I'll I'll put this out there. Kubernetes with tilt is more complex than a platform as a service. It's more explicit, and then through that explicitness is just documentation you can run.

Speaker 3: is is I think if I I look at what you're just put you've when you start pushing complexity around you've got environment variables. You've got them they run differently in your PaaS or on your fly. io or in your EC2 instance differently than you got them locally. You've got secrets management. You've got How do I set up the database locally versus how do I set up the database if I'm using RDS or if I'm using a an installed version of of Postgres or SQLite or how I deploy those databases? How do I manage those versions of the data? How do I backup the data? How do I handle all these surrounding bits uh of the application. And the the full stack app has opinions on all those things. And it runs the same locally as it does in that in whatever cloud you pointed at.

Speaker 2: Yeah, and there's there's something you said um Uh you didn't say it here, but you said it before, which is something along the lines of um KCTL is like the standard API. It's like this this one one universal.

Speaker 3: And and I rarely touch it, uh honestly. You you may think that b basing my whole opinions around development, environment, developer experience on Kubernetes means that I'm a k Kubernet kubectl expert. I I am not. Uh I don't I don't ever claim to be. Although the L LLMs are very good at telling me how to go tail my logs and check for the running nodes and and these kinds of things. But that's about the maximum I do. Uh the the the the other key bit of this Is that and I know it sounds like overkill is having CI C D and using things like Argo C D for deployment means that I've got a tool that's basically fact checking me along the way. If I make a change to a manifest, you know, Argo will reject it before it gets to deploy it out into any any space um before me. Any change I make. If it's on the right branch and it's in the right place and I've followed my my own process

Speaker 3: is ended up in the right environment. Like it's either in my testing or sandbox environment now or it's Once I've merged to main, that release goes to production because it's been approved and tested and I've got good tests and the CI running. It just helps me keep all the good practices always going in the right direction without any cognitive overhead and and load on my part as a developer to think about it because it just runs. Like these things just happen. If I go and you know Django admin, you know, create a new project. Now I've got a whole bunch of things I gotta think about, you know, to put in place all those practices. So even when I'm starting a a a a dummy little pet project, I will go use the full blown scaff uh template that that said that there is a cost to though that thing to run a a base scalf in Kubernetes and like Amazon

Speaker 3: may cost you uh over a hundred dollars a month uh for that level of infrastructure. That can be made cheaper. You can deploy it on a single node in Hetzner for a fraction of that cost. And I've been playing with those tools too. Actually I've been playing with Fast API. I've actually been sh playing with the Fast API cloud. I got a early access to to that and that's a lot of fun. But boy, howdy, if I want to move that someplace else, I mean I'm locked in on that environment for the moment. But boy was the experience. fun and and exciting as a solo developer. I put the front end on Cloudflare pages and workers with the API gateway on Cloudflare. I put the fast API with just running LilyFast API deploy and poof magic happened there and I I threw up a database in uh Neon, which is Databricks' hosted Postgres as a service. It's all free tier.

Speaker 2: Right. And they're they're targeting that kind of um that meeting Heroku space, right? That 's what we're doing. Uh right now. Yeah, right. Okay.

Speaker 1: Yeah. Well I I gotta I gotta ask you, Calvin. So I f so Carlton and I were just at this Pi TV event in Amsterdam, um, and Sarah Boyce, Django fellow, gave a talk on Django has a marketing problem. And it's a great talk. We'll have links to it. Um, but I wonder, as the Django community with Fast API, I don't feel like we have a great story for You know, w of course we say they're different tools like Sebastian and the Fast API team are great.

Speaker 3: Yeah.

Speaker 1: But I don't think we've nailed the marketing pitch for why Django. And I'm about to go to PyCon US and I'm gonna get this question a hundred times a day. Certainly. What would what would you say to someone who comes to you, you know, a client or someone else who says, you know, how would you make that decision tree between one versus the other?

Speaker 3: It's it's hard to argue with the batteries included aspects of Chango. I I feel like we've maybe, I don't know if it's law the project's not I don't think the project's lost its way on that. I don't think we talk about it enough that If I just spin up it it totally is. I I I I think that they're right um on that that that point. I mean I think HTMX plus Django is a really fast way to to solve some problems without building your API twice. If you're in the fast API land and you're building a React app, well you've now had you've now had to build your API twice. basically and now you're maintaining that thing in both places and you have to always have tests to ensure that they stay in in in parallel with one another. Where if I can just build the back end and I can enable uh the single page web app experience on the front end with low overhead.

Speaker 3: Wow, is that a that's powerful. That's a powerful way to get an idea across to your client, your customer, to internal stakeholders without, you know, spending a lot of time and effort. Now you can take that to the next level. Maybe you do want to build uh React apps or have but depends on your needs. Like at that point,

Speaker 1: yeah.

Speaker 3: You're gonna you're gonna recognize that There's a absolute usability need or user experience need for those level of tools, but it may be that HTMX is really all you need on top of Django because it's got all the templates built in. It's got all the templating engine, the ORM. It's got all the uh helpers, uh, which really uh I I think a lot of folks don't go explore the docs enough. Um That was really good.

Speaker 1: Doing new things, right? I think that's the other thing. They they don't realize that everything they're trying to do has been done and probably perfected and thought about and They just don't know where to look.

Speaker 3: Well they've missed all the they've missed that in the docs. They missed the HTML helpers and and those those bits that you feel like I don't know. uh reaching for the manual when the manual may say there's already solutions for all this built into Django. You don't need to reinvent wheels. Um I see we've seen that a lot over the years. with multiple frameworks, but Django seems to particularly have good docs and good good helpers built in. Uh more folks probably just need to get exposed to them. I mean I think that i th that's an interesting part about like conferences too. As you go to conferences and I think people like people pitching talks to conferences are always looking to pitch the latest, newest, fanciest, like cool way to solve a problem. we probably still need some base level talks about the framework and the the built-ins and the pieces that make Django really

Speaker 3: fun and easy and a breath of fresh air. uh when talking 'cause I a lot of people got attracted to Flask and now obviously they're getting attracted to like fast API because it it sounds fun and neat and it's it's fairly lightweight. It's lightweight and fast to get started, but then you're b you're on the hook to build all the stuff. No

Speaker 1: disagreements

Speaker 3: I think they do And

Speaker 1: well, yeah, and it's just but I think we could learn a lot from again the fast API team, you know, in terms of they're doing a great job on marketing. Um

Speaker 3: I think a great whether whether they liked it or not, Flask did a good job as a as a April Fool's joke on marketing too.

Speaker 1: Yeah, well, and and David Lord

Speaker 2: has been

Speaker 1: doing a heroic job for oh my god, I don't know, ten plus years. Uh on everything, so you gotta find the David Lord to keep your

Speaker 3: the longest running April Fool's joke in in history of April Fool's jokes.

Speaker 1: Pretty much. Um all right, one more, and I promise I'll shut up, Carlton. Um I wanted to ask you, Calvin, about typing, because this is I don't know if it's hot, but it's it's on everyone's mind and I You know, PyCharm is there's all these new type checkers. We're integrating, you know, all of them. We're trying to decide if we have an opinion. Um And then I'll just say that leads into Carlton gave a talk that you'll see versions of on Django Mantle that has a take on typing. So where do you fall? I fall on I see people trying to turn Python into Java and arguing that LLMs want static. types. Um but what do you see?

Speaker 3: Boy. That that's a hard one. I I I kind of I'm a a bit of a person with two minds. Like uh I I've always appreciated the Python staying out of my way. It's just letting me code through a problem. But I understand the structural beauty then of of types. One thing that I I gets me when I talk to folks is they'll say that Python doesn't have strong types. I'm like, you're you're absolutely wrong. Python is very strongly typed. It's just never had static typing. associated to it. And it and then when when you say that to someone who says those opinions back to you, they they think again now and go look at the language differently. And so I think the fact that we've added in static typing and type hints into the language has been a boost. I think it's a good thing. I think it's brought over a whole new set of people who were skeptical before and I I like the fact that I'm not forced to use it if I don't want to.

Speaker 3: Um but it's pretty nice. Uh I I think for IDEs and for a lot of the tooling. And for again eight for the AIs and the LLMs who are doing a lot of coding, it's probably a net good um in in general. Um But it's nice because I don't have to type it all. Like it li I I don't have to literally type it like with a keyboard. Um but the typing can get added for me and then I can have static type checks and I can have uh the the in you know I my uh my test environment and my integration integration environment all can validate that what was said is true. So I From a convenience standpoint, I'm still like I love the village is just rip off some Python and not worry about it. But from uh building important big important software Standpoint, I think it's a big boost because there's a lot of people who feel like they need that level of safety, which they're probably right.

Speaker 3: They're they're absolutely right. If I'm building software in a a life or death healthcare space or dealing with people's finances and money or those kinds of things, you need that level of of extra belt and suspenders.

Speaker 2: Guardrails, isn't it? It's more guardrails around the

Speaker 3: Well it's pro it's proactive, yeah. It's it's you you're you're definitely being proactive about your intent when writing the code. And I'll

Speaker 1: actually up to you though.

Speaker 2: Well yeah, well my my take on this is not is that is the types are wonderful and we should use them where they add value. But what I what my only sort of pushback there is I don't I don't want us to let go of the dynamic patterns. where they where they are useful. And I think if we do that, we're leaving power on the table that Python needs because if we just if we just try and treat it as a static language, well it's not a very good Rust. is it's slower and it's the type system's not as good and there's no compiler enforcing it and well okay it is a dynamic language we shouldn't abandon that is my take and then Because I'm obviously in the Django community, I link that back to Django. Django was written with dynamic patterns in mind. And so when you come down to the core of it, it's very hard to type in because well it's it's dynamic to the core.

Speaker 2: And We should be careful about trying to um enforce um unhelpful type pints onto on the sort of core highly dynamic bits of t of Django. And s you know, so that's my kind of take is like absolutely type integrate. But remember that Python has dynamic powers. Let's not just

Speaker 3: what's what's your opinion on the on the implicit return?

Speaker 2: On what, sorry?

Speaker 3: Like implicit returns in functions, like in methods.

Speaker 2: What like returning none from a

Speaker 3: Yeah, right, yeah. Well just not if you don't even type it, it's just gonna do that for you. I I feel like that was a mistake, like was it was less implicit than it should be.

Speaker 2: Or

Speaker 3: explicit, it's less explicit.

Speaker 2: Yeah. I mean I f

Speaker 3: Not mine either. But yeah, it w it was convenient obviously as a new person learning a language. I didn't t forget about r you know typing return at the end of a thing if it wasn't returning anything. But then you get the side effect of it returned None.

Speaker 2: Yeah. And then you get some error, none type is not callable later on, and you're like, why have I got a none type here? It's like because I didn't return anything from the Yeah, yeah, yeah. Yeah, no

Speaker 1: It's a rite of passage. That's how you earn your uh senior stripes, right?

Speaker 3: True. True, true, true.

Speaker 2: Sure, sure, sure. So yeah, that that's the kind of thing that a type checker might uh might pick up. And I the other thing I like is of forcing you into a um into a match statement to handle optionals so you've explicitly handled the none case. And I l I I think those kind of patterns that we pick up from Russia or and and try and bring across are lovely and they do add value. But, you know, um dynamically creating a class at runtime and, you know, using it to do superpowers in in a very few in a very concise way is not something we should just walk away from. It might be

Speaker 3: but I think it's super powerful, especially in a data driven world. When you want to be able to create like a data data classes, for example, like that.

Speaker 1: Yeah.

Speaker 2: Yeah.

Speaker 1: Well that leads in in my head anyways to the next one, which okay, AI, I'm gonna ask you about it. So you've you've published on the company blog a guide to AI coding assistance. I can see that you're seem to be getting a lot out of them and you've sort of touched on this Like what are you finding are you know, ways that are working and some things that are still not there yet? I'll I'll just say for me, the agentic stuff I'm not quite there yet. I just the security and the hands-offness. I I I'm not quite there yet and I'm friends call me a dinosaur for that. And I may be, but I'm still walking the earth, so uh where do you fall on the spectrum of AI, you know, tooling that helps

Speaker 3: I mean I think if you've been following along, I I I have been playing with them all. Like I've put out posts about, you know, comparing five or six of them at once and And and the the the ground moves very, very quickly underneath you. It's like quicksand and it's it it's it's hard to follow. I think there's a lot of the fear of missing out, uh, from folks, which maybe why they're calling you a dinosaur, I think that it's okay to have a skeptic view, it's probably be healthy to have a scept skeptical view of them because they are capable of doing things um that you may have side effects later. So I our team is very, very adept and very much using all the agentic AI tooling, but we're using it again more like a senior developer would is to augment the powers of the existing human in the loop who understands how to solve

Speaker 3: or loves the the act of creation and solving fun and hard problems. So I I don't care about some of the the busywork on the side or creating a scaffolding or creating a f uh you know a framework for a little piece of this or that. those those are the less interesting part of the problems. And so we can we can assign those easily to the agentic AIs to take care of that piece or to to build you know most of what we're doing. We're becoming very good at uh specifying and planning and using tools like Spec Kit, which can integrate into all most all the agentic AI uh tools that are out there. That's the one I'm talking about kind of most recently uh on the LinkedIn post.

Speaker 2: Um spec driven development. It's good.

Speaker 3: Yeah. Yeah. So spec driven development, a spec kit is from GitHub. It's open source. And it provides the ability for you to create in addition to so most folks are probably familiar with. agents. md or the claw. md file that you put at the root of your project, it kind of expresses your opinions about things. Agents or the spec kit takes us a step further with allowing you to the beginning of the project or as as a developer to establish your constitution. These are the things that are should be true for this project. And so it's a more extensive version of that agents. md. And it's meant meant to probably work alongside the agents. md. And then you start in on the the specification part of the process and it actively asks you questions. It helps you resolve um ambiguity and unknowns. It helps you write the user stories and helps you get to a better set of outcomes, not just output, from these AI tools.

Speaker 3: I think there's a problem in where a lot of developers are focused on the outcome uh output, not the outcome. Like we're with their AIs and LLMs are incredible output machines. They can output tokens till the you know the cows come home, but to get good outcome requires a great developer in the mix still. Uh we're not at the point where they're fully autonomous at automatons that can go off and do all the things. We're we're still un the humans are still understanding what the requirements are. We're still trying to document those requirements. It's actually making us better developers because we are Becoming better at specifying how we want something to be done or to actually operate once it's been delivered on the other side of that software equation.

Speaker 2: It's amazing. We spent like thirty years saying, No, we're not gonna write specs and now we're all like, Yeah, we're gonna write specs

Speaker 3: specs, all the specs all the time. And you get great docs and you get great tests and you get and you get great use cases and you There's some great flows out there too. I I mean we we've been leveraging the Figma Make platform, which is an agentic version of Figma. to build prototypes um relatively quickly for even prospects, people who we aren't who haven't even signed a contract with us yet, we can basically help convey understanding at that level with them and then we take it in into building the real the real tool. Those are those are high I think actually for us tools like lovable dot new replit are going to be a boom for our business because these are high bandwidth tools for b business users to convey to us

Speaker 3: what they meant, like how they envisioned a piece of software to work, and now they're like make it real. Uh I think a lot of people recognize relatively quickly those tools have been uh given system prompts to make you very successful early on in building something, but uh don't ha they they lack, I believe, in the success on deployment, in the the the what's next, the day two operations. pieces of that. So a lot of people will build early in those tools and then come back into the I don't want to say come back into the real world. They're gonna still use it. We're gonna still use agentic tooling. but in a different way to build the real version of those things. But now we've got a high bandwidth high highly communicated to us what the needs were, what the requirements were, what the the outcomes should be for this software. Like it's much easier to understand that through those pictures and through actual working UIs

Speaker 3: than it is for them to try and just have a zoom call for an hour and understand what they want.

Speaker 2: You talk about that pre and that point before signing a contract because it was it's there's always this kind of um like almost Mexican standoff.

Speaker 3: Is it allowed? Is that allowed?

Speaker 2: I don't know. I don't know if it is if it's not employed, but just a standoff. Um like But there's always this standoff between the client who doesn't want to pay until they're sure you're gonna deliver the right thing and then from your side or my you know my side, I don't want to do too much work without getting some guarantee of some payment, that discovery phase. If you can put together a prototype at very low cost, then you can do that during the conversation. That's the same thing.

Speaker 3: And now because of these tools that are available.

Speaker 2: You still have the problem though that the client's like, let's just ship the prototype. You know.

Speaker 3: uh and telling people what's real and what's hype. Uh and that's also been a problem I think you're seeing. I think there's a lot of people with FOMO and that FOMO is around what I'm calling just keynote where people are showing off something on a stage uh that is Half baked, they figured out the happy path, they figured out a great demo that showcased it really well on stage, and boy is that not really reality. And it's it does it's doing a disservice. Like people should show the realistic version of these these tools because they're still incredible. I I think they're really equally as incredible as a developer who's been around for a long time. I want to see the reality of it. Like how does this actually get me in a day-to-day usage Productivity value, you know the outcomes.

Speaker 1: Yeah, I like that. If I may, I might switch to books and projects time.

Speaker 3: Okay. Fun.

Speaker 1: So I think we gave you a heads up. I'll I'll go first just to break the ice. Uh and I'm actually not doing a book. And Carlton, I forget if you've done this, but I'm gonna say I

Speaker 2: I did Le Monde Diplomatique, so you could have a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of Okay, okay, right.

Speaker 1: I'll take I'll take London review of books, which I owe to Carlton Introducing introducing me to it. It's basically a novel every other uh fortnightly. Uh for me in a world of uh, you know How to how to say? It's nice to see educated, opinionated takes on things that are relevant and some things that are completely non-relevant, but you know, tapestry and sixteenth century whatever and they find ways to make it interesting. So I feel like

Speaker 3: you shared that and I immediately went and read Like three three little like novels and I was like, this is incredible. Oh my gosh, where'd the time go? Like it was really that it sucked me in.

Speaker 1: Yeah. Oh good. Yeah. Um there it was, that's my that's my shout out. Either one of you who wants to go.

Speaker 2: Calvin, you go.

Speaker 3: Okay. Mine is also a non-technical related thing, but I think very prescient in this time of what feels like a very fast-paced moving world. Uh one of the so each year uh the the team gets a book from Gabrielle, who's our CEO. Um and my co-founder at the team. And so uh two years ago, I think it was, we gave everyone the book Big Panda and Tiny Dragon. Um and it's a really, really fun animated story of a journey of two friends. who go places, see things, uh, but it's really w the the one big theme in there is that the the slowing down in in a world of uh that pushes constant busyness. is something that you you we need to take a moment and see. And it was

Speaker 3: all I think the number one for me, like the I that I took away from that book was it's it's A lot of times people talk about um uh it's not about the destination, it's about the journey. And then this book takes that a step further. It's not about the journey, it's actually who you go on the journey with. Who are your friends in life? And I found that one to be like about ready to tear up thinking about it because it's really important to me who I go on journeys with. Don't focus on the destination. Don't focus so much on the journey. It's focus on your friends. That that one's really I love that. That makes me feel good. There's a couple books in the series, but definitely get the first one, you won't regret it, and you will be a better person for it.

Speaker 2: I I'll put it up there in our top book recommendations for the for the series. Um I'm gonna um just show you um this book here called Universal Principles of Typography. You probably can't see the principles bit because it's like got a silver background there. It's by Elliot Elliot J. Stocks, who is a font designer. He's worked for Google, he's worked for Adobe, he's worked for all everyone. And it's a hundred key concepts for choosing and using type. And I've it's a couple of years old now and I've had it on the shelf and I've I I remember talking about it when I first got it. But I pulled it off the shelf the other day to look at again. I was just like gobsmacked by how just gorgeous absolutely every page is just beautiful to look at. It's it's a it's an utter delight of a book. And You know, for us developers who, you know, all design is so hard, it's really accessible.

Speaker 2: It makes the principles really clear and Yeah, it's just a wonderful book. So Universal Principles of Typography by Elliot J. Stocks. And um, you know, typography is 95% of design.

Speaker 3: I don't know if you know this, but I I got my start in technology in journalism doing desktop publishing and typography. Like and then I got a degree. I have a degree in technical graphics.

Speaker 2: Oh so you're one of those ones, are you? Okay, all right.

Speaker 3: Yeah, so that that that's a cool book.

Speaker 2: No, it is a cool book. I really recommend it. Um, you know, uh as I pulled it off the shelf and was looking through to find my specific thing that I wanted to look up, I was again just taken by its its sheer beauty as a physical artifact. So I do recommend getting it.

Speaker 3: Nice.

Speaker 1: All right. Um projects, I'll just go quickly. Um I'm gonna shout out to Django Mail Auth from Coding Joe, which is Django Auth via login URLs, no passwords. It's kind of a lightweight package. Um a newer one. Um I've been playing around with that and I think it's pretty interesting 'cause auth is way more complex than people think and sometimes you need a full featured thing but sometimes you need less and certainly passwords no one can remember them so it's a pretty interesting one I'm

Speaker 3: and if you have poor typography that actually looks like Django Mall auth

Speaker 1: Yeah.

Speaker 3: No, no, it it says Molloth.

Speaker 1: Yeah, in our little notes, the aerial font. It does look like Molloth.

Speaker 3: It looked like Moloth, but

Speaker 2: We need to get we need to get Joe on the show. Sorry Calvin before you go. We need to get Joe on the show because he's we but we've recommended his projects, you know, a number of episodes running. I think um we'll need to hit him up and I

Speaker 3: I put a couple projects in here that I I'm interested in right now because I'm building a little side app for the family. And one of the things I've done is I've made it multi-tenant and I wanted to build deploy it to the world. So this is the thing I was talking about where I was using Fast API and Cloudflare. uh for the front end. But being able to keep random bots from creating a bazillion accounts in your app is pretty important. And so there's a project out there called Disposable Email Domains. And you can use it across multiple languages, not just for Python, but it has basically a blacklist or block list of bogust email domains that bots typically sign up with. So you can actually reduce a tremendous amount of your account creation spam by putting that into your middleware or your pipeline to basically reject uh boat disposable or bogus email domains. The second one is the project from Cloudflare

Speaker 3: itself called Turnstyle. It is a free privacy focused capture replacement. you don't have to be a Cloudflare customer or use the Cloudflare front ends to to put that in place. But uh I really appreciate Cloudflare 's dedication to security, privacy, zero trust technologies. I feel like they got my best interests at heart. uh given the type of tools that they are putting out there into the community. So check out turnstyle. It's a drop-in. It will detect based on browser behavior, your behavior. Most folks won't see it. uh when they go to your forms. If you if your browser looks sus or you're a bot, you will get a captcha in its place.

Speaker 2: Um I'm gonna recomm I saw a project came up um it's called Django Modern Rest. Which is um from the um f some of the people that are involved in the Django Stubbs Project. And it's another take on a rest solution for Django. So no. F Rest framework, we've got Django Ninjas , um the I don't know. Farhan put out one, Emma's put out one. Here's another one. But the the take here is type in types and async support in is the headline that they've gone for there. But I wanted to put that out as, you know Just in case you felt that we didn't have a rest story in Django, that uh there's there's yet another one for us. It's a it's um It's a fertile time, I think. People are picking up the mantle of um, you know, okay, let's solve this. Let's let's push forward.

Speaker 1: Oh yeah, Django

Speaker 2: Mantle was a good thing.

Speaker 1: You're too modest, Carlton. Anyways.

Speaker 2: But yeah, so that there's another one to check out. It's as I say, it's by the people from the um Django Stubbs project and they they put a lot of work in there and they're they're talented people. So you know it's worth having a look. Django modern rest.

Speaker 1: As we depart, Calvin, is there anything we didn't ask you or you wanted to mention?

Speaker 3: No, this has been a great conversation. I really appreciate what you all are doing in the community. I want to uh send my greatest gratitude uh for the both of you. Thank you so much. And uh thank you for coming

Speaker 2: back on. Oh

Speaker 3: my.

Speaker 1: Yeah, thank you for, you know, sharing real world insights mixed with exploring, which um it's a tricky balance to do, but So I see you doing it. So

Speaker 3: it's it's so fun to be curious. I think that's what most folks need to do more of.

Speaker 1: Yes.

Speaker 2: Yeah, no, that's a that's a good moral to take out of.

Speaker 1: All right. With that, we are at DjangoChat. com. We're on YouTube. Links to everything in the show notes, and we'll see you next time. Bye bye.