Inverting the Testing Pyramid

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

Speaker 2: Hello, Will. Hello.

Speaker 1: And we're very pleased to have Brian Aachen back on the show. Welcome, Brian.

Speaker 2: Hey, welcome back. I mean well I'm glad you're glad to be back. No, no, no, you host Brian. That's really well. Yeah.

Speaker 1: So for those who don't know, Brian hosts two different pod uh podcasts. And books, courses, we're gonna get into all of it. But I'm really excited to lean on you, Brian, to find out about the broader Python ecosystem. So maybe I'll lead with that. An open-ended question. What do you see in 2026 in Python? Again, you sit much broader perch than we do.

Speaker 2: Okay, well there's it's probably not gonna be surprises. So um I s Uh we in 2024 we got UV came out and I can't believe it's only been that long. It's it just seems like that's the world now. Um and uh probably you guys, but uh definitely Michael and I and a lot of early adopters grabbed a hold of it. Like I probably I not right away. I I played with it right away, but um using UV even professionally, like in a a corporate setting, uh probably the start of twenty twenty five, but by the end of twenty twenty five, I'm I'm seeing like my whole company is like interested in it. So um I do see Uh I think I see see more corporations just uh and and corporate settings using the UV tooling because it just makes sense.

Speaker 1: Well you don't know Carlton that well then.

Speaker 3: Tell us about the corporate setting because I don't work in what I would call a corporate setting. So th it's important to prefix any discussion of my my choices with that. But Brian, what you tell us about your day job.

Speaker 2: Well, okay, so uh day job I'm uh well that actually changed over the last year, but it's fun now. Uh it's always been fun. But I I work for

Speaker 3: good good good recovery

Speaker 2: then. Um I work for a Rhodent Schwartz, it's a um uh test of measurement Um well they do a lot of stuff, but I'm on the test and measurement side. And uh so that's like electronic test equipment. And uh most of my career's been in cellular and uh and wireless and Wi-Fi test equipment. Um and uh these are these are fun boxes, but they're very complex instruments. And the uh what am I going at? Oh, um w a lot of the tooling around it, we don't there's I don't think there's I think there might be some Python inside some of the boxes, but not the ones. that I know of that I work with. Uh but we do a lot like we do the testing with Python. We do and a lot of the the utilities and all the day-to-day stuff. A lot of there's a lot of stuff that needs done and we use Python.

Speaker 2: And there's um There um and be because of that, th we try to, you know, maintain best practices and uh try to not jump on too many bandwagons, like uh because it we could be changing directions too quickly. Uh but um UV just seems like a der direction there. And because of this, the time savings. I mean Saving s saving time is faster. But I I also see that like actually the corporate pickup of new stuff is happening faster than like say five, ten years ago. Um it used to take it took used to take like a year or two or more, you know, or even cut a few years for like best practices to really me

Speaker 2: reach corporations because they kind of move slower. Um but um but I'm seeing that rapid uh that uptick go quicker. So

Speaker 3: Have you got a little bit theory as to what caused that? Is there a d what what's changed in the world such that corporations are able to move faster

Speaker 2: I think Python Bytes brings a lot of uh ooh, good, good. I like it. Um I have to

Speaker 1: credibility or information?

Speaker 2: Uh I think a little of both. I think it's um a common um Credibility and information, but also I th actually you know, it's as awful as it is, I think AI is bringing a lot, uh, because uh you know there's there's a lot of people that like to just do their job and don't they they use what they learned in college or something and and don't don't pick up a lot of new stuff um but um Uh and there's, you know, I was always reading blog posts and listening to podcasts and stuff, but some people don't do that. And so the people that just sort of Now they're they're asking chatbots and the chatbots are paying attention to stuff. So, um, you know, the the the the fear I get though

Speaker 2: is There's less and less of us blogging about it because there's no money in it anymore. So uh um um yeah, I I don't know where the new information is gonna come from

Speaker 3: Well it's gonna come from the slop output, so they'll be d they'll be feeding themselves. Well now

Speaker 1: I feel now I feel like you're tempting me, 'cause I've I've been on a little bit of a bugaboo about model collapse. Are are you familiar with that term in the academic papers around that?

Speaker 2: I can guess. Um

Speaker 1: basically you you train on AI slop and it just degrades and becomes you know, the variance shrinks so much. Um so there was an Oxford paper uh twenty twenty four showing both uh training it and the maths behind it that in the absence of other things, um, the models get worse over time. So then there's the argument of, okay, so we know that's the case. Maybe somehow the training gets better. Maybe synthetic data is better than we think it is. Maybe at scale those things don't apply. I mean, nobody knows, but I I'm in exactly in the same boat, right? Like w I could plug in things and the LM will spit out something I wrote or you wrote if we prompt it correctly. But like The search is dead, the business model 's dead, I don't feel any imperative to create that content, nor do many other people.

Speaker 1: So How can they how can they auto complete the next word when they're training on worse and worse data? I don't know.

Speaker 2: I don't maybe we go back to books? I don't know. Um

Speaker 1: Well, but books, I mean, don't get me started on book. Oh, you know Like Amazon, like some big percentage of it is just AI generated stuff there too. So I mean I I half wonder if the snapshot of like mid-2022 internet is like this canonical corpus. And then we like fill in recent things, but we rely on that corpus of largely human content for the variants that we need.

Speaker 2: I just I I think I just I have to be positive and I I I have optimism in the creativity of people and we'll come up with ways to spread creative people's ideas, regardless of the uh the global averager that is AI. Um So

Speaker 1: well, I I like um our previous guest, um Farhan who's who's younger, was we're talking about AI usage and he was mentioning how for him and uh he was making the distinction between people who love computer science and love to learn with AI are just super powered. But people who got a CS degree, you know, more for economic reasons or less for the love are less inspired to use AI and to keep up. But you you just said maybe something of the opposite. Maybe it's actually easier for people who aren't quite as in love with it to with AI.

Speaker 2: If if you didn't love coding, why would you get a C S degree? I just

Speaker 1: money

Speaker 3: Oh

Speaker 2: I don't buy it.

Speaker 3: You might you might fall out with uh of love with it during the course of getting the CS degree, right? That's what

Speaker 2: I'm

Speaker 1: like three, four years ago it was like, hey, you want six figures and you don't want to be a doctor? Like coding's the only game in town.

Speaker 2: Okay. Maybe it's okay to get rid of those people. Uh

Speaker 1: but uh

Speaker 2: but I think that there's I mean there's Just get you gotta find your passion somewhere. I don't know. I I I I couldn't work a job where I didn't enjoy it. Um I really enjoy what I do. So I don't know. I don't know. Uh but the And I think that like I'm writing a book, right? We're gonna talk about that later, but I'm not doing it to get money because like that's n that's like w I c if I wanted a few extra dollars, I could just go work at McDonald's up the street for a side job, I guess. That'd be uh more cost effective than uh than writing a book right now. Uh but but I'm gonna do it anyway. But anyway, uh I don't need to transition into that anymore, but the one thing I do Uh while we're talking about AI, I want to say I think that um

Speaker 2: one of the neat things is that uh people code is using c AI code assistance can go back to some of the old school good processes of come up with some ideas, generate a plan for how we're gonna do that, generate a few designs. Um look at alternative solutions. Should we use that database or a different database? Should we use that front end or a different front end? Come up, bounce around those ideas and what are the trade-offs and why. and then uh iteratively build it up and put in some uh top level API level testing for the system and uh build it up That's what we thought good practices were, but it was too expensive.

Speaker 2: So a lot of um a lot of, you know, scrum houses and stuff and a and and agile sl it was agile slop that was churning out garbage. And I I think it's cool that we can maybe do the old school good practices, but we can do it faster. It doesn't take months anymore. It takes Days or weeks to go through that whole cycle. So

Speaker 3: this this for me is definitely w one of the the things that have come out of the the new uh LLMs and that is people were now actually keen to write the specs that you've been asking them to write for you know so oh can we have feature X or what do you mean by feature out so how dare you ask me let's just implement it was the sort of attitude before Whereas now it's like, no, I will I will write it out. Not because I'm going to implement it, but because I'm going to feed it to a machine. But at least it's like, yes, the the explain what you're after before you tuck to the keyboard. That's progress.

Speaker 2: Exactly, but since it was so cheap to build the spec, um, we're not tied to it. In the in the past, one of the big mistakes was the spec was golden and we can't touch it. And um and now we can go, oh, well, we're like ten days into it and it sort of seems like a dumb idea now. Let's change direction. Um And and we didn't do that before. We would just be like, well, we spent like two months rewriting this thing. We're gonna have to build it now. Um and I I think that I think that the the we're actually getting the agile part the agility part of agile, I guess, maybe. Anyway, optimistic. Good, good, good, good, good. And I'm having fun

Speaker 2: still. Uh yeah, I I you know what, uh that's b sounds smug though. Uh as one of the what uh people working software that still is a job. Um I I think that I think I'm still having fun. That's good. So

Speaker 1: Well, we are. I mean, it's why we do this. Like, I think step back from the like uncertainty, like it's a really interesting time, right? Like with all the AI stuff and It's nice to kind of know a little bit what a little bit about what you're doing and then f see how AI fits in for work. And I don't know for me, like I work at an IDE company. We're still Sorting it out, I see lots. I mean it's it's more interesting than even I thought it would be without AI. More more uh tumultuous, but more interesting.

Speaker 2: Now, one of the things I just uh I actually heard this from uh a video clip from Ben Affleck, um, and I don't have a link. I just saw it on social media somewhere. Who's talking about AI, um, and having it be an averager. Like it it turns out garbage, but it's average garbage. Um and if you are if you're if you're new at something, like if I was gonna write some CSS, average is fine for me because I'm

Speaker 3: level. Uh

Speaker 2: yeah. Um so if I can have the AI bot generate average, uh that's way better than I can do by myself. So um For skills that I don't have, I'm gonna lean on it. Uh and uh and maybe that's okay. Um Yeah. And it's especially for projects that don't have a budget to hire experts in every field, why not? Um, so I don't know where I was going with that, but

Speaker 3: Just a general AI rambling that we have each week now.

Speaker 1: Yeah.

Speaker 2: Yeah. Um

Speaker 1: ,

Speaker 2: okay, one little more thing is we talked about the podcast a little bit. Um, I started blogging about code and podcasting and writing, uh not because I wanted to I mean the a little extra money is nice. But that is what um I was burning out in C S and and in coding and that involvement in the community is what turned it around and I and I still do it not because I'm still making money, I'm doing it because it's keeping me from burning out. So That's

Speaker 3: keeps keeps a connection, no? It can be quite isolated just sat at home behind your computer or sat at work at your computer.

Speaker 2: Exactly. And also I'm passionate about the crap. And A lot of the people I work with are not, and that is if you're in a setting where you really think you really want to love what you're doing, but you're not working with anybody that has any sort of uh uh like uh heated feelings about it, then you gotta find the people that do so that you can talk with them. So Anyway.

Speaker 1: Definitely. Well let's um we we we talked about books. Can we talk about lean test-driven development?

Speaker 2: Yeah. Um so the the book project I'm working on is uh lean TDD. And it is uh um actually inspired by a lot of the AI stuff. Um there's I'm gonna probably throw in some A on the I in there. There's no mention of AI in it right now. But I've I've got the first draft done. So lean test-driven development I was way back in the early 2000s. Uh a few books really helped me out. Um uh Pragmatic Programmer. Uh, and then there was a book called uh Lean Software Development. And um and that was that was great. Those two those two books are great. Um, especially for lean, uh the lean software development, especially the first actually the introduction. The introduction is all you need to read it, but like covers everything.

Speaker 1: I mean it's a lean, it's a lean book, right? Yeah.

Speaker 2: It no, it's pretty beefy, but that's the sort of the thing in the book industry is like, oh, your idea's only like forty pages? No, you're gonna have to make it bigger. Um, and they put there's a bunch of stuff in the back that I don't I maybe it works for some people, maybe it doesn't. And and to be fair They said that. They said the principles are what you need to know. The practices that we're going to fill out the last two-thirds of the book are m our interpretation of how you could fulfill the principles. So fair enough. Um and I like those, but I wanted to take that. So one of the one of the things that Lean gives you is an idea of how to anal analyze processes for waste. And waste being anything that doesn't directly add value to your customer. Not waste is in garbage, but waste is in like

Speaker 2: like tests. I think all tests are waste, which is gonna tick a lot of people off. But that's true. Does a customer really care how you're testing? Mm, I don't know. Um, but Think of it as like would if you doubled it. If I doubled the number of tests, it's if the the product's already perfect and I spent ten thousand dollars more on testing Do you want me to? And they're like, no, it it's already good. So uh incremental value sort of a thing. Um whereas like an extra feature, value. uh an extra test if it doesn't test anything I care about, not value. So anyway.

Speaker 3: I'm chafing at the bit there, Brian. I've got to interrupt you. I'm chafing at the bit because like If I buy um, you know, I buy a product and two products that look identical on the shelf, but one has come from a a a a reputable factor. fabrica for reptile factory who's got quality control and all those things, it's gonna be more reliable, it's gonna be it's gonna last longer, it's gonna be something I can put my trust in and rely on. Whereas the the thing that was put together in a sloppy manner is probably gonna break within, you know, a small period of time and it'll b break at a crucial moment. And software testing's that kind of quality control, right? It improves It gives you a better product in that sense. So why is a customer mindset? Yes.

Speaker 2: Yes, uh those things, those qualities that you said that that it's gonna it's not gonna break. Um the things that you advertise is doing, it's actually gonna do those things. That's the actual value. How we get there is we put in place testing. Um So I guess what I'm saying is like the uh uh we used to say it's cheaper just to have people manually test stuff than to automate it. Now the cycles are so fast that we can't rely on that because I want to be able to change a feature and ship it today. Um um so we have to have automated tests. But it isn't the automated test that's the value. It's the the c the value that those tests create, I guess. Um it lets like management activities. Like that's one of the things that Lean Software Development throws in there, and I think it's hilarious, um, is all management activities waste.

Speaker 2: Um it's like

Speaker 3: well the benefits of the world unite.

Speaker 2: I was a manager for ten years and um and I got I mean there's a lot of activity that we do that is just dumb, but that's not what it's talking about. It's talking about that There's there's essential work that you have to be done. Oh, I guess think about it in a s silly example. I'm gonna cut circles out of a piece of paper. Um if I slow down and and like do the circles really close together, I can reduce the number of wasted paper so I can get the most circles out of a piece of paper. But I have to slow down to do it. So is it worth it? You have to do trade-offs. Do we do I slow down or do I speed up? And it there's there's either wasted time or wasted paper. And you have to do those trade offs. And that's where testing and a lot of other stuff comes in.

Speaker 3: Almost everything, right?

Speaker 2: Yeah, there's trade-offs everywhere. So um really what I did is I'm using all those lean principles and focusing on the test-driven development process. and looking at where the value comes from. And I think the real value in a lot of automated tests are in the customer facing tests. The does this feature actually do what I want it to do? Those are valuable tests. So those are the ones we keep. The unit test, does it do the thing that the developer wanted it to do? Uh only if the customer cares about it. If it's just that a a developer thinks that a unit should do this because you they're gonna reuse the the something on a new product. Less valuable. Um those sorts of things. So

Speaker 1: it's still value, right? I gotta push back slightly, right? Because there's also the value to the developer, right? Like I don't feel comfortable hopping into a new code base with no tests. Right. And I'm sure you you talked about this, right? There's some like what but I we can't have infinite tests, but like I want to have some tests even if the customer never sees them just so I can move faster without breaking stuff inadvertently all the time.

Speaker 2: Well I I mean I that's why I mean my spend my day half more with more than half my day writing tests. Um So I I do find the value in tests, but it's the higher level ones. I think um the API level tests and the component level tests are way more valuable than uh do my getters and setters work for instance.

Speaker 1: I think you've seen a lot of time spent on unit tests. Like that's what I'm picking up, which is fair, right? Like maybe wasted time.

Speaker 2: I th I think I'm I'm I'm le I'm swinging the other direction because the test pyramid did so much damage. Um and it and Because the test pyramid said gave the unit developers the permission to focus on unit tests, and the rest of the pyramid is somebody else's problem. Um and and there is and in most companies there's nobody else to take the rest of the problem. Um there's no dedicated QA team anymore. Uh there's who's gonna write the component tests. It's it's a bunch of people building trying to build houses with very thoroughly tested nails and pieces of wood, and nobody to make sure that the house is to spec.

Speaker 2: Um a and that's just the truth of it. And that's where we see like we still see a lot of people um focusing too much on does my little widget work? And I'm not and I and and there's there's a I write a lot of unit tests too, but it's focused ones of like This algorithmic bit that's confusing, let's throw tests around it to make sure that it it always works the way we think it does. Or if we're gonna throw a corner case in because we need it or there's a bug fix, Put a test around it so that nobody looks at it and goes, Oh, this is a weird algorithmic our algorithmic bit in the middle here that that it'd be a lot faster if we took that out. But if there's a reason for it there, throw a test around it so that it doesn't break later.

Speaker 3: I use um unit tests as kind of um scaffolding for while I'm developing code. quite often. So you know, I'll know I'll I'll have a rough idea of what I need to build and I'll have broken it down into logical steps. And I need a test for step one. And okay, I've got step one's passing. I've got step built one one build. And that test remains useful while I'm building step two and step three and step four, all the way to the end. But kind of once I've built the feature and I've got a test around the whole feature, like an integration test around the whole feature. It's questionable whether I need to maintain those unit tests or and sometimes they can become a barrier because later on you want to come back and refactor the that that into implementation. And you're kind of scared to because you've got all these tests that you're gonna throw it away. It's hang on, but they were just there for scaffolding while I was building it. They're not really they're not adding the value as you're saying.

Speaker 2: Well that's where the big the the rule of thumb is keep tests that test behavior, throwaway tests that test implementation.

Speaker 3: Yeah, pretty much

Speaker 2: Um because the scaffolding around your implementation doesn't help you if you try to dig um so that like the a lot of the the the thing with test driven development was red-green refactor. But is the unit test again in the way of refactoring?

Speaker 3: Yeah. Exactly.

Speaker 2: Um so if a unit test if the behavior stays working and your unit test breaks, then it's the pro the problem is you've got a unit test that shouldn't be there. Um Uh so that and there's I've seen too many projects not change things because they don't want to Change a bunch of unit tests.

Speaker 3: Yeah, exactly. Or we can't change that, the tests will break. Right. Yeah, no, no, no, no, no, no, no. Yeah. Okay, good. So I've got what so let's tie back to the AI question because I think test driven development sort of almost comes back into its own if you've got a you know a clawed code or a copilot CLI or a Gemini CLI or whatever your your favorite one is. Because you need su the you need the agent that's doing its thing to have some way of knowing if it's If it's successful and without tests, mm

Speaker 2: exactly

Speaker 3: gonna eyeball it and the last thing you want to trust is an L L M eyeballing it.

Speaker 2: So what are you so you want tests that you're actually willing to review? So just like you you'd have it like maybe you'd work with Claude to uh come up with your your uh your design plan you'd review it to make sure that you agree with it what what it's gonna do before you build it. Same with your tests. If you're not willing to review the test then you shouldn't have the AI build it. Um whereas um and I think at the high level API level test is is where we I'm I'm willing to review those tests to make sure that the product I'm building actually does the thing I want it to. But if it's got some weird funky implementation down at the bottom, I'm not gonna review the unit test for that. Um so uh I wouldn't even know what to review.

Speaker 2: And that's that's the that's the hard part as well, even with people, like not just Not just AI stuff, but people. If you're if you're how do you review somebody else's unit tests? Um, whereas you can review the API level level test pretty easy. You can go, oh yeah, that's testing the behavior of our system. Uh whereas lower level component lower level stuff is harder to review somebody else's project, I guess.

Speaker 3: Re reading code, reading tests, so that you understand them, so that you can give them a proper review. That's hard work, right? It's the first thing to acknowledge is this is not going to be easy. You're not gonna get you're not gonna glance at the test, suddenly understand them and be able to say whether they work or not. You've got to go through them

Speaker 2: well, hopefully. I mean like you should you should try to get if you ev you should write readable tests and if you're gonna have somebody else or some other bot write it, they need to be readable tests. Yeah, okay. I I think that's a nice thing to um aim for certainly.

Speaker 1: If we can that's um oh go ahead.

Speaker 2: That that ties back to the first question of the what I do for my uh job. Right now, uh I'm in a role to try to make sure all of the System level tests are at a highly readable level so that everybody in the project can read them. So

Speaker 1: Did I I feel like when I asked I started off asking about Python ecosystem in 2024 you mentioned UV. Did we talk about 2025 and 2026? Did we get those in or did you have other things you wanted to mention there?

Speaker 2: Just I think I think we're gonna see the the m bigger shift of just m more people everybody shifting to UV whereas whereas uh and PIP will be the corner case, uh even in corporation settings. And the and then Not in I think twenty twenty five was the year of people uh gener fib coding and I think twenty twenty six is people g actually using it as an assistant to make developers um Uh, do the right thing. Maybe

Speaker 1: we'll see how the business model holds up too.

Speaker 2: Yeah. Well, um, I have no idea about that one. That one just seems crazy. I don't I don't know how you have a company valued so largely so large that it isn't making enough money to cover its bills. That's Whatever.

Speaker 1: Well, I mean to put my jet brains hat on and think about what I can say publicly. I think there was a sense of a lot of companies were like, oh, we're gonna build tools on top of LLMs and we're gonna make money in a you know, extra money, whereas now the sense is no just to like keep to Be competitive, we have to integrate AI, but we have our existing business model. It's not that AI is like another chunk of revenue. It's just a necessary piece of the puzzle of our offering.

Speaker 2: Well, if you're already charging every developer on the planet $20 a month, um, and some of them $200 a month, how do you make more money? I don't know. Um

Speaker 1: Ads. That's that's the joke that was going around, right? Like they finally got AGI ad generated income.

Speaker 2: I'm gonna put ads in your code that I generate. By the way, check out Pepsi Uh no thanks. You're

Speaker 3: coke on him.

Speaker 1: I'm going back mem oh sorry, Carlton, you look like you wanted to say something.

Speaker 3: Well no, I mean it I was just gonna ask about the yeah the because Lean TDD is your new book, but we should talk about the old book. I I was doom thought thinking to myself, oh we should talk about the second edition, but and then I thought that was just last year, and then I looked It was actually twenty twenty two and I was like, oh wow, how has it been three years since the second edition of uh

Speaker 1: four years? Well

Speaker 3: four years now.

Speaker 2: Has it been four years?

Speaker 1: Well twenty twenty-six, so depends. Yeah, how you counting it.

Speaker 2: So that's um Python testing with PyTest is what we're talking about. And um the and it's it's um it's like It's actually still doing okay. It's um the it's down probably with the rest of the industry, um, as far as sales go. But I I keep up on it and keep I I keep getting questions. So one of the great things about um I guess I don't know, was it last year? Maybe it was last year or year before. Uh anyway, um I think it was 2024 where I went through the whole book and did the course. So there's a the complete pie test course, just I walk through the entire thing. And it's there's a lot because it's uh it's It's a book. Um it's not a big book, but to to go to walk through everything is takes a while.

Speaker 2: Um, and and I think I did a decent job that um especially with the second edition of of keeping it to things that are gonna stay relevant even in future editions. So Uh I think the book is still valuable now. The the the I I am I d I don't know if I'll do a third edition. The the only problem right now isn't the content of how to use PyTest. The problem right now is that the project that I used there, it it was it uses dependencies. So those dependencies are out of date. And I have to go I should go back and uh update the project too. with the new um updates from the dependencies. That that would probably be the if I if I were to do a third edition, um the main thing I would do is take out the dependencies in the project.

Speaker 2: Um and uh just Just do it, uh not have any dependencies so that I don't I have complete control over it and it'll always work. And just do stuff I see

Speaker 3: Will nodding in the background now he's sort of waiting for the biggest. Oh I'm just I'm

Speaker 1: yeah I'm not I I feel your pain. I feel your pain.

Speaker 2: Uh and the dependencies are like not big deals. Like I use what? I use um a uh a a database layer. Um the the that it's just a silly it's like mini D B or I can't even remember what I use. Tiny D B, that's it. Um and it's uh it's a it's like Mongo, but like small scale. It's a single file uh document database. And actually for it's kind of fun if if you're using it, but um But it's it's got an old version in there. And if I would uh if I would redo it, I'd probably just go with like, what's that, the built-in SQL? Uh SQL eight? Yeah. I probably just have SQLite because that's that's always going to be supported. Um and then uh

Speaker 2: and then I wasn't I used like I think I used click in the first edition and then typer for the CLI interface. And um again, both of those are great projects, but they're dependencies. So I'd probably just re-implement it in um in whatever the yeah, arc bars. That's it. Um, and I'm also better at I mean I'm I'm better at testing with Arc Parse applications right now, uh, than I used than I was when I did the 20 the second edition, so. Um but um I still n I it's it was a good good idea to write that book. Um And I I'm I'm glad that a lot of people have gotten value from it. So

Speaker 3: Yeah. It's the absolute cornerstone I think is, you know, it it You think through the, you know, the classic books, the fluent Python's and things in, you know, the PyTest book the PyTest book is gonna be done there.

Speaker 1: You don't have competition, which means you nailed it and maybe it's a s and it and we know it's not a small area, right? Like everyone has to I was like, that's always the thing. You're like, is it is it a tiny pond or am I a big fish, right? It's yeah, a bit of both, I'd say.

Speaker 2: One of the core developers did write a competing book, um, and that you don't remember it is a good a good sign for me. Um

Speaker 3: seen 'em off.

Speaker 1: Well, uh so let's see, we're We're we're coming up a little bit on time. I want to mention projects and books, but I want to get your t hot take on what do you see as the Python web s framework space because you're not a biased insider. You know, so there's Django, there's Fast, there's Flask, there's Django.

Speaker 2: I think I'm too much of an outsider. Um well

Speaker 1: I'm still curious what you think. What what do you make of what's going on?

Speaker 2: Well, I like that okay. I I have a project that's that's that I'm a side project that's using Django. Um and so I'm hope I'm glad that Django's staying is keeping up to date. And I I actually think Django's a safe bet now. Um it just looks like you you don't have it's kind of you don't have to defend yourself if you're gonna say I'm gonna use Django or Fast API. Um everything else I think you'd have to defend yourself as to why you were using using that. Um, but that's just it. Uh um I I do th it's I think it's interesting that Michael's rewriting a bunch of his stuff in court instead of something else. Uh so

Speaker 3: Michael about that. Like the the the academic, he's got that the free the free reign to do what interests him.

Speaker 2: Yeah.

Speaker 1: PhD is Carlton, right? PhD's gone wild. This is a problem.

Speaker 3: Something like that. Uh

Speaker 1: should we mention oh sorry go ahead.

Speaker 2: But I'm I'm nobody should take my advice for it because I'm not really a web uh web developer, so

Speaker 3: I do want to ask, how is your Django project going? Because last time you came on the show you just started and you were like still exploring your way in Django and that was a little while ago. So you found your f found your feet and all happy?

Speaker 2: No, no, no. It's still in the concept phase. Um, so uh it's a perpetual concept project. Uh but uh

Speaker 1: you could spec it out with AI and

Speaker 2: That's the that's the plan. Um to I mean Django's great for

Speaker 1: it, right? That that's the thing I always have to remember with my blinders of Python Django, like That's as good as AI gets because it's so well documented. Both are so well documented, right? Some other fringe language or framework, like you're not gonna get as good results.

Speaker 2: It's kind of like the book. So the Lean T D book is the book I've been wanting to write for twenty years. Um and so I'm Finally doing it so that it's out of my head and it and it can it's living rent free and it needs to pay its own way. Um And this side project that I want to do is the same sort of thing. It's a project I've wanted to do for probably ten years and I want to get it done so that it 's And it just it doesn't have to make me a ton of money, but it pro if I need to either see that it sinks or swims. And by swimming it just has to pay its own like hosting fees.

Speaker 3: Yeah.

Speaker 2: Exactly. $20 a year for like or whatever for its uh URL renewal. Um and that's about it. Um but yeah. Um yeah, I'm a newbie there. Um we are running short on time. What do we do next?

Speaker 1: Well, so we we've gotten the habit of mentioning project in a book, which We sprung on you last minute, so Carlton and I are happy to go and if you feel inspired, um I'll st I'll start. So projects, I'm gonna shout out DjangoPackages. org, which is not a new project that Jeff Triplett has taken over, but he just r uh re-redesigned the whole thing. So this is like the best place to go if you want to search through the thousands of Django uh third party packages. And so the new redesign is really nice. He used AI. He's talking, he's talked about it. Um definitely check it out. Give it a new look. Carlton, you have one.

Speaker 3: Okay, so the package I want to talk about is called Django Message Spec Field. So it's a it's a JSON field subclass that uses the message spec serialization um f tool or library um to impose um schemas and validation on the data you store in a JSON field. And what I like about it, there's there's several of these um packages out there di that using different options. But what I like is it's another example of People in the Django community jumping onto these newer serialization options rather than you know just rest framework serializers that we've had forever and a day So there's a Pydantic version, now there's a message spec version. And I think the more people in the Django community start using these things, the more they'll go, oh wow, this is actually a step up from what we're used to. So um Django message spec field is my recommendation for the week.

Speaker 1: Well you I get you're used to doing yeah recommending things. Do you have something top of mind?

Speaker 2: Well one of the things I've been using a lot lately was is kind of an old tool is uh is from uh uh Rough. Um so it's another astral tool.

Speaker 1: Yeah, I was gonna ask you about that actually.

Speaker 2: Um but the the uh one of the the the check stuff is amazing. So uh we like I mean we like linters in in software uh to to check stuff. And linters really are just um static analysis tools. Um so static analysis tools are very powerful as a starting point before you even run things to test them. But um the rough checks are amazingly thorough. It's not just it's not just uh simple things like, you know Did you you did you know if you use a variable or you have a you have an import that you're not using, it'll check for that. But there's so many checks. So you should go check out the rules at um at uh at Astral for the rough rules. And and there's a lot of stuff you can turn on.

Speaker 2: There's Bugbear. There's uh there's even I've been using a a PyTest uh uh flake eight pie test extension that you can turn you can just turn it on with rough check. Um it's already built in. It's it's amazing. So Uh if you if you even if you've played with Rough before, go check it out. It's keeps keeps getting better. So

Speaker 1: Books. Carlton, do you wanna go first on books?

Speaker 3: Yeah, I'll go first. So I'm gonna recommend um The Python Polar's the definitive guide. So Polars is like a a a data frame library, a bit like Pandas, right? But it's Polar.

Speaker 1: It's a new hotness. Yeah.

Speaker 3: Yeah, it's the new hotness. It's so it's written in Rust and it's got Python bindings around it and it's got an expressive lazy API and all sorts of things. And so it's worth investigating. Um Pandas has got a new version coming out and Pandas is not by any mean d done and dusted. But Polas is, you know, another thing in that space. And it's a good book. Um It introduces everything very well and I it's gonna live on my desk for a long time now because it's got a very good reference section and it kind of as you d dig into it explains the kind of methods and then you're gonna keep it on the desk to dig into the details as you need them as you're using them. So Um Py Python Polar's the definitive guide.

Speaker 1: Okay. I will mention not a programming book, but relevant, which is How to Hide an Empire, which I actually read several years ago and I'm rereading. So it's a history of the Greater United States So without getting too political, uh the US has a long history of acting like an empire. And this book dives into that and talks about disabusing common myths that Americans uh tell ourselves about what we're doing and it's timely unfortunately. So really well really well written. And I don't say that lightly. I'm a super snob with writing and this is excellent. So strongly recommend it.

Speaker 2: Okay, another timely book, and and I am getting political, um, is um is the the Little Brother series. Um or it there's a series uh called that starts with Little Brother by Corey Doctorow. And it's an excellent series that uh yeah, talks about in a hypothetical world in America that just sort of looks predictive. It it was I I listened to the series on audiobook and it was excellent.

Speaker 3: So L little brother must be a play on big the idea of Big Brother, right? Yeah. Yeah, okay.

Speaker 2: Um the other and it's it's uh targeted towards CS people, so like or like there's a lot of programmer the the heroes are all programmers.

Speaker 1: Which is cool. Good one. As it should be, right?

Speaker 2: Yeah. Um another one uh that I just sorry, we're only just supposed to do one, but

Speaker 3: No, you can do this.

Speaker 2: Uh my daughter had to had to read a book, she's having to read a book for um uh for English called They're There by Tommy Orange.

Speaker 1: Oh yeah, yeah, yeah.

Speaker 2: And I I listened to the audiobook for that and it was phenomenally um it was very hard. There's a lot of it's not an easy thing to get through because it's talking about um the way we've uh treated the native population in America. Um but from their perspective kind of um yeah. So it's but it's it's very very relevant as well and I I highly recommend it.

Speaker 1: I've heard great things about that. It's on my list, so I'll have to push it up.

Speaker 2: Uh yeah, those those are my recommendations.

Speaker 1: Any things you wanted to mention we didn't ask you about, you want to shout out. I mean I of course people I think will have links to all your various projects, podcasts, and books, but anything else?

Speaker 2: Uh one of the th I just reminder for people to have fun. Um I I assume people got into software to have fun and not just to make money. So I think just find out what you're still having fun with and double down on that.

Speaker 3: Yeah, there's a lot in that. That's great advice.

Speaker 1: Well, thank you for taking the time. Thank you for waking up early to accommodate our schedule. It's very early for you.

Speaker 2: Yeah, and I now I get to go to work.

Speaker 1: Yeah, yeah. Well, same. Carlton's done.

Speaker 3: He's gonna go make dinner.

Speaker 1: Yeah.

Speaker 2: So where okay, quickly, where's everybody from? I can't remember.

Speaker 3: Well, I'm from Britain, but I'm based in Spain, so I'm, you know, quite a few hours. Yeah. It's getting dark now and uh well, it's been dark all day 'cause the wet weather's miserable, but you know.

Speaker 2: Okay. And I'm in Oregon. And where's you?

Speaker 1: I'm based in Boston, but I'm from Vermont. Big difference.

Speaker 2: Okay, but you're in Boston now. I I love Boston. So

Speaker 1: Yeah, yeah, I like Boston. It's not Vermont, but as US cities goes, it's where I've decided to hang my hat. So

Speaker 3: I'm gonna get you a t-shirt well. It's not Vermont.

Speaker 2: To be clear, I tried to see Boston and I couldn't find a parking spot. So I had to move on.

Speaker 1: Oh yeah, well it's it's uh it's the most European of uh American cities, so you shouldn't have a car. You gotta walk.

Speaker 2: That's what I was told afterwards. They're like, why did you try to take a d car into Boston?

Speaker 1: Yeah, and Boston drivers, th it's like the aggressiveness of New York with a Byzantine one-way streets that are not laid out in a grid. So if you just see Boston through drivers You're not gonna like it.

Speaker 2: Yeah. Well I'm from the West Coast and the weather you can't you can't get anywhere without a car over here, so

Speaker 1: Yeah. Yeah, try it again without a car. I think it's very w you can walk the whole city in a day. Carlton came to visit. We walked a lot of it. So

Speaker 2: well I also want to thank you guys for keeping this up. I really enjoy the uh Django Chat podcast and it was it was I always miss it when it's on a hiatus, so

Speaker 3: Oh it's just over the summer, you know. We have to we have to keep our energy up. Yes.

Speaker 2: I appreciate it. I understand that.

Speaker 1: Yeah. Well, again, thank you for coming on. We are DjangoChat. com. We are on our YouTube channel. And we'll see everyone next time. Bye-bye.

Speaker 2: See you next time. Bye-bye.