Transcript: Being a Productive Developer - Nick Janetakis

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

And we're very pleased to have Nick Jantakis join us again to speak about web development, Django, and other things.

Welcome, Nick.

Yeah, thanks for coming back.

So let's see, what's what last time we talked a bit about Docker and Flask, and and you're a really interesting guest because you know Django, but you also work day-to-day now with PHP.

You have a lot of experience with Flask.

And so I think maybe we'll talk about more generally web deployment and not just narrowly Django as we usually do on this show.

Um but maybe what's what's changed for you in the last two years since we last spoke?

I believe you have a full-time job now.

But yeah, I still do the courses and YouTube videos and blog post stuff on the side.

How do you have time to do a full-time job

and courses in YouTube?

And there's a reason why new courses haven't been posted in a while.

Because yeah, I mean, when you're working a full-time job, it's like 40 hours, give or take a week.

Like, yeah, and you gotta be protective of yourself, just your own time, right?

You don't want to want to be grinding full-time job, and then it's like 10 minutes to eat dinner, and then it's like four hours of doing courses after.

Like, you're gonna get burned out doing that all the time.

Yeah, no, in time.

And honestly, like it depends on how long the video is, but it's not too bad of a time investment.

Let's say maybe two hours all in to make like, I don't know, a 15 or 20 minute video.

Okay, that's fantastic.

Because I, you know, I've got screen flow going, and I think, yeah, okay, that's about right.

But there's lots of depth in it, and I'm thinking, uh we're scared to commit to the technology.

What do you recommend?

Uh right now, because I am using Windows, I do use a tool called Camtasia.

Okay.

And I think there is a port for that to work on macOS as well.

Um yeah, it's pretty no, I don't want to say bare bones, like it has good features, but yeah, I don't know, it's it's whatever you get used to.

Like I've made like 600 videos now, so it's like I'm familiar with all the widgets.

I remember when you were still doing the podcast, I was like, you know, slow down a little there.

You're making me feel bad because you were just, you know, week after week for and how many was it that you did?

Was it it wasn't quite a hundred, I don't think, right?

It was like sixty or seventy.

Oh, I I had you had quite

I had to hit the hundred mark.

I don't it it's definitely a hundred policy.

Maybe um just to go back, like what was so this is the running in production podcast, which is fantastic.

Lots of things on um Django, but other areas.

What was, you know, with some time away, how do you look back on, you know, what the good, the bad, like how do you feel about it now?

I mean, you're still doing YouTube videos, so you're not completely burned out from teaching, but you know, how do you yeah, how do you view the podcast experience in hindsight?

So I don't regret any of it.

I don't know, it was awesome because I kind of kind of got a chance to speak to like a hundred different people uh from all different walks of life, right?

Someone who just graduated high school, like their first app ever, to like, you know, billion dollar company type of thing.

So it was cool, yeah, just to talk to different people.

So I don't like regret the time spent.

Uh but yeah, there were certain areas that were just like major burnout inducing uh things, as as you may know from doing your own podcast.

I mean, just to have someone else to the ups, the downs, someone to say, hey, let's, you know, let's do more, let's do less.

I think it's it's anything solo is really hard, especially a podcast given it's so much kind of hidden work, right?

I mean, for an hour-long conversation, I think you even said at one point you estimated like six or seven hours total.

Or what was your calculus for how many, you know, for a given episode, how much actual time did it take to put it out?

And that's everything from like finding the guest and you know, coordinating some schedule and then recording the show for an hour, hour and a half, and then doing the editing part, the show notes, putting it all together and then shipping it out.

It's like the conversation is the fun part, but it is it's is it quite it's probably a little less for me just because I have Carlton's that helps, you know, with chatting and stuff, but it's still it's still probably a good five hours per episode total.

And like, you know, out of 40 hours in a week, you know, ostensibly that's it's a chunk.

I mean, it's basically a day.

Like basic, you know, we're recording on a Tuesday.

I basically take today to just do all the stuff and try to set up guests and so you know it's 20% of my time when we do it, but we don't do it all the time.

Um yeah.

Well, do either Carlton, you have do you have questions?

I mean, what were what were some of the I don't know highlights that from the guests?

Because I agree, like it's for us having the podcast is it's amazing.

We get like we're speaking to amazing guests in all realms of you know, walks of the tech world, and it kind of keeps my excitement up instead of just you know the computer and reading blog posts.

It's like, oh, there's people and like they have passions and interests and they introduce me to things.

It kind of keeps it fresh for me, at least.

Did you find that to be the case for you, uh Nick?

Yeah, I learned all that.

What about you, Carlton?

You're you're tired of talking to guests?

No, no, no.

I I I like having

Like um, you know, the the bit you said, Nick, about um getting to reach people from the different different walks of life, you know, seeing different people in the different areas of the Django community, you know, people who are using it in their work, people are working on the framework themselves, you know, everybody in between.

I think that keeps it fresh and worth doing for us.

But yeah, I couldn't.

It's the summer holiday for us.

It's the big the break at Christmas, it's the only doing it once every fortnight.

That makes it sustainable, I think.

That's something I didn't do, but I've noticed other podcasts, um not companies, but like every guy, like you do have like quote unquote seasons, right?

There's a there's like a period where you take X amount off.

I mean, I think it's a little bit of marketing, but that's not the primary goal.

So I think if anything, we've leaded leaned into that the last couple years, Carlton, right?

I mean, we want to take time off, take time off.

Like it just helps the burden, right?

Because there is this burden when you're putting out content regularly and you feel like you need to, and I think that's sort of like the burnout cycle.

Same thing with work, right?

And when there's something which like takes up, oh, that that's 10, 20% of the time gone.

Ah.

And then you know, there's these other two or three things on the list, and all of a sudden it's like, oh, I'm actually under pressure.

Whereas if you can just sort of pause one of those things, all of a sudden there's so much more space in your life, and it's like, ah, I can breathe, I can do, I can, you know, I've got time.

So being able to drop the podcast for the summer, that's just like, okay, yeah, and we'll we'll join you again in the autumn.

Um, so yeah, I guess you went and got a job, so there wasn't really like a lot of downtime, but um I don't know.

There was there was probably some there's some settling when you take something that you've been doing all the time, at least for like for me, just on the Django board, which is a smaller time commitment.

I think it took a good two, three months to wrap things up that I needed to do, but also just to be like, I don't have to check that email every day.

Like, like the brain kind of settles into oh that's not there.

It's not just an immediate thing, like a vacation or something.

Did was that the case for you at all, Nick?

And like suddenly the more free time I have, the more unproductive I am.

Like, have either of you guys noticed it as well?

Because actually, yeah.

I feel like there's a built-up kind of stress pressure, and most of the we feel like productive is when we're like grinding through podcasts or doing things we know how to do that take time and energy, but really it's when you have a moment to be bored or a moment to reflect or a moment to sit around that you kind of actually are creative and actually are truly productive.

And there's these blips, but it feels at least for me, it feels uncomfortable to find the space because it's so hard to block off the space.

But it's like it's only when I'm like, you know, like like yesterday I I was I sent Carlton a picture, like I got the Harry Potter video game, and like I have no time to play video games, I've got kids and stuff, but still if I find half an hour an hour, like I'm convinced that's when I'm gonna have like an insight because it's like my brain is focused somewhere else.

Anyway, so I'm I'm very kind with the idea that like I don't need to be constantly like going to be productive.

It feels productive, but I feel like it's actually probably not productive in my line of in in what I do, anyways.

Sorry, that's a long tangent.

I want to hear what your thoughts are on it.

Okay.

Well, so

He's the one who's like, kid kids are good because you're playing with the kids, you're thinking about something else.

Like, like it's all it all kills.

So the right brain can get on and do its thing.

Otherwise, the left brain's just like, yeah, we're gonna focus on words and things and logic and space.

And the right brain's like, No, I want I want a bit more freedom to do, so put on some music, play over the kids, do something different.

That's important.

That's where the insight comes from.

That's why it's in the shower.

The left brain's like, I mean, I'm busy washing the right brain.

It's like, haha, here's your genius idea for the day.

Like that happens.

For me personally, I'm still going through this kind of um process of clearing the COVID black log.

The the the you know, we had that year of lockdown, and then we had illnesses, and then massive stress.

And I got to the point last year where I literally had to put a pause on almost everything and just take on one thing at a time, get the next Django release out.

Okay, that was out, get the channels update out, okay, do the conference or you know, just get through to the end of the year and managed to do all of that.

And then just as I was sort of um reaching an even keel, my daughter had an accident, she was, you know, ill, that was pretty serious, and then my son's now ill, and it's like, okay, right, just take it one step at a time.

And so to for me, it's like, okay, finishing the fellow role, got to the end of March, got, you know, said I was gonna stop at New Year three months to wind up and you know, give time for finding a new fellow and all those sorts of things.

Okay, fine.

Now breathe.

Well, for me, it's button, which is my simple deployment story for Django that's been on the back burner for two years, and I just really haven't had any chance to work on it.

Well, okay, that's what I'm gonna work on now.

And for me, it's like productivity 101.

If you've got too much on your plate, too many balls in the air, put them down, get one ball, get rid of that, then that's one ball less, get the next ball, process that, get rid of that, one ball less.

Then all of a sudden it's like, oh, do you know what?

Actually, I've got an empty job list.

And I know that's really basic.

But when you're when you're stressed, when you're when it gets too much, you've got to take those kind of emergency steps to just focus on what's important.

That's my tech.

And was there a special like moment in your brain when you knew like I had to make the change to reduce the list?

It's 2023 now.

So start of 2022, I was just going for a walk and I had a um a phone call from the neighbors of my my parents, and my mother had uh been taken ill and was in hospital, and it was like ah, and it was like ah just one too many things, and it I had to at that point I was like, I have to, I just I gotta take remedial measures now.

It's it's that my life's on fire.

So, okay, how do we stop this?

Well, okay, we pause, we focus, put that to the side.

You know, just and it it really is productivity 101.

You read any productivity books, project project management for dummies.

It's like, well, take if you've got too many projects, pick the one that's most valuable, do that first.

And okay, fine.

So at that point, I had to deal with family, and then you know, they had the the check the big Django release I was release manager for, and then you know, so on.

And there was just a list that got that went on.

And around October time, around DjangoCon US last year, I thought, yeah, I've cleared the COVID back block, it's great.

I'm you know, on the there, and then my daughter had arcs, and then you know, life said, No, you haven't.

No, you haven't.

So it carries on, and now it's like, okay, I finished feathering button and then the summer, and then you know, we'll see what comes next.

Yeah, yeah, I think that's a really important skill that I know you you need the time to just introspect on yourself.

And you you've got to if you can identify that and take measures before burnout, then that's that's helpful, I think.

Like for me, I still do like walking or jogging time for me is non-optional, like at least an hour and a half a day and two times a day, maybe.

Not like three hours total, but you know, like 45 minutes per time.

Super important.

Like, and I don't know, like the shower thought thing is like the most realist thing ever.

Like almost every programming problem I ever have, it's like either in the shower, on a walk, or like eight seconds before I fall asleep.

That's when it gets fixed.

No, entirely.

I'm gonna go and cook dinner.

And then halfway through cooking dinner, it's like, oh yes, of course, colon.

So there it's easy to think when you're feeling not bored, but you're like, oh, not quite sure.

It's like, oh gee, I could be doing something that makes money.

Like that sounds good, that feels good to be productive.

So it's it's even harder when it's like, oh, well, like instead of going for a walk for, you know, it's like that could be, you know, X amount of dollars, and that would feel nice.

I don't know why, but like that would, you know, it also takes a while to kind of get over that to be like, yes, I do want to do consulting and it's valuable, but also, you know, not just fill the void with um paid things, which you know, sometimes obviously you have to, um, but it sort of gets this feeling of I think enough, you know, enough in terms of work, in terms of money, and and valuing valuing that time of like not doing all these other things.

Like, have you ever been in a plane?

I'm probably I'm assuming you guys have been.

And uh the flight attendant is always like, you know, if something goes crazy, you have to put your mask on before you can put the mask on of your children or family members or whoever might need it, because without you being okay, like they can't be okay.

So, like that analogy in my mind, I always think about that in terms of myself, like you know, like trading time for money as doing consulting work or whatever.

It's like, wait, you gotta step back and like make sure you're okay before you can do the other stuff.

Absolutely, 100%.

And that applies to everything in life, like parenting.

Like you, you know, if you if you're not emotionally well in yourself, you can't help your children to be emotionally balanced.

It's yeah.

You can say now they're seeing that even parents get stressed and raise

their voice.

But yes.

Well, you're seeing daddy's not perfect.

You're welcome.

Um, you're headed off to Florence.

Nick here, because so so Nick, you were saying you were saying you were doing lots of uh work, the podcast, you dropped the podcast.

Then so so how is it you came to seek full-time employment or seek a gig or seek a a job to instead of that?

Yep.

So prior to the full-time gig, like even when I was doing the courses, podcasts, etc., no, I was still spending a majority of my time doing contract work.

And there was a company where I don't know, the last like since the end of 2018, I was doing contract work for them.

Like I started off helping them get their apps running in Docker on AWS, and like, you know, I I had consistent work with them, maybe sometimes five to twenty hours a week, and I just continuously did that with them.

And uh eventually, you know, they were asking if I can join full-time, and I said no, thank you, and then they asked again, and I said no thank you, and then they ask again, and then like you know, nine months later, um, I decided to join them full-time.

And so tell us about your role.

What what

When you're still there, you're yeah, you're still you're still there, you're doing, I think you said before, like focusing on deployments stuff, right?

It's sort of kind of all over the place-ish, but it is focused on, yeah, just I guess deployments is the core critical component of it.

So I'm dealing with Docker and Kubernetes and just AWS and Terraform, Ansible, a lot of shell scripting, basically developer developer tooling.

So, like trying to help build tools to make the developers more productive, um, just going over like CI CD processes or generally like dealing with releases, like how can we make that more efficient, even if that spans beyond just like writing code, you know, it's just like how do we take an idea from like concept to rolling it out to production?

Okay.

Um, yeah, it's kind of all over the place.

But it's nice because I I feel like I have basically almost full autonomy.

So, you know, I still report to somebody.

Uh, the person that I report to is the person I worked with directly when I was doing contract work.

So it was a really nice fit there.

Um, but yeah, we just like bounce ideas off each other every week and just you know work on doing things uh that take priority.

And I guess priority is an interesting word because yeah, it's like you can't, there's so many good things to do.

Like, how do you pick one?

So I you the list of tools you ran through there was basically like everything in the sort of DevOps candy store, like you know, Ansible Terraform, AWS, Docker, Kubernetes.

Like what's your favor what are your favorite bits of the stack?

And you know, what's your what lights you up about all of that?

So for the longest time, I I avoided Kubernetes for for years.

And um, and uh and I kind of hopped on board with the meme wagon where it's like, oh, it's so complex, like no one's ever like why would you ever use that thing?

And the more that I use it now, the more that I actually like it.

And uh just for context, like the place that I'm working at, we're not at like crazy mega, like insane scale where we're spinning up thousands of containers with like hundreds of developers.

No, like the dev team, there's uh 11 developers, we've got eight services, and it got to the point where Kubernetes started to make sense for us because we were spinning up individual EC2 instances or servers for each service, and there was a lot of duplication there, so we converged on one cluster, and now I don't know.

I I'm liking Kubernetes actually a lot, especially with another tool called Argo CD.

I don't know if you've heard about this one, but um yeah, it follows this philosophy of like GitOps, where right now, like instead of pushing uh code to the cluster with um maybe doing, I don't know, some well, first of all, before we get into great details, have you ever worked with Kubernetes a bit or no?

And that's the the bit for me where I'm like, I don't want to deploy it for my I don't want to use the extra complicated tooling for one service or one service in a worker, you know, it just doesn't make any sense.

So like the 30-second okay, the 30-second elevator pitch on Argo CD is like, you know, you can kind of have your Kubernetes config files in a git repo somewhere, and like it will just check your git repo on a specific branch every three minutes, and it will just converge the state of what's in that git repo to the actual cluster.

So like I don't need to like push deployments, it's more like pull-based.

So we just modify the config files to be like, hey, here's the new Docker, you know, tag version for the image.

It picks it up, it rolls it out.

You know, it handles basically the you know CD part, like continuous deployment.

You said DevOps.

So I mean, is DevOps is DevOps a thing or a practice or what?

What's your view on I mean, I mean, would you describe yourself as doing DevOps, Nick?

Right, right.

But like I feel like, to me, like just informally to me, DevOps is it's more of a mindset.

It's like an orchestration of things.

It's not necessarily like what you do, you know, it's not like it's not comparable to Kubernetes or something.

It's more just like a workflow of things that you do to make everything better, and not necessarily just like the tech part, right?

Like it's not a CI CD system, it's like, well, how do we have this idea, right, that can go from development to production and in a in the most efficient way possible, balancing with developers and like product teams and everything.

And you'd kind of sort of, as a developer, you'd get your your your app ready to go, and then you'd sort of have to throw it across the divide to the sysadmins on the other side.

And they weren't really that interested in catching it.

And if it fell into the chasm, well, oh well, not a problem, or if they dropped it and it smashed, oh well, not a problem.

it's gilfoil and and it was kind of like that.

Would it does that?

So, like specifics about our dev team setup.

You know, we've got 10 or so devs, a couple different teams, like let's say three devs on each team, and they can take their whole idea from concept to production on their own.

Now, I helped set up like a CI CD pipeline for them so they can deploy things, but from their perspective, all they need to do is, you know, make the pull request like they normally do.

It gets peer-reviewed by someone on their team, and uh then the quote unquote release manager is really just you know, the engineering manager has to say okay to have the release, but him is just like literally merging that pull request is the release, and that's it.

Like as soon as that happens, things get kicked off and get auto-deployed.

So they don't need to worry about like what is Kubernetes or Argo CD or any of those other tools.

But and then it's on them to yeah, just make sure it's running well.

So like I've set up Datadog stuff like logging and metrics, and they can see the insights on their app.

Like I help them, you know, debug and profile things, but you know, they've got all the tools they need without necessarily needing to be, you know, crazy deep in the woods with the the grey details.

So can I ask if for so that's quite a big team, and I think that's you know, as you describe, it's a lovely setup.

You've got something where the the developers are freed to just sort of push to their code and it's all ready to go.

Almost like a platform as a service.

But for a smaller team, like at what point, because I'd very much for like a small, you know, one to five where you haven't really got the specialist ops operation, keep it simple, you know, spin up the single EC2, run it on there, scale that up for a bit.

I kind of think that that at that small scale works much better.

But what what point can you what point do you think you grow up you grow out of that or that it makes more sense to move to?

Um something like the script the setup you've described.

There's like a m multiple different components that you can scale off of when you need to do that.

Like, for example, number of developers on your team versus also like number of services you might have.

Uh, there's still technically, I guess, value in Kubernetes a little bit, like even if you had one big monolith or something, just because you know it abstracts away some of the details that are hard to do yourself, like just doing rolling updates, like a zero downtime deploy, like keep this one version running, put up the new one, and then get rid of the old one in the load balancer, that type of stuff.

Uh, I'm curious, Carlton, did you end up rolling some of that stuff your uh basically on your own?

very well for you know again a small deploy.

Um how how big do you want to push that?

You know, you're running multiple services on a single instance, no, because they get in the way of each other, and you you just don't want to do that.

Um and it's what's interesting for me is the point at which you grow out of that, you know.

That's the bit where I'm you know, that's not really where I'm targeting my button.

I'm targeting very much the simple setup.

You know, you've got an app, you want to get it online.

What's the the what's the story that saves me having to take a week of learning you know tools which are perhaps too powerful?

But I also want to have a story for okay, at this point you need to start considering, you know, EKS or whatever the the other options are that are a bit more um powerful.

Like if I were to you know put together my own software as a service, you know, like some like real thing that customers would be paying for, I'm gonna be deploying that to one server, probably using Docker Compose, maybe using Carlton Service, depending on if you know when it's available.

But yeah,

No, but that was it.

And guess what?

You're good to go.

Yeah, yeah.

And it's handle the handling the traffic isn't the question.

Like what's the question, I think, is handling the dependencies between the various bits you're deploying.

Or if you know if you've got an add-on which suddenly needs some old version of Python or some, you know, then that's no use a container then because what you don't want to do is try and manage these multiple versions of Python on the same box, and this one needs that version of this, and this one needs that, and dependency hell and all those things.

Like it's gonna pull things off a Redis queue and that's it.

And you know, and the the the the motive what got me started in all this, you know, and what I'm uh you know bringing to completion now was the frustration of seeing um beginners, you know, perhaps they use Will's book, you know, got their first app online, and then getting sucked into a kind of pro-level ops game, which was totally inappropriate for them.

Um, and that's what I'm trying to avoid.

But what are you building?

What are you deploying?

So you're deploying these eight services.

Are you building with Django and Python or a different stack?

Sorry, in advance, by the way, because that's a

No, but we don't have to do that.

It's competriots, not competent competitors.

Yes.

We're all like on the same team.

But yeah, the other ones are more just uh really large PHP applications that I am not so much involved with in the day-to-day, but they are being deployed.

Okay.

You know, we're talking like 12 years of uh development on the apps.

Okay, fantastic.

See, people apologize for code.

I've got this this old this view that any running software is just amazing.

It's like a miracle of, you know, a miracle of life.

And something that's been in production for 12 years, that's you know, that's that's a massive achievement.

And it's never gonna be the case that it's gonna be using all the latest this or the latest that.

It's never gonna be perfectly clear, clean code, it's never gonna be, there's gonna be horrible bits about it, but you kept it going for 12 years and you built, you know, code with it, that's an achievement.

I think, you know, not you, but the team and the company.

I think that's a uh I think you know, I just don't think we should apologize for old code.

Because it's like your customers don't necessarily care that much about your tech stack, as long as you provide a valuable service to them that they like using and it runs reasonably fast and like user experience is good, etc.

etc.

Yeah, it it all works in the end.

Okay.

So you're you're a teacher.

How do you explain this?

I'm thinking of this because I have the 4.2 update to my books about to come out, hopefully by the time this podcast comes out.

And I've been adding a lot more of the um the the how, not just the why.

That was one of the early criticisms of my books, but I sort of showed how to do things, but I didn't dive into the weeds because I didn't want to overwhelm people.

And I've added a lot more in subsequent editions and visualizations, but there's this big jump from local to production, right?

And how do you like it's hard to explain to someone who's learning code, like, yeah, all three of us could build Twitter in a weekend, but we couldn't build it at scale.

Like, so like why is it so hard?

Like, so how do you explain to people like the difference between like a thousand users and like a million, right?

Because that's where you get into load balancers and servers and DevOps.

Um but it's hard for people to feel that and because they can't just you know, like we can just build a clone of something and feel it, but you can't mimic the the scale and size, and even if you could, it's expensive.

So you wouldn't you kind of have to be thrown into the fire.

Um, I'm curious how you approach that question because I constantly think of how to explain it in real terms, not just abstractly being like, yeah, like there's two real engineers and there's like 10 DevOps for anything at scale, and they do a lot of stuff and it's complicated, and you don't want to deal with that, use a platform as a service.

Like that's kind of my like my glib answer to beginners.

Um, anyways, so what what do you what do you say when someone asks you that as an expert teacher?

And you know, I think Heroku kind of did an okay job at this one how long ago?

Like, do you remember this 12-factor application?

Like it's a methodology they put together.

And what I found at least, like even doing some contract work and everything, is that oftentimes the scaling part, it's not so much the details of the scaling.

I mean, there that is a hard thing to cover for sure, but it's just yeah, just getting your application ready to scale

is a

And it's like a precursor to being able to scale.

Like, for example, you know, let's say that you have some user authentication and your session backend is just running in memory, right?

Um, not using Redis or anything like that.

And now it's like, well, now you have to go to two servers, but now you've got two copies of your application running.

User hits server A, they're logged in.

User hits server B, they're not logged in because it's in in-process memory.

Uh, that's a problem.

Uh other problems are like file uploads, right?

You upload your avatar, but it only goes to one server, not the other.

Suddenly someone gets on server B and avatar is not there anymore.

So it's like you've got all these dependencies that you need to like handle or precursors to scaling out.

Yeah.

So I think it starts there, in my opinion.

When one of the first um gigs I ever had, there was uh, you know, slime was from somebody there was like the hardest thing you do is move to two servers, like from one to two servers.

That's the hardest jump.

And then, you know, three, well, you've already done everything you need to do to get to two, so three is not too bad.

So the takeaway there is like figure out what you can do to stay with one.

So you never have to do the hard stuff.

But right?

I mean, I think it's so yeah, I think uh many of the um the stack for May, the apps you're working with is PHP.

I don't know if you use, is it Laraforge or whatever the hosting thing is there, but you know, that's a multi-million dollar business.

And he's written publicly, I think it's on two, three like servers, the entire thing for like hosting thousands, however many PHP apps.

You know, you just like it's a good example of like you don't need to if you don't need to do all this stuff, don't do it.

And try really hard not to do it.

Like seems to be maybe the takeaway for listeners.

And if we're on

It's a bit like third party, you know, on a on a local level for someone who's newer, I think it's a little bit like third party packages, in that when you're starting out, it's like, oh great, it's like superpower, just toss them all in and they all do stuff, and I don't know why, but boom, there's my authentication, there's this and that.

But then it's the update hell, and you don't really understand it, and it does come back to bite you to the point where like now I don't use third-party packages unless that I really, really, really need to, and I kind of know they're really, really good, because I'm just like, it's like a parachute every additional thing, right?

Because the updates is always it's always the packages.

But actually that leads into a thing.

You mentioned uh before you came on air, you just updated to Django 4.2, uh, even though it came out yesterday.

Yeah, yesterday, Carlton.

Yeah, yeah.

Can you how how is that how is that update process?

And then Carlton can tell us about all the blood, sweat, and tears to um get that release out.

I know Maris was the release manager, but I'm doing

Marish Well, for one then

Marish was doing it all by himself and poor fella.

Uh he managed to get it out the door all totally smoothly.

So well done, Niv.

Go on, Nick.

Tell us about uh your starter project.

So I do have uh a Django starter project that is using Docker, Docker Compose.

Like it is the optimized for that one server deployment type of thing, but also good for dev.

And yeah, so I updated to uh Django 4.2, like I don't know, an hour before this podcast call now.

And that was a very, very, very painless update.

So one thing that I do is when I jump between Django versions like 4.1 to 4.2, like minor versions or a major one.

What I like to do, since I'm, you know, I have a starter project, uh, I like to generate a new project using 4.1, generate a new project using 4.2, and then I'll do a directory diff on that to see what changed, like the project generators for creating a new project or apps or whatever.

And in that case, there was like basically no changes at all.

I mean, a lot of it was just updating the 4.1 link to 4.2, like you know, Django in the settings file.

Yeah, they give you good links to like here's how to you know do database configuration.

So it was that there was like one string and one doc string that changed, but it was super painless.

I also updated uh Psycho PG2 to using what is it now?

Psycho PG.

but it

There's um uh so it's the new back end, it's a new version of Psycho PG, um, and it's got asynchronous drivers, and it's quite exciting.

So it's gonna be the future.

Um, and there are a few little niggles, like if you you know, things with tuples and whatnot that you need to watch out for a couple of gotchas on on whether it's strictly backward incompatible.

But it's you know, if you just install the new package, Django will just use it.

And for most use cases, it you know, it's totally transparent.

Um, but what I think it for me, the exciting thing at least is that um it gives us the opportunity to have the asynchronous client.

So um 4.2, we've introduced um support for streaming async streaming responses.

So you can feed, you can return um a streaming response with an async generator, and if you're running under ASGI, it will stream it out asynchronously without blocking your worker, without blocking a thread like it would under WISGI.

And you can generate, you know, use good for service and events or long polling or these kind of long-lived request examples.

And so with an asynchronous um Postgres connection or Postgres client, we could in principle use listen notify to you know do an update, have something trigger in the database which then notifies the client, you know, some kind of real-time goodness.

And it's you know, over the next you know, year, two years or so, those patterns will become um codified and blogged about, and you know, maybe there'll be third-party packages wrapping up exactly the best patterns for doing that.

But that's an exciting and fertile terrain that we're in now.

That's it's like okay, these are new um new usage patterns for Django that haven't been available before.

And you know, there's you you could have done similar channels or what or whatever, but to have the asynchronous database driver there as well, it's like the full stack.

It's like, okay, there's there's some opportunities here for things which weren't previously possible.

So that's what I'm excited about.

And you know, these things need to work together if you want the full experience.

And I think there is also there is like um an async test client as well, right?

Yeah.

Yeah, yeah.

So you can have an async dev view, and it'll you know, you can make an HTTP request to it with the sync client, and it will test, it will run your async code and return it.

And so you don't need to necessarily write a sync test case.

But say, for instance, you're writing a um say a middleware, an async middleware, and you want to test its async behavior sort of outside the full Django stack, the full request response cycle.

Well, then you would use the async client because you could write an async dev test and you can get the, you know, you can do all these kind of things.

You don't necessarily need to use the async test client for your kind of standard view test.

You know, did this view return this response?

It can be an async def view, but you can still use the sync client for perhaps simpler testing.

So just to rewind back to what it was like, yeah, and to update to 4.2, super easy on my end.

Like the starter project, it's not like building out a lot of business logic.

So there I didn't have to go back and modify a whole bunch of different queries uh just because it's all set up and ready to go.

Like you're, you know, as the application developer would be using the starter project to build your own app.

But Carl Turner will, I'm curious, like what was it?

Have either of you updated like an actual application to 4.2 yet?

And like what was that experience like?

It's only been out since yesterday.

Um, but I'm on 4.1 point, whatever the latest is, and it will be totally seamless.

Um I think the biggest thing is the storages change.

Um, so storages have become a dictionary now.

Um for you, so you can define multiple storages.

Um and the old settings have been uh deprecated for the new one.

But um Adam Johnson has his Django upgrade project, which has got an updater for that, which you can use.

So there's two or three small settings updates like that, um, which I'll be running Django update to use.

I'm quite excited about Django update.

I think it's it'd be really nice if every single release we can ship a set of, you know, to run this, run this updater, and it will automatically go through your code and make the necessary changes so that you know you don't have to worry um

about those.

Does that I haven't used that updater yet or upgrader yet?

Does that run something like black where it will like go through everything and kind of look at things and either warn it or you know, warn you or do it?

So PyUpgrade, you run it, say Pi upgrade to you know 3.10 syntax, and it will go through and look for all the the cases where you know the new syntax is this and you should be using that, or you know, this import moved.

Um, and they it's done with the AST module.

So, like you know how Black takes constructs your AST and then rewrites it, rewrites the code exactly how it's meant to be.

Well, um Django Upgrade does the same thing, but looking for, you know, have you defined this setting?

Okay, though this setting should be rewritten like this, um, in this case.

It's a great, it's a really interesting project because um one thing we want to do for say Django 5.0 is modernize the request object.

We want to add um so JSO a request.data um property which would handle, for instance, JSON content.

Um, you know how you get form data passed in request.post.

Well, you know, if you've got JSON, instead of having to manually pass the body, you could just you could get that passed automatically and then give that pluggable passes, maybe.

But while we're at it, there's a proposal to modernize the request.

So instead of request.get, have with capital letters screaming from, you know, and it was basically copied from PHP back in the old days to have request.query parames, which is a more you know Pythonic style, lowercase, um snake case, um, you know, a bit more modern.

And the the worry with doing that has always been that we've got so many deployments that people are like, please don't break our code, please don't break our code.

But if we can have a project like Django Update that will automatically that's scriptable to automatically rewrite your code, it makes that transition um less jarring for people, and then it makes it more realistic that we can do big upgrades, you know, bit big changes that have previously perhaps been a bit like we can't do that because it will upset too many people or you know it's not worth it.

Yeah, I love that idea.

Like add the flags on run server?

Do you know about do you know about these?

And I guess just to segue back to what Carlton was saying around like, you know, what are some things you can do to prepare your app to scale or whatever?

I guess this is not necessarily related to scaling, but I do like to keep my development setup as close as possible to production within reason.

Like I would always use Postgres.

If I'm using Postgres in prod, I'd use it in dev, etc.

But likewise with GUnicorn, I do the same.

And oh man, I remember it was a Django 4.1, I think it was.

There was some change to how it deals with um the template loaders.

So when I was using GUnicorn in development, like the default loader no longer does like, I don't know, it enables caching by default.

So like I was updating my HTML templates and it didn't reload my templates in development.

And I was like, what the heck is going on?

And then someone replied to a Twitter question I had within honestly like 15 minutes of me asking the question, and they're like, Yeah, you need to explicitly, you know, not use the cache loader in development.

But that was super easy to fix.

Like, yeah, another like random question thing, like just knowing the problem sometimes is super helpful.

So you'd like the twelve, you mentioned the 12 factor um uh 12 factor idea where you move methodology.

Yeah, methodology, thank you.

Where you move um configuration values into environment variables is basically the one of the key approaches.

But something like um uh a template config, which is quite an elaborate dictionary, uh how how would you handle that?

Would you handle that?

Because I'd handle that with separate setting files.

I'd you know, I'm happy to move things like secret keys out of setting files so I don't commit them to Git, but I still have you know, here's my dev settings, here's my production settings, here's my thing.

Because for instance, if I've got a different templates config, that's a whole dictionary or databases config, that's a whole dictionary.

I don't want to be mapping those for environment variables.

I felt I find that quite tricky.

I'm wondering how you how you'd handle that exact case of um needing to change the caching behavior for the templates config in development versus okay.

Yeah, sure.

And what I ended up doing were there was I defined a new variable called default loaders, and this included what did it include the file system loader, app directories loader, and then I made another variable called cache loaders, and that one would take the default loaders and also append to that list the cache loader.

And then inside that dictionary, the templates dictionary, you've got this loaders property.

And there I just dropped in a one-line if condition

that said if

So there was no new environment variables that had to even be created.

But if debug is enabled, then you get the good experience in dev, and if not, then you get the cached one in prod or any non-development environment.

Right.

And then there was like a one-liner if condition in the actual templates dictionary or list, whatever.

No, no, no,

good, that's all good.

Oh good.

Yeah, we'll do that.

Okay, all right.

I'll find it, yeah.

Well labeled, it's not gonna be like update, update, update.

No, everyone's gonna be looking at your commits.

Um I find that if you're just I guess using run server with the flags, uh I I feel like most people have no idea that the deprecation flags are there, and there's all this work that people put in.

So for example, like with forms, um there's changes, and in 5.0 they're gonna be made permanent.

And you would see that if you ran you ran with the the the flags, but you otherwise wouldn't.

And you know, it's a bit of like, okay, it's in the release notes, people talk about it, but you know, in the real world people like don't know, right?

Like until someone tells you.

Um so I guess did you see anything on forums or are you aw aware?

I mean you don't need to be because it's not a f it's a 5-0 thing, but like there's some changes to how forms are processed in Django coming.

I'm totally putting on the spot.

But I'm just w I'm just wondering if so you doing the upgrade process, if you put you probably wouldn't see it unless you'd like deeply read the release notes and decided to act on it and had run it with flags.

Um but as someone who uses Django but like is a jobbing developer, lots of other things, like it probably didn't come up for you, right?

Because it's not it's not gonna break things yet.

Right.

I mean I go through the change logs specifically like the release notes and look at everything.

And I know that you guys do a great job updating those things but I wonder well let me ask this has there ever been a case where you release a new version of Django like a big minor or major update and something didn't make its way into the release notes and like someone found it out after the fact and had to open up like a PR?

I mean occasionally it's been like no actually this is a this is this is something that we actually have to revert and that's more happens in the pre-release phase where and this is why we have the long pre-release phases for people to test the pre-release versions.

I can't remember the particular example off the top of my head but I remember one a few releases ago which it was quite moderate change and it went through and it was like no actually at the release candidate phase we have to revert this because it's too disruptive to the ecosystem and you know so we we roll that back.

But quite often they'll be like look let's add a release note clarifying exactly you know if you're in this circumstance what the change in behavior is or you know that that happens quite a lot.

Fortunately we have a you know an active community who do help join the pre-release phase and you know it's three months I think in order to catch bugs catch regressions um you know catch visual the things in the admin whenever we make a change in the admin there's always visual regressions because you know CSS being what it is and we're not you know we're not front end developers by sort of calling um but you know what they'll get spotted they'll get fixed and there are um you

know normally we'll be able to do something I mean there there's a there's a good example came up this release cycle of um module loading so the the mana the cached manifest storage which takes your your your JS files and your CSS files and it creates a manifest of them and get like gives you a um like a long hash a file name so that you can put far x far future expires headers on and when

you update them the hash changes and you don't have to clear your caches and people get the latest JavaScript or latest CSS but they get it from their browser cache where possible.

Turns out this does there was a fix to to make this work with module imports, you know latest JavaScript syntax but it only captured some cases and there were some weird regressions and we spent quite a lot of time during the pre-release phase trying to get that as as good as we can and in the end there's a warning in the in the notes saying look this may not work for all cases and you may have to manually get rid of import statements in comments.

Like that they're in they're commented they're not real but they they've got the same syntax as import statements.

And these come up in source maps and things like that.

But to work through all of that and get that working properly was you know and what's the best option?

Are we going to have to revert this?

Well this is you know it's a good feature we want it ah there's quite a lot of work that goes into getting it just so

Like if I'm using G unicorn in development is there any way that I can get like a G unicorn hook to get that

So you run Python with the dub with the W flag the capital W flag which is for warnings and then you run it with with all warnings and then you get um deprecation warnings and which are noisy by default but also pending deprecation warnings so the the the the the the ones that will be removed to out you'll get a you'll get those showed up in your console or in your logs and then you can you can fix it.

Okay.

I'm gonna move on with my life.

I should yeah that'd be a good I yeah I'll do that.

I'll do a little post because you know Adam's tool Django upgrade like there's a couple things that people should know about if they don't just to when when you update your code um how to do it as well for a like yeah yeah yeah sorry thank you for saying that yeah if

So there'll be one from you know Django Compressor or one from all or one from Django filter or one from you know whatever package you're using and you'll be like oh there's the aren't with Django 4.1 this uses this raises that and that's an opportunity to contribute to those packages because the the maintainer will be grateful to take the PR fixing that warning because they know they're gonna have to do it before the final release and you know it's a good way of getting in and finding something that's concrete and probably quite small to work on.

But you know even if you just have them output it to you know standard out it as long as you're not outputting lots and lots of text so that they get lost you see them very quickly.

And funny enough like you know if DevOps stuff is on topic maybe for this call like you know this happens a lot like if you're adding a firewall in front of your service you know example.com or something you may want to enable your custom rules in count mode instead of actually blocking so you can see in the logs like hey did this rule work the way I wanted it to and then you can like change it to block later you know so you kind of get the insight of what's going to happen before making a dangerous change.

turns out you get no more traffic ever.

I mean and it has got how to upgrade and how to run with warnings and but it takes a while to find all of that right

Res framework at some point some version of that needs to come into Django itself and then a better upgrade story.

To me those are kind of the big three and so Eric's been working a lot on this he's he's the author of Python Crash Course and it currently works with Roku Platformer and Fly but it's exciting I hope it gets legs in terms of being an option that's a platform agnostic that kind of tees up a standard vanilla um application and makes it deployment worthy.

So that's um just something to mention regularly to people that it's kind of a cool project I hope he I hope he continues with it and gets gets some help but it's kind of exciting.

as you can you've got your project then you can run simple deploy and then you've got a diff to your to your project that you can look at and see oh these are the changes it had to make to deploy for fly or deploy to platform.shell or whatever so I think that's I think it's super I'm really excited by that project.

see there's real growing pay uh pains with all these next generation um platforms as a service so you know specifically fly like I I wrote the Django docs for them I'm using them in my book they're updating twice a week their command line tool and there's all these little subtle things that um keep changing they they're having you know all these th pla these platforms are having growing pains um so they're not they're not quite Heroku I mean they haven't been like killing your database and like being completely off but

I I kind of wish I could fast forward to two years from now where you know one or two have won out and they've figured out a lot of these you know Django specific issues that they're all kind of having because there's all these cobwebs and stuff under the covers um you know as they're finding so it's a little you know as a book writer it's a little frustrating because I have to update things all the time but I think it's overall good but it's like oh man Heroku like why couldn't you just why couldn't you just stay Heroku I don't want to write about deployment.

I want to write about Django

Yeah um I just have been focused on doing it raw per se but um I'd love I'd love to off to put it to something else.

I mean the thing with the book is I've constantly removed third party packages over the years.

Like I I've had stuff on Stripe and I've I had a bunch of third party packages and now I'm really really really um reticent to add any because I've just been caught by changes with them and then people saying oh this thing is broken and you know it's it's like hard enough to make Django work but it's all the other stuff.

It's always the deployment and third party package things that you know make the book not work.

So like to the point where in the book what am I using now?

For the beginner's book I'm only using Django all auth, crispy forms, I think it's like one or two other ones but I'm like really pulled back on what I use just because I don't it's yeah the dependencies.

Dependencies are what gets you.

So what do

I mean ultimately it's not a book on layout.

But yeah I would I would use Tailwind and um and the professionals book too that's the one that's sort of tricky for me because that's the one I feel like I would optimize it and do kind of all these things but I have to kind of take it to a point where it's maintainable and kind of universal rather than getting into the specifics of fully you know I I have stuff on caching.

I don't think I cover template caching just because it would be a thousand page book and I already can barely update them.

But um I don't know maybe maybe I'll kind of specific courses on these things.

Because I do think there's a need for it.

It's just very hard to stay up to date on all of it.

I mean even for me.

What do you think?

The problem and Nick you can relate to this the problem is that I pin all the versions everything works like it works it works I test it I test it.

But then people just you know install the latest version of Django and say hey all these things are broken.

Like like I don't you know they're just gonna do what they're gonna do.

Even though I have a whole thing on how you do it um and I don't blame them for it.

You know like fine.

So uh I'd I might I'm gonna need to try to do something like that with the other two books because they're they're they're a lot harder to to maintain and yeah I I've still resisted doing the dot X thing on it even though in practice like I missed the 4-1 update.

So yeah there's a main there's a maintenance thing.

I think probably the biggest thing is you know shake my head I think the biggest thing is maybe not making the both those books um not making a professional's book one big project because I've used this analogy it's just like a Django puzzle puzzle and just one thing breaks and I have to redo everything and it it's it's hard to maintain.

I would rather have it be concise areas a little bit more like um two scripts of Django except that's very abstract.

They don't actually show you how to code things.

So but like you know kind of like here's caching and let me go into all the things like that would make it a little more maintainable for me.

I don't know Nick you've had this problem too right because you have you have video too you have full courses and video.

Like the maintenance thing is is tricky to figure out

Like I still have this problem.

How do you keep it like you I pin I I do pin everything to their exact like patch release and then yeah at the end of the course I have incremental updates to be like oh we're gonna update from this to that here's how you would do it.

But then it gets to the point where like you have so many updates at the end where it's like you

just got

to re-record everything from scratch because so much has changed over the last like two years or three years or whatever happens to be.

But I do like what Carlton mentioned too like you know just having like the X variant like instead of maybe doing those incremental updates live in the book like literally a chapter for each individual one maybe you can like bring it up to more of a higher level to be like you know here's what I would do when it comes to updating to a new version of Django like here's a checklist of stuff that I would uh tackle where you're not going into every specific step but like you more generalize it.

Yeah I'm gonna I mean I'm a broken record on what I I've I thought for 4.0 ones I would have this and maybe for 5-0 uh I'll have this but uh yeah I don't Django Django isn't the problem Django's not what changes it's deployment or third party things but um

It's broken.

You know like these are the types of bugger ports that you get when people take your courses or go through books.

And again it's just like everything again Carlton's been a fellow for five years so this is all just like ripples on the oceans of stuff he deals with but it's just like these little things it's like ah dealt.

I just want to focus on the big

dealt with dealt yeah past tense.

I'm retired.

Yeah well

But I guess like what that really means is like more batteries included potentially with Django.

And I know it's already batteries included but like there are at least like I have worked with Rails before too and you know I don't know a lot about Laravel but like I sort of just briefly glimpsed what's going on in all these communities just for the sake of curiosity.

And like no they've got this like built-in functionality to deal with like notifications.

You know like do I want to send an email out or an SNS message or maybe over a WebSocket connection so the user can get a little you know a red dot next to their bell or something like that.

I feel like other opinionated frameworks have solutions for that one.

I may be speaking dumbly here because maybe Django does have a solution for that.

I just don't know but is it more like third party or kind of just like not quite

This is another this is another dependency help like because I I I haven't been able to remove it from the from the books even though I'd want to like they're constantly changing everything and then Twilio bought them and they're changing their auth.

You know, so I have a chapter on email, and like three quarters of it is like navigating Sendgrid.

Um and the answer from the sort of the Python team is oh, it's about maintenance.

So now someone on the Django team when they say more batteries, I'm like, oh, but it's about maintenance.

So it's like it's kind of like touché.

I totally feel where you're coming from, but also it's like, well, what's what is maintainable?

I think there are so many good packages out there, and what I think we're missing from the ecosystem still, even with like Django packages and the great work that uh Will and Jeff do with the Django newsletter, is some kind of map of the Django ecosystem.

And it's still not easy to find the solution for what you want that's already out there and actually well maintained, and it's it's easy to use.

Isn't there's no, you know, I don't know what the solution is here.

I uh it it's just uh

So there is the awesome Django repo Jeff and I have Jeff and I maintain that's that's trying to to do this.

So it's ostensibly a curated list.

So it's if you look for email, it'll show you.

We don't say, you know, it's not chat GPT, we don't say this is the one to use.

Yeah, right.

But there is, you know, somewhere between Django packages where it's which Jeff maintains now, which is all the packages, uh the awesome Django repo is designed to be like, you know, we're very strict on what's in there.

Um but of course people don't want to have like, oh, here's the top three and like choose your own adventure.

They want someone who's an expert to just say, use this one right now.

Um I mean I do have yeah, I mean it's a it's just it's hard to be subject it's hard to be curated and subjective.

I mean it's like because you kind of put yourself up for flack, you know, instead of saying it depends, it would be nice.

But I agree, like maybe like the common question that I mean I have a top 10 Django packages list that's just by downloads, which is imperfect from PyPI, which kind of gives you a sense.

So it's like Django, Django S framework, Django cores.

Um it would be, yeah, maybe it's worth sticking your neck out a little bit on on that.

I mean, we had a guest, Carlton, I forget who it was, who made the point that who also has experience in other frameworks, who made the point that Django has a lot of batteries, but less magic than Rails.

Because I think I was saying something like, it'd be nice if we just had a solution for all these things with these other ones.

And you say, no, no, no, hold on.

Like Django has a lot built in under the covers.

It just is explicit and it's not as magical because of course, you know, oh, the email works until it doesn't work.

Um, you know, Django is down the slope a little bit where it's a little more challenging as a beginner, but then when you want to customize it, which you will, it's easier to do than I'll pick on Rails, you know, one that's a little more magical.

But you know, like the auth system and stuff has so much built into it um in Django, perhaps even more than um other frameworks.

But you know.

Are there any um so you have your courses?

Uh do you want to give a plug to your courses or anything um before we depart, Nick?

Sure.

Have either of you quickly heard about um a service or tool called Mail Catcher?

It's something you run locally on your dev box and it sets up a local SMTP server, and you can configure your Django settings or whatever to just send mail to it.

And you don't need to contact the third-party service.

It's not meant for production, but it's great for just local testing.

So if you wanted a quick thing to do, it's got a Docker image that you can run.

Um yeah, I've been using it now for a couple of months.

I like it.

I'm gonna check that out.

Huh.

So um Yeah.

Yeah, that's one of

It's like it's been around since like 1837, but like I just learned it a few months ago.

Like in the newsletter, we're I'm always like, we're never gonna fill it with projects.

And invariably we find at least two or three valid, interesting projects to add every time.

Um, but it sort of leads to like the cruft of, you know, we sort of maybe I should put a forum question, be like, what are the common questions that you have about what third party package does what?

And make like a top 10, 15 list and just say, here you go, like check these out.

Because I think there are there are some answers, right?

Like with authentication, it's all auth.

You know, there are some answers, and where it's not, there's like maybe two competing ones.

Like there's not that many out there, I would say.

I think it's do I think the list is doable.

Yeah.

And you'll be like, uh, but

You know, the ones that have Django's so mature now that those packages, there are new, new, new packages that come out all the time, but the the sort of core ones that have been around for a decade, they they're they're not going anywhere.

They'll still be here in another decade.

There's a lot of responses.

Um, so maybe it's worthy of just you know, linking, you know, just this is the problem, Nick, right?

Like you have the content, it's more or less up to date, but like you're still doing stuff and people's questions are the same, but your mental space has moved on.

And you're like, do I just repeat myself all the time, like on the video and then on the podcast, and then the book, and then in person?

And yes, you do, right?

Because it's new to them.

just because it's a little rote rote to you, um, you know, you just gotta like it's like a wind-me-up doll, right?

It's like it's like academics, Carlton, right?

You and another life.

Like, stand up before class and be like, I'm gonna tell you what I'm gonna tell you, I'm gonna tell you it, and I'll tell you what I told you.

Yeah, or you can read my book.

I don't care.

They go to a gig, they play the same tracks.

Yeah.

50 years running.

Yeah, well,

sure, but they're the Rolling Stones, so fair play.

Do you want to just quickly highlight the courses that you have that you still maintain, as you said?

Yep.

There's uh dive into Docker, which is dive into docker.com.

That's more like a ground zero getting started with Docker.

Um, I have another like build a sas app with flask.com that's using Flask just to build all sorts of different, you know, SaaS apps that you may want to build.

It uses Stripe, etc.

But yeah, all the details about everything could be on my main site, which is nickgenitakis.com.

You know, N-I-C-K, J-A-N-E-T A-K-I-S.com.

Perfect.

Not an easy one too.

Yeah.

A few times.

Well, Nick, thank you for coming on again.

It's always great to to catch up on the video.

I really enjoyed it.

Thank you.

This was really fun.

Hopefully, uh in two years or less, uh, maybe I'll come on again.

You're always welcome.

Sounds good.

Bye bye.

Bye bye.