Transcript: Deploy on Day One - Calvin Hendryx-Parker

Whether it's scaling an application, deriving insights from data, or getting results from AI, Six Feet Up helps you move forward faster.

See what's possible at sixfeetup.com.

Hi, welcome to another episode of Django Chat.

I'm Will Vincent with Carlton Gibson.

Hey Carlton.

Hello, Will.

Hey Calvin.

Nice to be back here.

Welcome back on

the show.

You were making the pitch for this um Scaff Kubernetes approach that you have that Carlton is especially hesitant about.

So maybe give us the context and then we'll dive in.

Like both feet.

Let's do it.

Because I think this was, you know, at least a year, maybe two years ago since we came out.

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.

My goal has always been for 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.

I mean,

Yeah, it's hard to do.

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 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, like so we got mailhog on the back end for developers, but maybe when you're deploying, you're 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 kind of one-off you know toy that you've built 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 uh bit for us is how do we make you know day zero really a deployable event that I could you know build out a scalf 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 is 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 around that that choice.

Everything you said all makes total sense to me so far.

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.

Like Tilt, for example, has enabled a lot of that uh ease of use for me 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, like some event, big things went on.

But we we moved virtual, and that's when we built the loudswarm 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 SixV 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, you know, 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 how it operated, but I was locked into a platform and there were slight edge cases here and there.

Um, you know, there were there were you uh it's 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.

Yeah.

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 it and it fades away and becomes simple because of other tools we've wrapped around it.

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 to do the same thing locally that I would do in my production environment.

Right.

Am I right about that?

Because I recall, you know, Docker especially.

Docker like was like too, you know, 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.

Like there but there's two things I think 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 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 can 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, Docker-based uh Kubernetes distribution.

There is an even lighter weight version of this uh 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, but Talos is again a full Kubernetes distribution.

It's powerful, it's great, it and it gives you kind of peace of mind from a security standpoint.

The other way we typically deploy Kubernetes is using K3S.

So Kates is a very lightweight version of Kubernetes that can meant to run on the edge, single node, multi-node, um, 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 autosaves, 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 in develop mode locally.

That is what you're doing.

It is, and it runs very, very fast 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.

Or it could be running in EKS or in ECS on the cloud.

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 more complicated, obviously, to do such a thing, but it is possible.

So with all that said, if I'm a new employee or I'm working on a new project at six speed up.

By the way, we should mention you're hiring, right?

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 come play and have fun and uh do cool stuff with us, uh we're looking for people right now.

So go to sixchep.com slash careers.

That's the last plug I will give uh for the company that we identified.

I mean you you do you work remote?

No, no, no,

no, no, we'll come back to that.

We are fully remote.

We are fully remote first company.

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.

So wow.

That sounds well.

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?

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 and actually tilt our our Scaff 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 another thing we've started embracing has been uh Nix for some of the development environments.

So if you're not familiar with Nix, that's a whole nother level of stuff that um it's not a pinion I'm I'm fully sold on, but I see the promise of is that I can CD if I've got DirInf, if we've not played with DirInf, it's at the 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 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 data, you know, just bootstrapped into the local developer experience because we typically don't want to 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 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 PyCharm, we've got people who like VS Code, we had someone ask for cursor the other day.

I mean, it's whatever you want to use, whatever you're comfortable with.

Like the the power of senior developers.

You could use BB Edit.

Yeah, yeah.

Yeah, sorry, and that's relevant because um Carlton and some of the um steering council and board are 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.

And I there was one about BB Edit, but Carlton, based on historical, it has to go in the other category because it was less than 1%.

No, no, no, that's fine.

It's like which edit do you use?

And every single year I take other BB Edit.

BB edit.

Oh wow.

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 finally 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 because it 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.

It just goes from worse to bad to worse, right?

Like it's I would ignore it.

I mean, it's just those things are just such lifesavers as developers because I can 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 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 future the way it will be, uh, 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.

I mean, yeah, I mean maybe.

I certainly wouldn't say no, but

yeah, we call it.

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, really 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 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 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 an elegant solution.

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 d decisions.

You you recognize by by pattern when there's gonna be a a future problem coming to bite you later.

Uh 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.

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 enjoying the senior life.

I think.

I don't know.

It's it's kind of a wayward home for senior developers and open source people who love it solving hard problems.

There's your hiring out again.

It totally

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'd never thought I'd work with.

Uh, and I'm just so ecstatic that they're part of the team now.

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, momentarily.

I just want to cut back to Scaff because everything sounds wonderful.

And and I love the setup and I love that you've

It's really changed too.

I've got 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 Loudswarm and serverless, and and you know 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 before about it feels like you're using a jang uh a jumbo jet when you you just want the two-seater 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 yeah, it's like the sort of um 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 that the the the nice craftsman's hammer, right?

I also I think this is I thought I thought I knew this was coming.

I I knew exactly where where this 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.

Uh it's more explicit, and then that through that explicitness, it's just documentation you can run.

Is is I think if I I look at what you're just put you 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've 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 installed version of Postgres or SQLite or how I deploy those databases, how do I manage those versions of the data, how do I back up 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 point it at.

It's like this this one one universal.

Uh you you may think that basing my whole opinions around development, environment, developer experience on Kubernetes means that I'm a K Kubernetes KubectL expert.

I I am not.

Uh I don't I don't ever claim to be.

Although the LLMs are very good at telling me how to go tail my logs and check for the running nodes and these kinds of things.

That's it, but that's about the maximum I do.

Like I the the the other key bit of this is that, and I know it sounds like overkill, is having CI CD and using things like Argo CD 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, 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 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 dummy little pet project, I will go use the full-blown scalf uh template.

That that said, that there is a cost to the that thing.

To run a base scaff in Kubernetes and like Amazon may cost you over $100 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 playing with the Fast API cloud.

I got an early access 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.

Okay.

It's all free tier.

What's stopping you?

Maybe it's an application that won't scale or an AI initiative that just isn't delivering.

That's where Six Feed Up comes in.

With deep expertise in Python, Django, and AI, they solve hard software problems, modernize platforms, and get teams to market faster.

Their impact speaks for itself.

Automating healthcare pipelines for hospitals, helping NASA explore Pluto, building severe weather prediction tools, and applying AI to connect farmers with vital crop data.

When the stakes are high and the problems are hard, six feet up is the partner that delivers.

See what's possible at six feet up the partner that delivers.

And they're they're targeting that kind of um that meeting Heroku space, right?

That's a good thing.

Oh, which

Yeah, right.

Okay.

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 was 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, of course we say they're different tools, like Sebastian and the Fast API team are great.

Yeah.

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.

Um 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?

And 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 a it it totally is.

I I I I think that they're right um on that that that point.

That if I I mean I think HTMX plus Django is a really fast way 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, wow, is that a that's powerful.

It'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 it depends on your needs, like at that point.

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 I I I think a lot of folks don't go explore the docs enough.

Um that was that was really important.

I think that's the other thing is 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.

They missed the HTML helpers and and those those bits that you feel like I don't know.

I think a lot of people may just jump in two feet and not think about 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 that's an interesting part about like conferences too.

If 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 built-ins and the pieces that make Django really fun and easy and the breath of fresh air uh when talking.

Because 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 you're on the hook to build all the stuff.

All right.

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.

So you gotta find the David Lord to keep your

Pretty much.

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?

I I I kind of I'm a a bit of a person of two minds.

Like uh I I've always appreciated the Python staying out of my way and 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 in the and when when you say that to someone who says those opinions back to you, they they think again now and go to 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.

Um, but it's pretty nice.

Uh I I think for IDEs and for a lot of the tooling and for again a for the AIs and the LLMs who are doing a lot of coding, it's probably a net good um in in general.

Um it's nice because I don't have to type it all.

Like it like 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 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 to just rip off some Python and not worry about it.

But from a 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.

They're they're absolutely right.

It's more guardrails around the the code can go wrong.

It's it's you're you're definitely being proactive about your intent when writing the code.

Yeah, it's really up to you though.

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 that 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.

It's 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 uh because well, it's it's dynamic to the core, and we should be careful about trying to um enforce um unhelpful type pints onto on the sort of core highly dynamic bits of ty of Django.

And you know, so that's my kind of take is like yeah, absolutely type hints are great.

But what's your opinion?

Remember that Python has dynamic powers.

Well, just not if you don't even type it, it's just gonna do that for you.

Yeah.

Like it was it was less implicit than it should be.

Or explicit, it's less explicit.

I mean, I've uh that's not my one particular bug pair that

Not mine either, but it was convenient, obviously, as a new person learning a language.

I didn't forget about 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.

Yeah.

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.

That's how you earn your uh senior stripes, right?

True, true, true.

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 I I think those kind of patterns that we pick up from Rust 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 that we should just walk away from.

Right in my way.

Especially in a data-driven world when you want to be able to create like a data data classes, for example, like that.

Yeah.

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 where do you fall on the spectrum of AI, you know, tooling that helps developers.

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 uh it's it's hard to follow.

I think there's a lot of fear of missing out uh from folks, which maybe while they're calling you a dinosaur, I think that's okay to have a skeptic view.

It's probably bet healthy to have a 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 or loves the the act of creation and solving fun and hard problems.

So I don't care about some of the busy work on the side or creating a scaffolding or creating a 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.

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.

The both the these are the things I believe, 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.

I think there's a problem 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.

We're not at the point where they're fully autonomous automatons that can go off and do all the things.

We're still on 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.

And now we're all like yeah we're going to write specs.

I mean we we've been leveraging the Figma make platform which is an agentic version of Figma to build prototypes 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 using you know those are those are high I think actually for us tools like lovable, bolt dot new replit are going to be a boom for our business because these are high bandwidth tools for business users to convey to us what they meant like how they envisioned a piece of software to work and now they're like make it real 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 I don't 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 going to still use it we're going to 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 than it is for them to try and just have a Zoom call for an hour and understand what they want.

hase if you can put together a prototype at very low cost then you can do that during the conversation.

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 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 yeah I like that

It's basically a novel every other fortnightly but it's pretty 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 16th century whatever and they find ways to make it interesting.

So I feel I would feel better.

Oh my gosh where'd the time go?

Like it was really that it sucked me in.

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 well the the one big theme in there is that the the sl

owing 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 I think the number one for me like the I that I took away from that book was this it's a lot of times people talk about um 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 but 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 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.

It's by 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 and 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 oh des

ign is so hard it's really accessible 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's 95% of design right you know I

Like and then I got a degree I have a degree in technical graphics.

I really recommend it um you know it 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 it's it's sheer beauty as a physical artifact.

So I I do recommend getting it.

Nice.

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 because 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 mean

Or do they okay I didn't no no

it it says

in our little notes the aerial font it does look like

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

And one of the things I've done is I've made it multi tenant and I want to be able to deploy it to the world.

So this is the thing I was talking about where I was using Fast API and Cloudflare 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 bogus 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 both disposable or bogus email domains.

The second one is the project from Cloudflare itself called Turnstyle.

It is a free privacy-focused captcha replacement.

You don't have to be a Cloudflare customer or use the Cloudflare front ends 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 interest 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.

Uh it will detect based on browser behavior, your behavior.

Most folks won't see it uh when they go to your forums.

If you if your browser looks sus or you're a bot, you will get a cap shot in its place.

Okay.

Well, that's

Um I'm gonna recommend I saw a project came up um called Django Modern Rest, which is um from the um from some of the people that are involved in the Django Stubs project.

And it's another take on a rest solution for Django.

So, you know, we've got the rest framework, we've got Django Ninja, there's um I don't know, Farham put out one, Emma's put out one.

Here's another one.

But the the the take here is type and types and async support in is the headline that they've gone for there.

Um but I wanted to put that out as you know, but just in case you felt that we didn't have a rest story in Django, that uh there was something 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.

Oh yeah, Django Mantle.

You're too modest, Carlton.

But anyways.

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.

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 you know sharing real world insights mixed with exploring, which um it's a tricky balance to do, but I s I see you doing it.

I think that's what most folks need to do more of.

Yes.

We're on YouTube, links to everything in the show notes, and we'll see you next time.

Bye bye.

Bye bye.

From scaling applications to simplifying data complexity and unlocking AI outcomes, they help you move forward faster.

See what's possible at sixfeetup.com.