WEBVTT 00:00:00.020 --> 00:00:04.920 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. 00:00:05.360 --> 00:00:10.240 This is episode 489, recorded July 21st, 2026. 00:00:10.820 --> 00:00:11.860 I'm Calvin Hendryx-Parker. 00:00:12.200 --> 00:00:12.800 And I'm Michael Kennedy. 00:00:13.220 --> 00:00:15.420 Hey, Michael. Welcome. Good to see you. 00:00:16.500 --> 00:00:20.500 We want to make sure you all recognize our sponsorships of the show. 00:00:20.640 --> 00:00:23.380 So thanks to Michael and the courses over at Talk Python. 00:00:23.500 --> 00:00:25.660 Go check those out if you head over. 00:00:25.920 --> 00:00:28.180 And he's got tons of new stuff he's been adding in there. 00:00:28.220 --> 00:00:29.620 And I hear there's more on the way. 00:00:30.180 --> 00:00:33.300 and then check out the fine folks over at Six Feet Up. 00:00:33.600 --> 00:00:35.340 So I'm co-founder and CTO of Six Feet Up 00:00:35.700 --> 00:00:39.040 and we do some amazing consulting to solve hard problems. 00:00:39.180 --> 00:00:39.900 We love using Python. 00:00:40.160 --> 00:00:42.080 I've been doing this for 27 years 00:00:42.680 --> 00:00:44.000 as part of that agency and I love it. 00:00:44.680 --> 00:00:48.060 If you wanna connect with Michael and I between the shows, 00:00:48.160 --> 00:00:49.500 you can find us on all the socials. 00:00:49.600 --> 00:00:52.120 We're on Mastodon, Bluesky, X, LinkedIn. 00:00:52.800 --> 00:00:55.260 And then the show has also got links in the show notes 00:00:55.460 --> 00:00:58.640 for the shows, Mastodon, Bluesky, and X. 00:00:58.920 --> 00:01:03.420 If you want to watch live, you can always catch us generally Tuesday mornings by time, 00:01:03.910 --> 00:01:05.740 very early mornings for Michael's time. 00:01:06.250 --> 00:01:11.100 So 7 a.m. Pacific on pythonbytes.fm/live to be part of the audience. 00:01:11.980 --> 00:01:15.480 Sometimes we'll get questions in there and we'll pop them onto the show and you can get 00:01:15.480 --> 00:01:16.980 them answered right away. 00:01:17.700 --> 00:01:19.520 Kind of real time feedback to the episode. 00:01:20.360 --> 00:01:23.460 Older versions are also available there if you want to watch the live stream and see our 00:01:23.720 --> 00:01:27.100 shiny faces as we go through and talk about the news of the day. 00:01:27.780 --> 00:01:31.960 Speaking of the news, Michael, I think you're going to kick it off with the first article today. 00:01:32.290 --> 00:01:35.580 I am, but let me do a little follow-up to what you just said, actually, 00:01:35.670 --> 00:01:37.600 which is not normally something that deserves follow-up. 00:01:38.220 --> 00:01:41.180 But, you know, last time, a couple times ago, I talked about Hermes. 00:01:41.580 --> 00:01:41.840 Yeah. 00:01:42.160 --> 00:01:43.340 What a cool little thing. 00:01:43.440 --> 00:01:45.300 I've been getting more and more done with it. 00:01:45.600 --> 00:01:50.520 One of the things I did over the weekend was I've set up an automation 00:01:50.960 --> 00:01:54.640 such that Hermes can use the website to manage the YouTube channel. 00:01:55.080 --> 00:01:56.420 And then I set up a nightly job. 00:01:56.520 --> 00:02:06.440 So every night, as much credits as I can get for API interactions from YouTube, it will automatically go back and update the back catalog like 10 or 20 shows at a time. 00:02:06.900 --> 00:02:10.259 And so it's on this cool, cool thing. 00:02:10.360 --> 00:02:17.400 So the live back catalog YouTube stuff is getting better and better because it happens as I sleep like it should. 00:02:17.560 --> 00:02:18.120 I love that. 00:02:18.440 --> 00:02:21.200 Getting the richer show notes, etc. put onto there. 00:02:21.420 --> 00:02:24.800 I like the fact we can use this to make the world a better place. 00:02:25.180 --> 00:02:25.580 Yeah, exactly. 00:02:25.780 --> 00:02:30.960 Like it's just everybody gets, you know, links and stuff in there in the videos if they watch it. 00:02:31.940 --> 00:02:33.220 And how do you get it? 00:02:33.380 --> 00:02:36.180 Well, is it a JSON API or something else? 00:02:36.340 --> 00:02:36.800 We don't know. 00:02:36.850 --> 00:02:39.760 So I want to talk about Django or JSON. 00:02:40.080 --> 00:02:41.960 Is it ORJSON or ORJSON? 00:02:42.280 --> 00:02:43.480 It's probably ORJSON. 00:02:43.500 --> 00:02:44.740 Hi, OR is my guess. 00:02:44.910 --> 00:02:46.340 Let's go with OR. 00:02:46.550 --> 00:02:48.180 I agree because ORJSON is weird. 00:02:48.460 --> 00:02:48.880 ORJSON? 00:02:49.280 --> 00:02:49.380 OR? 00:02:49.680 --> 00:02:50.000 ORJSON. 00:02:50.060 --> 00:02:50.580 ORJSON? 00:02:50.690 --> 00:02:51.000 I don't know. 00:02:51.600 --> 00:02:51.700 Yeah. 00:02:51.810 --> 00:02:54.360 So I want to talk about this project from Adam Johnson. 00:02:54.420 --> 00:02:56.720 So we have a couple of Django topics. 00:02:57.270 --> 00:02:59.800 This one is a Django topic, but it also goes more broadly. 00:03:00.260 --> 00:03:03.800 So there's kind of a multi-level thing going on here. 00:03:03.850 --> 00:03:06.380 Not the marketing badness, but just multiple uses. 00:03:07.220 --> 00:03:14.360 So this is a project that Adam created so that you can change Django's response model. 00:03:14.360 --> 00:03:21.860 So apparently the way Django uses JSON or generates JSON responses happens in a bunch of different ways. 00:03:22.440 --> 00:03:25.840 So it says there's a library called ORJSON. 00:03:26.240 --> 00:03:28.800 And somewhere it says, yeah, here we go. 00:03:28.860 --> 00:03:31.720 It says, compared to Python's built-in JSON, 00:03:32.140 --> 00:03:37.520 it boasts 10x faster serialization and two times faster deserialization. 00:03:37.820 --> 00:03:41.320 And I believe it is a little bit more forgiving of date times and stuff. 00:03:41.320 --> 00:03:43.040 It has like default conversions, 00:03:43.310 --> 00:03:46.400 whereas if you've ever tried to serialize certain things, it's like, nope. 00:03:46.600 --> 00:03:47.220 Sounds like a win. 00:03:48.440 --> 00:03:49.400 I know it does. 00:03:49.440 --> 00:03:52.900 Like I couldn't possibly figure out a way to represent time. 00:03:53.760 --> 00:03:56.480 What a weird, this is a rare concept we don't normally encounter. 00:03:57.660 --> 00:03:59.320 So this handles some of those things as well. 00:03:59.360 --> 00:04:01.260 So there are a couple of reasons that you might play with it, 00:04:01.940 --> 00:04:02.740 but it is a little bit different. 00:04:02.780 --> 00:04:04.060 So be a bit careful. 00:04:04.460 --> 00:04:05.040 So, all right. 00:04:05.080 --> 00:04:07.260 So the idea is that there's a bunch of different places, 00:04:07.580 --> 00:04:10.400 like such a great library, but adopting it isn't easy 00:04:10.500 --> 00:04:13.840 when your framework uses JSON in multiple different parts, 00:04:14.280 --> 00:04:14.800 in different places. 00:04:15.300 --> 00:04:22.520 So Adam introduces Django ORJSON, which provides a bunch of replacements and you just plug it in, right? 00:04:22.720 --> 00:04:26.600 So import JSON response and you can return that directly, which is cool. 00:04:27.040 --> 00:04:31.760 There's test capabilities loaded up in a template and so on. 00:04:32.060 --> 00:04:36.520 After seeing the initial proposal, Django ORJSON, 00:04:36.920 --> 00:04:41.220 Paulo, who was recently on Talk Python to talk about maintainer burden and AI, 00:04:41.400 --> 00:04:43.700 coming back to that at the end as well, or later, 00:04:44.020 --> 00:04:47.580 decided to push for the addition of ORJSON support in Django itself 00:04:48.140 --> 00:04:51.380 under a new feature called pluggable JSON serialization backend, 00:04:51.680 --> 00:04:52.980 which I think is pretty cool. 00:04:53.200 --> 00:04:53.820 I'm all for it. 00:04:54.020 --> 00:04:54.900 Yeah, it's nice, right? 00:04:55.040 --> 00:04:56.060 Like, why not make that an option? 00:04:56.440 --> 00:04:56.720 Yeah, totally. 00:04:57.100 --> 00:04:58.780 It's like saying, nah, that Pydantic thing, 00:04:59.120 --> 00:05:00.040 probably a flash in the pan. 00:05:00.050 --> 00:05:01.360 We don't need to really worry about that. 00:05:01.660 --> 00:05:03.380 Let's go ask, did you get to try it out? 00:05:03.920 --> 00:05:04.820 You've got a lot of data. 00:05:05.180 --> 00:05:05.440 Yes. 00:05:06.020 --> 00:05:08.980 And so I'm like, well, let me just try this. 00:05:09.180 --> 00:05:16.180 And one of the things that's really cool is with Claude Code and other things, you can say, here is a proposal for how to do this for JSON. 00:05:16.680 --> 00:05:20.700 How would I do this for Flask and Cort, where I'm running my apps? 00:05:21.120 --> 00:05:25.140 And can you tell me the areas where it might be a benefit or not so much a benefit? 00:05:25.500 --> 00:05:37.500 Not only did I get a little summary for how that might go, it's like, and I set up some test performance runs, and it turns out that you get four times performance boost, not 10 times performance boost. 00:05:37.560 --> 00:05:44.280 and yeah that's not bad no it's not too bad but i put that actually the reason like a little bit 00:05:44.280 --> 00:05:51.480 of that analysis into the show notes and it turns out that if you have large json documents with a 00:05:52.110 --> 00:05:58.420 few fields then it doesn't give you a big boost if you have a very fine-grained json document with 00:05:58.560 --> 00:06:03.620 lots of small fields apparently that's where this performance starts to pay off and i happen to have 00:06:03.580 --> 00:06:06.200 like big chunky JSON, I guess is what I got. 00:06:06.200 --> 00:06:06.520 I don't know. 00:06:06.520 --> 00:06:10.760 It's got things like 100K of transcripts in a response, 00:06:11.140 --> 00:06:14.040 you know, not, and it's structured as a giant piece of text. 00:06:14.180 --> 00:06:19.820 It's not necessarily like subtitle text second and so on. 00:06:20.100 --> 00:06:21.440 So that's interesting. 00:06:21.780 --> 00:06:24.560 And it said, look, it could help your MCP server, 00:06:24.640 --> 00:06:26.800 but the traffic on the MCP server is not that high. 00:06:27.640 --> 00:06:28.280 You swap it out, 00:06:28.480 --> 00:06:32.520 you'd probably save 0.119 milliseconds of requests. 00:06:33.140 --> 00:06:35.580 And for a response that takes 1.1 milliseconds, 00:06:36.620 --> 00:06:37.760 you really wouldn't mess with it? 00:06:38.340 --> 00:06:40.660 I decided no, which I thought was kind of interesting 00:06:40.840 --> 00:06:41.460 in the first place. 00:06:41.640 --> 00:06:43.960 Like, you try it out, you're like, oh, cool idea. 00:06:44.360 --> 00:06:45.320 Just not for my use case. 00:06:45.580 --> 00:06:46.840 Most of my stuff is RSS. 00:06:47.580 --> 00:06:48.380 It's HTML. 00:06:48.720 --> 00:06:49.640 It's like not that much JSON. 00:06:50.420 --> 00:06:52.560 But I do think for the right use case, 00:06:52.640 --> 00:06:53.540 it would be really powerful. 00:06:53.780 --> 00:06:56.220 I mean, are there any compatibility caveats 00:06:56.420 --> 00:06:57.540 that people need to be aware of here? 00:06:57.800 --> 00:07:02.099 There are some minor ones about how it handles certain things 00:07:02.120 --> 00:07:03.640 that either can't be serialized 00:07:03.860 --> 00:07:06.180 or if you don't specify how to serialize them, 00:07:06.320 --> 00:07:08.460 like for example, date times and stuff like that. 00:07:08.640 --> 00:07:09.960 Which everyone loves dealing with date times. 00:07:10.640 --> 00:07:11.100 It's our favorite. 00:07:11.240 --> 00:07:11.400 Yeah. 00:07:12.600 --> 00:07:14.180 Can we put some time zones in there please? 00:07:14.680 --> 00:07:15.520 Yeah, yes. 00:07:16.700 --> 00:07:17.700 All right, over to you. 00:07:17.800 --> 00:07:18.440 Yeah, very cool. 00:07:18.580 --> 00:07:20.020 Well, mine's also performance related 00:07:20.980 --> 00:07:22.620 and I think it'll dovetail nicely 00:07:22.860 --> 00:07:24.240 into what you just mentioned here. 00:07:24.700 --> 00:07:28.060 Speaking of performance and JSON and evaluations, 00:07:28.300 --> 00:07:29.940 I think one of the things that has been nice 00:07:30.000 --> 00:07:31.980 about using these AI agents, like you just mentioned, 00:07:32.120 --> 00:07:38.460 you can put it on a mission to go try some hypotheses and some theories and etc. This is a 00:07:38.660 --> 00:07:46.420 article from Peter Mengson who revits a one from 2017. So this is actually the original performance 00:07:47.020 --> 00:07:53.000 article he did around fastest Redis configurations for Django. So a lot of folks just use the default 00:07:53.120 --> 00:07:57.980 out of the box configuration for Redis, kind of a standard thing these days to use for any kind of 00:07:57.900 --> 00:08:03.440 caching that you might use inside of your application, but it has tunable capabilities 00:08:03.700 --> 00:08:09.440 since you can adjust the format of the serializer. So whether it uses like JSON, UJSON, MessagePack, 00:08:09.520 --> 00:08:14.020 or Pickle, you can also adjust the compressors it may use. So whether it's using Zlib, 00:08:15.040 --> 00:08:19.940 LZMA, or ZStandard is a new one that's coming up. It didn't exist when he did this 2017. 00:08:20.760 --> 00:08:25.280 So he just, actually, this is kind of all pre-AI as well. He did it the old school hard way, 00:08:25.800 --> 00:08:29.240 which is specify a bunch of different configuration combinations, 00:08:30.000 --> 00:08:34.580 run through a framework and try and test and see what the performance boost may be 00:08:35.200 --> 00:08:37.340 based on the kind of data he threw at it. 00:08:37.360 --> 00:08:39.400 So if you look down here, actually it's kind of fun, 00:08:39.700 --> 00:08:43.479 very ASCII art result graphs here. 00:08:43.960 --> 00:08:45.140 I'm here for the ASCII art. 00:08:45.140 --> 00:08:45.640 I'm here for it. 00:08:45.640 --> 00:08:45.660 Yeah, I know. 00:08:46.160 --> 00:08:47.320 So JSON is the slowest. 00:08:48.200 --> 00:08:50.260 Here are the shorter or better, so best averages, 00:08:50.660 --> 00:08:54.180 like for averages, medians, and size of data stored. 00:08:54.700 --> 00:08:56.820 You can see here, JSON, not so great. 00:08:57.000 --> 00:09:00.840 Actually, I wonder if in his updated version, he did not use ORJSON. 00:09:01.090 --> 00:09:02.580 I wonder how that would affect this. 00:09:02.670 --> 00:09:09.400 But basically, MessagePack as a message format is going to be one of the fastest ones he found for this specific application. 00:09:09.980 --> 00:09:12.260 And then if we look over here. 00:09:12.700 --> 00:09:17.720 I would bet that MessagePack is faster than ORJSON. 00:09:17.880 --> 00:09:18.060 Probably still. 00:09:18.060 --> 00:09:19.760 So I bet that sets a lower bound. 00:09:19.800 --> 00:09:27.040 Yeah. So updating here to look at three specific compressors, Zlibs, LZMA, and Zstandard, 00:09:27.600 --> 00:09:34.040 the LZMA is still slow. While it compresses well, it's slower from a performance standpoint. 00:09:34.740 --> 00:09:41.840 The default, actually not doing too bad here, except for size of data stored, which if you're 00:09:41.840 --> 00:09:47.400 saving larger sized items, there was a different performance difference, which actually I think 00:09:47.240 --> 00:09:53.500 leads to why coding agents like Claude Code and Pi and these orchestrators allow you to do this 00:09:53.500 --> 00:10:00.960 kind of experimentation with very low risk and overhead. Because ultimately, the end difference 00:10:01.180 --> 00:10:04.500 matters on the kind of data, like you just mentioned, the kind of data you're storing 00:10:04.980 --> 00:10:08.700 in these various serializers are going to determine a lot of the performance characteristics. So 00:10:09.080 --> 00:10:14.040 I hate saying it depends, but your mileage will vary based on what you're throwing into Redis and how 00:10:14.040 --> 00:10:17.780 you're accessing it. So it's always nice to be able to set up some kind of performance harness 00:10:17.980 --> 00:10:22.620 or benchmark where you can actually test these yourself and see how you get the most mileage 00:10:22.740 --> 00:10:26.400 out of these tools. And based on what I saw here, it seems like there's quite a bit of room for 00:10:26.640 --> 00:10:33.200 improvement for eking out more performance. So as we typically do, I like starting off with the 00:10:33.320 --> 00:10:37.900 defaults first and only optimize when I see a problem. But these are great ways to take a look 00:10:37.960 --> 00:10:44.000 at the different message format serializers for Django Redis and then the various compression 00:10:44.020 --> 00:10:48.440 formats that are out there for it so a nice methodology a nice little write-up showing some 00:10:48.440 --> 00:10:52.600 of the results and showing that it's actually not too not too hard for you to go implement this 00:10:52.760 --> 00:10:57.000 yourself a great way to get some squeeze more performance out of jango with your redis which 00:10:57.000 --> 00:11:03.720 is already fast but here you can i love it yeah yeah it's super fast i 100 endorse here let's try 00:11:03.720 --> 00:11:09.420 it with the built-in stuff and then see because yeah like in my example i could have taken on one 00:11:09.500 --> 00:11:13.980 more dependency and thing i have to update but it's like do you really need a tenth of a millisecond 00:11:14.580 --> 00:11:16.700 No, it makes zero difference to me, honestly. 00:11:17.120 --> 00:11:20.720 We'll talk about simplicity in my next one I bring up after yours here. 00:11:20.940 --> 00:11:21.240 Okay. 00:11:21.780 --> 00:11:25.900 I do have a little bit of real-time follow-up, sort of. 00:11:25.990 --> 00:11:28.160 I just chose to throw this out there, by the way. 00:11:28.160 --> 00:11:28.260 Oh, nice. 00:11:28.620 --> 00:11:30.220 Just a quick shout-out to Valkey. 00:11:30.720 --> 00:11:33.440 When I hear stuff on Redis, I'm like, don't forget the Valkey. 00:11:33.690 --> 00:11:34.500 You're familiar with this, yes? 00:11:34.940 --> 00:11:35.240 Oh, yeah. 00:11:36.540 --> 00:11:40.080 When there was a whole hoodoo around the licensing with Redis, 00:11:40.110 --> 00:11:42.220 we switched over to Valkey for many of our projects. 00:11:43.200 --> 00:11:43.860 It's been great. 00:11:43.940 --> 00:11:48.800 Cool. Yeah, yeah. That's awesome. Yeah. So basically Valkey is like the more open source, 00:11:49.040 --> 00:11:53.540 all a fork of Redis and it's like API compatible of my understanding, but it's, 00:11:53.900 --> 00:11:59.240 it's, you know, 26,000 stars. It's like a half a flask, something like that level of popularity. 00:11:59.620 --> 00:12:02.940 Yeah. Well, it's tricky because then the Redis folks went back on the whole 00:12:03.600 --> 00:12:08.160 Bizzle license back into open, right? Yeah, exactly. It gets, it gets a little funky, 00:12:08.380 --> 00:12:13.900 but let's talk about something that not even close to as controversial as that licensing 00:12:13.920 --> 00:12:19.140 Let's talk about Linus Torvalds puts his foot down against anti-AI kernel maintainers. 00:12:19.370 --> 00:12:20.560 There's a lot of double negatives here. 00:12:20.800 --> 00:12:22.480 So Linus says... 00:12:22.480 --> 00:12:24.000 I had a hard time parsing that one. 00:12:24.340 --> 00:12:24.920 I know. 00:12:25.620 --> 00:12:25.760 Okay. 00:12:25.830 --> 00:12:32.820 So Linus says, I'm not having it, that there are people saying we're unwilling to use AI 00:12:33.010 --> 00:12:35.600 in any way against the Linux kernel. 00:12:36.000 --> 00:12:37.400 And it's pretty interesting. 00:12:37.580 --> 00:12:40.920 I'm going to link to the actual original thing here. 00:12:40.920 --> 00:12:42.620 I got some quotes that I pulled out. 00:12:42.880 --> 00:12:47.040 So this all has to do with this thing called Shashanko. 00:12:47.310 --> 00:12:50.760 And what Shashanko is, I don't work on the Linux kernel, 00:12:51.360 --> 00:12:54.100 so it's not a thing I'm super familiar with, just to be clear. 00:12:54.760 --> 00:12:59.540 But Shashanko is an AI PR review tool. 00:12:59.900 --> 00:13:03.400 I guess it's built into GitHub or something like that for automation. 00:13:03.780 --> 00:13:06.580 You know, like GitHub actions are the equivalent thereof. 00:13:06.640 --> 00:13:13.540 And it will review inbound PRs for bugs, for correctness, performance, that kind of stuff. 00:13:13.720 --> 00:13:13.900 Yeah. 00:13:14.180 --> 00:13:19.200 And I think there are some people that are like, no, heck no, I want nothing to do with this thing. 00:13:19.620 --> 00:13:26.460 So it's not necessarily just cutting AI completely loose and saying, hey, here's the spec of the kernel. 00:13:26.920 --> 00:13:27.000 Right. 00:13:27.140 --> 00:13:27.640 Make it better. 00:13:28.060 --> 00:13:28.760 See you next week. 00:13:28.900 --> 00:13:32.460 You know, it's way more subtle and less intense. 00:13:32.600 --> 00:13:33.700 It's a human augmentation. 00:13:34.120 --> 00:13:35.840 It's making us better at what we do. 00:13:36.260 --> 00:14:04.900 Exactly. So I'll just pull out a couple of pieces here. I think this is, this is a little noteworthy. My understanding is he was fairly against this kind of stuff and then kind of played with it more. It's like, you know what, actually I'm not against it anymore. And let me just put this out there. Like he acknowledges it. I acknowledge it. I'm sure a lot of people will that there are downsides to AI in lots of ways, but there are also upsides. Right. And so says Linux is not one of those anti AI projects, you know, think Zig or something like that. Right. 00:14:05.240 --> 00:14:09.720 And if somebody has issues with that, they can do the open source thing and fork it or just walk away. 00:14:10.160 --> 00:14:10.920 It's like, you know what? 00:14:10.960 --> 00:14:11.160 Okay. 00:14:11.670 --> 00:14:14.100 I mean, what do you expect from him, right? 00:14:14.400 --> 00:14:14.740 That's true. 00:14:14.820 --> 00:14:15.300 What do you expect? 00:14:16.080 --> 00:14:19.480 AI is a tool, just like other tools we use, and it's clearly a useful one. 00:14:19.760 --> 00:14:24.400 And it may not have been that clearly even just a year ago, but that's no longer the question. 00:14:24.720 --> 00:14:26.160 I think that's an important thing, right? 00:14:26.340 --> 00:14:31.060 Like people have formed opinions, especially people who have formed the opinions like, I don't want to touch this. 00:14:31.170 --> 00:14:31.580 This is junk. 00:14:31.900 --> 00:14:33.560 It's like, why would you come back to a thing that's junk? 00:14:33.850 --> 00:14:34.240 You know what I mean? 00:14:34.460 --> 00:14:34.580 Right. 00:14:34.860 --> 00:14:38.300 Why would you go build a house with hand tools when you've got power tools available? 00:14:38.760 --> 00:14:39.520 Yes, exactly. 00:14:39.770 --> 00:14:41.200 Well, because nail guns are dangerous. 00:14:42.060 --> 00:14:43.580 And we've had them since the 40s. 00:14:45.500 --> 00:14:51.380 I do want to point out that there's this really good, I've mentioned this guy before on the show. 00:14:51.400 --> 00:14:52.480 Are you familiar with this? 00:14:52.880 --> 00:14:53.320 I am not. 00:14:53.500 --> 00:14:56.780 Maximilian Schwarzmüller, this German guy. 00:14:56.960 --> 00:15:01.200 He's really good at talking about trends in software development. 00:15:01.420 --> 00:15:08.000 And one of the things he says here is he, in response to talking about this, said it is time to wake up for some. 00:15:08.010 --> 00:15:16.120 So he put it less, more bluntly saying, look, if in a couple of years, if you're doing professional software development, you're going to have to be using these tools. 00:15:16.580 --> 00:15:16.740 Yeah. 00:15:17.080 --> 00:15:20.120 And you need to get good at them regardless of how you feel about them. 00:15:20.400 --> 00:15:20.800 You know what I mean? 00:15:21.100 --> 00:15:22.780 It's fine for hobby stuff not to do it. 00:15:23.200 --> 00:15:24.460 That's like a 12 minute. 00:15:24.620 --> 00:15:27.520 That's a summary of a 12 minute video, but it's really well done. 00:15:27.570 --> 00:15:28.740 So I recommend people check it out. 00:15:28.820 --> 00:15:30.220 And he's just an interesting guy. 00:15:30.560 --> 00:15:32.000 Okay, back to what Linus is saying. 00:15:32.500 --> 00:15:34.120 Yes, it can be somewhat painful tool 00:15:34.440 --> 00:15:35.900 for maintainer workloads and so on. 00:15:36.020 --> 00:15:39.100 And also because it just keeps finding embarrassing bugs, 00:15:39.300 --> 00:15:41.300 which is annoying, but amazing. 00:15:41.740 --> 00:15:44.940 I think that this embarrassing bugs bit is actually transient. 00:15:45.580 --> 00:15:47.340 We've got 10, 20, you know, 00:15:47.380 --> 00:15:48.960 however long the projects have been around for, 00:15:49.320 --> 00:15:50.280 years of tech debt. 00:15:50.620 --> 00:15:51.060 Tons. 00:15:51.200 --> 00:15:52.860 Yeah, and we send this tool on. 00:15:52.960 --> 00:15:53.920 It's like running a linter. 00:15:54.040 --> 00:15:55.020 Like, do you guys have a linter? 00:15:55.280 --> 00:15:58.040 No. Oh, you should try a black or rough or something. 00:15:58.180 --> 00:15:59.980 And then it's like, there's 2000 errors. 00:16:00.380 --> 00:16:01.620 we can't fix 2000 errors. 00:16:01.830 --> 00:16:03.120 Like we just don't run it anymore. 00:16:03.360 --> 00:16:03.820 You know what I mean? 00:16:04.400 --> 00:16:06.740 But projects that start adopting linters 00:16:06.920 --> 00:16:09.760 don't always have 2000 warnings or issues, right? 00:16:10.600 --> 00:16:11.360 All right, carrying on. 00:16:11.720 --> 00:16:12.860 But the solution is not to put your hand. 00:16:12.860 --> 00:16:13.640 It feels like nothing but win here. 00:16:13.880 --> 00:16:15.100 Like you want a linter? 00:16:16.240 --> 00:16:17.860 I wouldn't go without it right now, period. 00:16:18.100 --> 00:16:19.240 Yeah, 100%. 00:16:19.280 --> 00:16:20.580 It's just, it's kind of painful 00:16:20.780 --> 00:16:21.780 to deal with some of the fixes, 00:16:22.080 --> 00:16:23.460 but you know, you get through them 00:16:23.530 --> 00:16:24.460 and then it's pretty straightforward, 00:16:24.880 --> 00:16:26.060 especially with --fix 00:16:26.090 --> 00:16:26.960 and a lot of the modern ones. 00:16:27.050 --> 00:16:27.140 Okay. 00:16:27.860 --> 00:16:29.619 So the solution here says Linus 00:16:29.680 --> 00:16:34.420 is not to put your head in the sand and sing la la la can't hear you at the top of your voice 00:16:35.340 --> 00:16:39.740 it's to make sure the lm tools help maintainers instead of causing them pain we're not for and 00:16:39.860 --> 00:16:44.520 here's the essence of this whole um thing we're not forcing anyone to use it but i will verily 00:16:44.800 --> 00:16:51.000 loudly ignore people who try to argue against other people using it there's no ai is not perfect 00:16:51.540 --> 00:16:57.739 but but blankety blank anyone who points the problems points to the problems that ai had 00:16:57.760 --> 00:17:01.320 better be looking in the mirror and pointing themselves at the same time because people make 00:17:01.420 --> 00:17:06.439 mistakes too all right pretty certainly i did not write this email post yeah this feels very human 00:17:06.980 --> 00:17:12.199 this is very much on brand so i thought i put out there i feel like it's a little bit seminal 00:17:12.560 --> 00:17:18.459 and in terms of this um ars technica has a write-up as as well and it's gathered almost 200 00:17:18.680 --> 00:17:23.319 comments so that's worth checking out yeah yeah i'm curious why folks the folks who are in the 00:17:23.339 --> 00:17:29.720 never AI camp are not using it even for completion do they never use it and I mean I held out on IDEs 00:17:29.730 --> 00:17:33.600 for a long time because I didn't feel like I needed the autocomplete but like that those days are long 00:17:33.760 --> 00:17:38.780 gone like this things have gotten so fast and have helped me like streamline my workflow where it's 00:17:38.790 --> 00:17:42.900 not standing in my way and I feel like these tools will get into that point where it is just like 00:17:43.040 --> 00:17:48.139 wrapping a amazing exoskeleton around your capabilities and going for it and doing more 00:17:48.539 --> 00:17:53.080 and better. Yeah. Yeah. I don't remember the numbers. I don't know. I don't believe they're 00:17:53.120 --> 00:17:57.300 in here, but they might be in a fall. I mean, there's a conversation to be had. You can see, 00:17:57.340 --> 00:18:03.080 if you look at the art, the thread, but I believe it's something like this Shashanko thing is like 00:18:03.320 --> 00:18:09.040 15% false positives, but 85% like, yeah, these are actual bugs that you didn't have to find. 00:18:09.080 --> 00:18:12.980 I just told you they're bugs here. Yeah. And these people have all written helper scripts 00:18:13.300 --> 00:18:17.100 to do these kinds of things. They can't be against this one. Yeah. I mean, they can, 00:18:17.160 --> 00:18:18.360 but it doesn't make any sense. 00:18:19.900 --> 00:18:21.700 Yeah, I just, I feel like if you've got a tool 00:18:21.860 --> 00:18:23.440 that by the time you get to the PR, 00:18:23.690 --> 00:18:26.080 it has an 85% accuracy rate of finding 00:18:26.400 --> 00:18:27.920 and dealing with any of the issues. 00:18:28.160 --> 00:18:30.060 Like, that's pretty good. 00:18:30.300 --> 00:18:30.660 Yeah, pretty good. 00:18:30.800 --> 00:18:32.980 Plus you're still expected to operate as a human 00:18:33.390 --> 00:18:35.340 in this case, like bringing the creativity, 00:18:35.640 --> 00:18:36.720 bringing the original thought, 00:18:38.020 --> 00:18:40.340 just letting it take care of all the mundane, boring stuff. 00:18:40.510 --> 00:18:42.500 Like making sure you cross your T's 00:18:42.500 --> 00:18:43.700 and dotted your I's in the code. 00:18:44.380 --> 00:18:45.180 Seems like all went. 00:18:45.840 --> 00:18:46.340 All went to me. 00:18:46.760 --> 00:18:47.120 100%. 00:18:47.140 --> 00:18:51.280 Speaking of when, wouldn't it be awesome if HTML did better stuff? 00:18:51.480 --> 00:18:57.200 Like they didn't stop building it when soon as JavaScript was invented in the 90s or whatever it was. 00:18:57.230 --> 00:19:05.840 Yeah, so our third Django-related news item for the day is that the Django Steering Council is backing the Triptych Project. 00:19:06.100 --> 00:19:16.080 So if you're not familiar with the Triptych Project, it is three proposals for the HTML standard to make things a little more native and expressive. 00:19:16.920 --> 00:19:20.520 So adding in, for example, put patch and delete methods to forms. 00:19:21.500 --> 00:19:37.440 We've all abused post far too long and added in things like slash delete to the end of our API URLs to accomplish things that really should just be using a specific vocabulary or verb from HTTP language, which is delete. 00:19:37.820 --> 00:19:40.520 So this gives us the ability to put those three extra actions. 00:19:41.140 --> 00:19:43.800 The fact that button actions should be a thing. 00:19:44.070 --> 00:19:47.560 So buttons that just can fire HTTP requests without wrapping them in a form. 00:19:47.860 --> 00:19:52.220 How many times have you had a singleton button with form on top, form on the bottom? 00:19:53.180 --> 00:19:57.640 Or worse, like for example, if you're not using a button, but dressing up a link to 00:19:57.750 --> 00:20:02.180 look like a button, for example, like a logout, the logout button could potentially get triggered 00:20:02.400 --> 00:20:07.320 by some of the prefetch operations that are happening by some of the browsers or unfurling, 00:20:07.510 --> 00:20:07.840 et cetera. 00:20:08.260 --> 00:20:11.300 So you may get unexpectedly log out or unexpectedly delete something. 00:20:11.750 --> 00:20:15.100 Be careful when you make a button that says delete, that is actually a link. 00:20:15.440 --> 00:20:16.420 Those buttons should be buttons. 00:20:17.460 --> 00:20:22.900 There was actually back in internet lore, there was a really interesting thing. 00:20:22.930 --> 00:20:29.300 I think at the early days of Wikipedia, that one of the delete buttons was actually just 00:20:29.460 --> 00:20:34.460 an Ahrefs that went to a delete operator, but did a Git and got indexed and deleted a bunch 00:20:34.620 --> 00:20:35.060 of Wikipedia. 00:20:35.340 --> 00:20:35.980 I think it was Wikipedia. 00:20:36.080 --> 00:20:43.620 idea. Yep. So the idea is, yeah, let's, let's resimplify, make things more semantically 00:20:44.380 --> 00:20:49.260 operational in the way that we should expect them to work. The last thing, the last proposal 00:20:49.520 --> 00:20:54.260 is actually around partial page replacements. So if you are taking the ideas from basically HTMX, 00:20:54.680 --> 00:21:00.840 Unpoly, and Turbo, and putting them into the HTML standard itself. So this means if the standard 00:21:00.860 --> 00:21:07.440 gets adopted and the browser start putting this into their HTML parser and engine that's powering 00:21:07.560 --> 00:21:12.860 your web browser, less JavaScript and libraries can actually be shipped to get the same level of 00:21:13.020 --> 00:21:17.960 interactivity on the pages that we're doing right now today with things like HTMX. I really like 00:21:17.960 --> 00:21:24.080 the HTMX library. I feel like it gives people a clean, clear way to do things in Django really 00:21:24.320 --> 00:21:29.640 fast and have like a single page web app like front end without having to rebuild all of your 00:21:29.500 --> 00:21:31.920 Django models in React on the front end. 00:21:32.040 --> 00:21:33.720 Like with a lot of the React patterns, 00:21:33.940 --> 00:21:35.880 you are building the same models twice, 00:21:36.220 --> 00:21:39.100 the same routers twice, the same application basically 00:21:39.200 --> 00:21:41.700 has to be built and maintained in two separate frameworks. 00:21:42.320 --> 00:21:44.580 Where if you just had these capabilities built 00:21:44.780 --> 00:21:47.320 right into HTMX or the browser, I mean, 00:21:47.700 --> 00:21:51.240 with this triptych project proposals for the HTML spec, 00:21:51.660 --> 00:21:54.880 well, think about how clean and this is simple 00:21:55.700 --> 00:21:56.940 that the development could be, 00:21:57.080 --> 00:22:00.680 especially for testing out and running quick little one-off projects. 00:22:00.820 --> 00:22:05.840 They could be so much less dependencies, hopefully less maintenance going on in there. 00:22:06.180 --> 00:22:07.320