Transcript #122: Give Me Back My Monolith

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your buds.

00:05 This is episode 122, recorded March 20th, 2019. I'm Michael Kennedy.

00:11 And I'm Brian Okken.

00:12 And this episode is brought to you by DigitalOcean. They have some big news to share with you.

00:16 I'll tell you all about that shortly. Check them out at pythonbytes.fm/digitalocean and get a $100 credit for new users. So, tell you more about that later. Brian, how are you doing?

00:26 - I'm doing good, and if I chuckle, it's because you got your mic up and you kind of look like a rapper doing the thing.

00:32 - Yeah, I'm gonna drop it at the end of this episode.

00:35 - Yeah, anyway, no, things are good.

00:37 - People can't see, yeah, so I've got my microphone on a different stand, so we'll see how it sounds, but yeah, I think it's working all right.

00:43 - Yeah. - Nice.

00:44 All right, so I find dictionaries sometimes get used in Python, like every now and then people will make use of that fancy data structure.

00:54 - Yeah, definitely.

00:55 One of the hard things, and I don't have a link to this, maybe we could drop it, but one of the things you need to do with dictionaries is pull them apart and put them together and stuff.

01:04 There's a PEP 584, it's had the plus and minus operators to the built-in dict class.

01:10 - Yeah, that makes a lot of sense to me.

01:11 I mean, we already have it for list, well, not the minus, but we have the plus.

01:15 - List makes sense because operators are neat and the thing that throws me off is the massive difference between if you do dictionary one plus dictionary two, it's different than dictionary two plus dictionary one because the second thing always wins.

01:34 - Right, if there's duplicate keys, the second one is gonna overwrite the first one.

01:38 So you're saying that addition might not be commutative, that might be a problem.

01:42 - Well, maybe, but I mean like strings are like that, like if you've got, I don't know, do we do--

01:48 - That's true, you don't get the same result of like hello plus world or world plus hello.

01:52 - Yeah, exactly.

01:54 So maybe it's okay.

01:55 We'll link into the pep.

01:57 Actually, I think it's nice because if you look at the alternates, the alternates are gross.

02:02 Like you can unpack both dictionaries and then create a new dictionary or you can copy one and then update it with the other.

02:09 That all of those are not obvious and so I think plus would be good.

02:13 So we're gonna link to that article but also Guido Van Rossum wrote an article called why operators are useful that partly talks about this.

02:23 And then also there's an email link of why, apparently one of the options for combining dictionaries was to use the pipe operator instead of plus.

02:32 And so I've got a link to that too.

02:34 But actually, so this is just a, we don't know if it'll go in, it's in draft status and it just got proposed, but I think this is, would be a neat thing to add to Python.

02:43 - Yeah, I'm honestly a little bit surprised it's not already there.

02:46 It would be nice.

02:48 I certainly prefer plus over pipe.

02:50 Like, pipe is not something that's commonly used in Python for combining stuff.

02:55 Maybe if this was C or something, I don't know, but it certainly in the Python world, plus seems like a more natural choice here.

03:01 So this next one comes from Matthew Rockland, the guy behind Dask and other data science-y things.

03:07 I recently interviewed him on Talk Python, but you know, time shifting, it will be in the future when that comes out.

03:12 But I was reading through some of his articles and found something I thought, you know, well, at least it super resonated with me.

03:19 I don't know how your world is, Brian, but mine is like a constant stream of inbound inquiries, requests, comments.

03:29 Like watch the Talk Python Twitter account, my personal Twitter account.

03:34 We share watching the Python Bytes Twitter account.

03:36 I have a Gitter channel.

03:38 I'm on a couple of Slacks.

03:39 I'm on like Cisco Teams or something like this.

03:42 Email is insane.

03:44 And there's just too many places that stuff comes at me.

03:48 And I've spent like, there's times where I'll take a week and I'll take a full two days off to just write email and respond to messages.

03:55 And I'm still not all the way caught up.

03:56 It's like, it's really a problem.

03:58 So when I read this article called, "Why I Avoid Slack" by Matthew Rocklin, I'm like, oh, yes, this definitely resonates with me.

04:05 Because when you get that much inbound stuff, like anything that's transient is super hard to keep track of, right?

04:12 Like @mentions on Twitter, like maybe I'll catch him, but if I don't, like I'm sorry, but I just, you know, it's, I lost it.

04:18 It went by in the stream somehow on accident or something on Slack, right?

04:22 Like it's a hundred messages back and you know, I dropped in there and I didn't check it, marked the messages red and left and now it's just gone, right?

04:30 It's never gonna come back.

04:32 So I feel like those kinds of things, while kind of fun and interesting and more lively are also, you know, just adding stress and not really positive.

04:41 So Matthew wrote this cool article saying, "Why avoid Slack focused on "for open source maintainers of projects?" Right, like should we have a Slack channel for open source project?

04:53 He says, "No." So he says, "Instead of doing something like that," I mean, I guess a Gitter channel would be basically equivalent.

05:01 Says, "I encourage colleagues to have technical "and design conversations on GitHub "or some other system that is public, "permanent, searchable, and cross-referencable." What do you think?

05:10 especially for that case of open source projects and those types of conversations, I think I totally agree.

05:18 - Yeah, so he says, you know, a couple reasons why, like say GitHub, public GitHub repos and their issues and their conversations and PRs and whatnot around it are better than Slack would be because you can engage collaborators who aren't on Slack, right?

05:31 Not everyone is on Slack, but if you're working with a person who doesn't have a web browser, that's probably okay, you can ignore that person.

05:38 But most people can get to the web and they can read or even Google search and then find some kind of thing.

05:45 Also, you can record the conversation because it sounds like his life's a little bit like mine.

05:49 Like, hey, everybody just needs a couple of minutes of your time every couple of minutes, you know?

05:56 And it completely derails any form of productivity.

05:59 So it's super hard.

06:01 And the reason is they'll drop in a Slack channel or some other conversation and go, hey, why is it like this?

06:07 Or just quick question about that.

06:08 And it's like, if you have it in an issue and discussed or something, you can say, that's issue 17725.

06:15 We talked about it for a week.

06:16 Here's a whole detail, all right?

06:18 Also, you can serve the silent majority.

06:20 That is people who go to Google and they type in a thing and say, I need help with this thing or why does this work that way?

06:26 GitHub ranks super high on Google and those issues often come up and you can see the whole conversation.

06:32 - That's a great idea.

06:33 - Yeah, the other one is encourage more thoughtful discourse.

06:37 So if you're writing like one-on-one or a couple of people in a Slack channel, you're willing to just throw out kind of quick off-the-cuff comments.

06:45 If you're writing in a public permanent forum that's associated with your GitHub profile, it's much more likely that you're gonna write something thoughtful.

06:53 And finally, you get to cross-reference issues.

06:56 So you can say, we talked about part of it here and part of it over there on this other issue, and then there was this PR, and then we're bringing it back here.

07:02 Your Slack is siloed, you can't cross-reference people and conversations and things like that.

07:06 So here's a call to say, enjoy Slack, chat in Slack, but don't use Slack for design decisions and other stuff.

07:15 Maintainers come and go, maybe you wanna have a history of these things and not just a transient chat stream.

07:21 - Yeah, and the bigger a Slack channel gets, the more useful it is in some respects.

07:25 You get answers really quickly.

07:27 But also, the more it reflects like kind of just a topical party at somebody's house with lots of conversations going on.

07:34 - Right, there was a cool chat about this thing on the couch, but that's not the same as like, we wrote up our thoughts on that thing.

07:41 - Yeah, exactly.

07:42 Oh, I'll have to read this.

07:42 - Yeah, it's pretty good.

07:43 It's not much longer than actually what I talked about, but it's still really helpful, I think.

07:48 What's the next one you got for us?

07:49 - That reminds me, actually, no, I had a leak in my memory.

07:52 No, that's bad.

07:53 - That's pretty good, actually.

07:55 It's so bad, it's good, I like it.

07:57 - There's an article from Zendesk, from Y. Chiao, that's called "Hunting for Memory Leaks in Python Applications." And we've covered memory leak stuff before, but I really liked this write-up.

08:09 And it's specifically, they've got, Zendesk has a bunch of machine learning in Python written.

08:16 And one of the problems they run into is some of them will have really big memory spikes or memory leaks, and they want to try to figure that out.

08:25 So this was a specific use case.

08:27 So he's not covering all of the options, just some of the tools that were used there.

08:32 And I think it's cool.

08:33 I didn't know some of these things were around.

08:35 So there's a, for example, there's a combination of the memory profiler package with matplotlib where you can easily run without doing anything to your code, you can run some Python code and then get a visual graph of the memory utilization, which is cool.

08:53 If you're hunting into stuff and trying to break things around, there was a discussion of using, adding some code to your code to use, it looks like Muppy, M-U-P-P-Y.

09:02 Yeah, Muppy.

09:03 will dump, heap dump in certain places.

09:07 So if you think, sometimes time really doesn't help you too much, but you can add certain places where you think there is a stable state, doing a heap dump, especially if it's somewhere, something that's looping, you might be able to catch something there.

09:19 Reference to object graph or obj graph to profile memory object lineage.

09:26 So objects that create other objects.

09:28 - Yeah, that can be tricky because you've got, maybe you have some object, it's a class, and it's got some field, that field is a list, in that list it has a bunch of objects, one of those happens to hold onto a pointer to some other huge dictionary that you thought should be gone, but there's still some reference keeping it alive, right?

09:44 So this object graph will tell you that basically?

09:47 - Yeah. - Nice.

09:47 - Like for example, when he dumped some of the heap dumps, some of those examples, it's just that you've got so many megabytes towards strings.

09:57 Well, I don't know if that really helps you too much.

09:59 having a finding out where it came from might be helpful.

10:02 >> Yeah.

10:03 >> Then he ends the article with a bunch of tips.

10:05 Do quick feedback.

10:06 If you think something, one of the things I liked which is probably really good is, if you have memory intensive tasks or something you think might be the problem, separate that into a separate process, so you can debug it separately.

10:19 The Python built-in PDB has a bunch of stuff that can help you as well.

10:23 Then also watch out for leaky packages, because the leak might not be in yours, it might be in your dependencies.

10:30 Yeah, you might have pip installed a memory leak, for sure.

10:33 Which I was surprised that he said, for example, pandas.

10:35 And I'm like, really? Pandas is like, must be tested the heck out of it.

10:39 But apparently there's some known pandas problems in some corner cases.

10:43 But oh well.

10:44 Yeah, it probably is kind of tricky with like the C layer holding on to PyObject references and all sorts of funkiness, right?

10:51 My first reaction to dealing with memory in Python is like, well, we're not supposed to have to, so it must be a real pain in the rear.

10:57 But these tools don't look that bad to work with if you need to.

11:00 This object graph looks really cool and it will actually create a PNG visual graph of the relationships, which is cool, and you can even ask for back references, like, it seems like this is the thing that has all the memory, it should be gone, but why is it not garbage collected or cleaned up?

11:17 And you can say, draw me a graph, or not a, like a mathematical graph, not a parabola type graph, a graph to your graph of all the back references to this object, which is nice.

11:28 Yeah, so you can ask it in both directions.

11:30 Yeah, right.

11:31 If you think it should have been deleted and it's not, it's because somebody's still referencing it.

11:34 Right. So who is that?

11:36 Tell me about that.

11:36 I need to know about that right now.

11:37 Yeah, that looks really cool.

11:39 It's definitely something I'd like to explore.

11:41 Actually, let me rephrase that.

11:43 I don't want to explore it.

11:44 I don't have memory leaks, but if I do, I will find it very useful.

11:47 Yes, definitely.

11:48 Here you go.

11:49 Also useful, DigitalOcean.

11:51 Let me tell you a cool thing that they just released.

11:53 And this came from one of the listeners.

11:55 They sent me a message like, "Hey, this looks really cool.

11:57 Do you know about this?" So they announced this thing called the Digital Ocean Marketplace.

12:03 So the idea is that different companies and other people can create these pre-configured virtual machines, and then you can just do one-click app install them.

12:12 Like, if you want a Ghostblog server configured with Nginx and all that, you just click Ghostblog server, pay your $5, and now you have one.

12:20 Or maybe you want GitLab Enterprise, a MongoDB server, or even you can say, "I want a Django server," and it'll give you Django, Nginx, G-Unicorn, Postgres, Certbot, a whole bunch of stuff pre-configured all to work together in a few seconds.

12:34 That's pretty cool, right?

12:35 >> Yeah, definitely.

12:36 >> Yeah, yeah, yeah.

12:37 So I think this is a really nice feature.

12:38 It's already great to run infrastructure there.

12:41 Now if you can get it much closer to the end, it's a little bit, I'm sure it's Docker-inspired, right?

12:47 It seems like that, but for their infrastructure.

12:49 You still have to figure all that stuff out and to be able to throw a few dollars to the people who are willing to do the work to put it together, that's great.

12:55 - Yeah, it's beautiful.

12:56 All right, so check them out over at pythonbytes.fm/digitalocean, create an account, and then once you get into your account, there's a little marketplace tab over there.

13:04 So, super cool.

13:06 So speaking of Docker and all these other things, there's a cool article by Craig Kerstens, and it's called "Give Me My Monolith Back," or "Give Me Back My Monolith," as opposed to a whole bunch of microservices, right?

13:20 So there's been a lot of hype, excitement, I don't know, take your, choose your side of the fence around microservices.

13:28 And this is the idea of like, yeah, you have a web app and it's got like 500 Python files and maybe it's doing all these different things.

13:36 And wouldn't it be better if we could take the credit card processing and make it its own service with its own database?

13:42 If we could make the caching its own service, It's user accounts, it's own service, all that kind of stuff.

13:49 And then that user account part is super simple, right?

13:51 Because the whole purpose of this application is, who are you, what can you do, can you log in, can you reset your password or something like this, right?

13:59 That seems good, yeah?

13:59 - Yeah.

14:00 - There's a lot of really good uses for this.

14:01 Like if you have a large team of people working on a large web app, it might make more sense to break into these small pieces and have some people in charge of each piece.

14:12 I think that actually legitimately makes a lot of sense.

14:14 It's easy to bring on a junior developer who can say, all right, I'm gonna work on this caching bit or whatever, and I don't have to know the whole thing.

14:21 I just gotta work on my little API.

14:23 It does court, async, or whatever it does.

14:26 That makes a lot of sense, but most people who are working on web apps aren't in that space of having 30 people on their team.

14:33 That's really rare.

14:34 You've got them down this rant of you're not Google, you're not Facebook, you're not LinkedIn.

14:37 You don't need all these patterns 'cause you are not them.

14:40 You're a little relatively smaller company or project.

14:44 Anyway, this guy feels like, you know, that adds a lot of complexity and challenges and he lays them out of like, why does the world have to be so hard?

14:54 Wasn't it easy before and now it's not.

14:57 Not from the article, but just a thought of mine.

14:59 Like when I think of this microservice architecture, what you're doing is you're taking code complexity and you're moving it to infrastructure complexity.

15:08 - Yeah, definitely.

15:09 - Instead of having one kind of complicated bit of code, I now have 12 super simple bits of code, but they all have to work together in fairly complicated network environments, failover, all this kind of stuff, this topography and whatnot.

15:23 So my thought is at least, well, which of those two things are you good at, infrastructure or code?

15:30 That drives a lot of these decisions.

15:32 But he runs down a couple of things that he said used to be simple, but now we get to revisit them.

15:38 Get to.

15:38 So, setup went from like chemistry to quantum mechanics.

15:42 A lot of this has to do with bringing new people onto a team or junior developers and things like that.

15:48 So it says, onboarding a new engineer, at least for the initial environment, used to be like half a day.

15:54 And now we've ventured into microservices, this onboarding time has skyrocketed and it's super complicated for them to understand all the moving pieces.

16:02 And then the next one is, so long for understanding our systems.

16:07 You know, back when we had monolithic apps, you had an error, it had a stack trace.

16:11 You click on the hyperlink generated by your little editor to take you to the line where the stack trace is.

16:16 And now, you have different services that talk to another service, that queue something on a message bus, that another service pulls it out, and then you get an error.

16:25 What caused that?

16:27 Right, how do you follow that through?

16:29 How do you debug that?

16:30 So, it says, well, if we can't debug them, maybe we can test them.

16:33 Talks about the challenges of continuous integration and whatnot.

16:36 but also talks about some services that were made into some apps that were made into microservices that are now moving back sort of in a reverse migration to these monoliths.

16:46 And I gotta say, I'm pretty sympathetic with this.

16:49 Like I see the value of microservices, but I also know that I'm not Google, right?

16:55 And so, yeah, anyway, for me, I don't think this whole microservice world makes as much sense in my space, but I don't know, what do you think?

17:03 - We should go back to HTML and Perl.

17:06 - That's right, can't we just have static files?

17:08 All this like logic is busting your brain.

17:09 - CGI used to be easy.

17:12 No.

17:12 - No, it actually was never, ever easy.

17:15 - I think that there's different ways to solve problems and I think that making sure that you're paying attention to it, I think is a good idea and make sure that people understand that microservices are sometimes it's a funny, it's a shiny new thing to go learn.

17:31 And sometimes that's not bad if you're willing to take on the risks.

17:35 but it is changing from what you know to what you don't know is a risk.

17:40 - It's definitely exciting.

17:41 I mean, you can bring in Docker and Kubernetes and do all sorts of fun stuff, but at the same time, just be aware of the trade-offs you're making.

17:48 - Some of the things that it solved are now solved by async.

17:51 - Yeah, that's true, absolutely.

17:53 - One of the things also is if you're in a single language or not.

17:56 So one of the things that microservices gives you is the different teams can do whatever language they want, as long as they provide an interface that's compatible with everybody else.

18:05 - The authentication bits in Node.js, the caching tiers in something else, and the front ends in Python or whatever.

18:12 - Yeah, definitely.

18:13 - Yeah, makes sense.

18:14 Again, it's not something you will do that often when you're just a couple of people, but if you're a big team or set of teams, then sure, makes a lot of sense.

18:22 All right, so I know of some famous laws and rules in software development, like the solid principles, single responsibility principle, open-close principle, these are all good.

18:32 You found some more amusing ones, didn't you?

18:35 - Yeah, some of them are serious and some are amusing.

18:39 All of them have kind of a little bit of truth.

18:41 And this is an older article, so I'm not really sure how I got a hold of it.

18:45 But it's the famous laws of software development, and there are 13 listed.

18:50 I think I counted that many.

18:52 I'm not gonna read all 13.

18:54 I guess it was written in 2017, it's not that old.

18:57 But okay, so Hofstetter's Law, which is great.

19:01 It always takes longer than you expect, even when you take into account Hofstadter's law.

19:05 So it's self-referencing.

19:07 - I love it, yeah, I love it.

19:08 (laughs)

19:10 There's some money good ones here.

19:11 - So that's just funny.

19:12 There's Conway's law, which it's not supposed to be funny, but it's sometimes depressing.

19:18 Any piece of software reflects the organizational structure that produced it.

19:23 - Yeah, I think that's true.

19:24 - Like microservices are great for lots of teams.

19:27 One team, one monolith, or something.

19:30 I don't know, but I've seen that before.

19:32 Also, the hierarchy of different teams shows up in the software as well.

19:37 And then, of course, a couple more I'd like to point out, the peer principle, in any hierarchy, every employee tends to rise to his level of incompetence.

19:48 - Sounds like a quote from the Despair, Inc. calendars or posters.

19:54 That's great.

19:55 - Yeah, and then the 90/90 rule, which I haven't actually heard before, but it's just hilarious.

20:01 Have you heard this before?

20:02 - No.

20:03 - The first 90% of the code takes 10% of the time.

20:06 The remaining 10% takes the other 90% of the time.

20:09 - That sounds about right to me.

20:11 Yeah, it's definitely, it feels like things just drag on and on right at the end of these projects.

20:16 So the comments are good too.

20:17 I noticed that some people, a guy named Cory threw in a thing and said, "I'm shocked that Cunningham's Law isn't on the list." Cunningham's Law, the fastest way to get help over the internet is not to ask a question, but instead to answer it wrong.

20:31 (laughing)

20:33 And then someone also responds, maybe it's omission was the conscious choice to invoke it.

20:37 (laughing)

20:39 - That's awesome.

20:40 - Yeah, it's really good.

20:41 There's a bunch of nice ones in there.

20:42 - Yeah, that's like real though.

20:43 I mean, the best way to get people to help you on the internet is to start blogging the wrong stuff.

20:48 (laughing)

20:49 - Yeah, enable comments and start writing.

20:52 Yeah, that's cool.

20:54 I got a quick one to round it out here.

20:56 We talked about a plugin architecture before for building plugins that ran like within your app.

21:02 So basically, ways to let people interface like simple bits of code into your other systems and version plugins and all that.

21:09 There's another one called Beer Garden plugins, which is pretty fun.

21:13 I want the listeners suggested this.

21:15 So the idea is it's a framework that will convert your functions.

21:19 These are like regular Python scripts.

21:21 They don't know anything about the web or plugins or whatever, convert those into composable, discoverable, production-ready services, as in RESTful, HTTP services with minimal overhead.

21:33 So if you have a class, you can just go say, this is a system, and then the functions on the class, you go, these are services, and they take these parameters, and you describe what they take, things like that, and it will just go serve that.

21:45 And it even does cool stuff like it does swagger documentation of the services and whatnot.

21:51 So yeah, it's a pretty interesting little quick way to convert code that was not meant to be a service into services.

21:57 - Oh, very cool.

21:58 - Yeah, it's pretty cool.

21:59 It's apparently based on MongoDB, RabbitMQ, and it supports modern Python, so that's pretty cool.

22:06 It talks about what you have to do to get it running, or something that's kind of nice is it also comes in a Docker and Docker Compose form.

22:13 So you can just clone the Docker Compose bit from GitHub, and then you say Docker Compose up, and now it's up and running.

22:21 And then you can give it these little apps and whatnot, it's pretty cool.

22:25 - Nice.

22:25 - Yeah, so I think the idea is you run your code and it plugs into the server there.

22:29 So yeah, anyway, it's pretty neat.

22:31 People can check that out if that sounds like something they're looking for.

22:35 All right, well, that's it for official items.

22:37 Anything else you wanna cover here at the end?

22:40 - Just had a really cool interview the other day.

22:44 This'll go out as a testing code 69, which should be available for everybody before you listen to this.

22:51 But it was with Andy Hunt, who is now at the head of Pragmatic Programmer.

22:56 I mean, Yeah, he's one of the original founders of it, right?

22:59 Him and one other guy, I think?

23:01 Yeah.

23:02 Is that right?

23:03 Andy Hunt and Dave Thomas wrote the Pragmatic Programmer, and that was released in '99.

23:06 And then in 2003, they formed their own publishing company, and they've been going strong.

23:11 And the Pytest book was under their publishing company.

23:13 And so now Dave doesn't play an active role in the publishing anymore, but Andy does.

23:20 So it's a really cool conversation.

23:21 Andy was also one of the original signers of the Agile Manifesto.

23:25 And so we talk a lot about, oh, right.

23:28 That's cool.

23:28 Yeah.

23:29 We talk a lot about that and quite a few other things.

23:31 So that, that, that's a fun thing to listen to.

23:33 Excellent.

23:34 I'm definitely going to check it out when you release it.

23:35 That's a good one.

23:36 How about you?

23:36 So I have two quick things to share with you.

23:39 First, there's this thing called Firefox send.

23:42 Have you heard of this?

23:43 I have not.

23:44 Yeah.

23:44 So Firefox send is actually not something built into Firefox, but it's more like a Mozilla project to make the web better, right? So here's what it does is it lets you share files securely, large files like up to two and a half gigs per file, and it does end-to-end encryption where the the decryption key is actually stored in the URL. So if you don't share the URL, like even the Firefox send people can't decrypt it or whatever. Okay, interesting. So basically Basically it's a way to serve these files around, like without putting it into Dropbox or OneDrive or Google Drive or whatever, where it's like permanently there, it's gonna be backed up.

24:27 It's, you know, who knows like if you could ever truly delete that thing, right?

24:31 Whereas here, the maximum life of one of these files is seven days, and you can even say it can only be downloaded one time and delete it in an hour or something like that.

24:41 And of course, the encryption key is not stored with the Firefox folks.

24:44 So if it gets lost, it's not that big of a deal.

24:47 - Interesting.

24:48 I'll have to check that out.

24:49 - Yeah, it's a free, quick little thing.

24:50 You can either sign in and have larger file options or smaller ones if you want to stay anonymous.

24:57 But yeah, definitely I think it fills a cool need and it's kind of nice to see Mozilla just making the web better in that way.

25:04 It doesn't depend on Firefox.

25:05 It just happens to be made by them.

25:07 - Okay.

25:08 - Nice.

25:09 Speaking of making stuff better, do you know what I really hate?

25:11 I hate going to weather.com and I'm saying, "Oh, it looks like you're running an ad blocker.

25:17 We want to serve you crap ads from an ad network that may have malicious content and JavaScript in it, so please whitelist us." And every time I see that, I think if you...

25:28 And these are not small little blogs or little article sites.

25:33 These are CNN, The Weather Channel, major, major places, right?

25:38 And I always think, look, if you want to serve ads to me, why don't you do it on a system that is not broken, on a way that will not put my computer and my information and everything else at risk.

25:53 You could easily talk to your sponsors, put an image on your site, let people click on it, and it takes them to their offer.

26:00 But no, they want to run all sorts of retargeting and tracking, and they want to figure out, like, oh, are you a woman who is 36, who is also searched for this, right?

26:11 Like, it's really shady.

26:12 So this is not a change for us, but this is more of a make it explicit for us.

26:18 On Pythonbytes.fm and also talkpython.fm, we don't pop up these, hey, it looks like you're running an ad blocker, please stop it.

26:26 Because our ads still show when there's an ad blocker, because all they are is images, and we're not trying to retarget anyone.

26:33 Isn't that cool?

26:34 - That is very cool, yeah.

26:35 Yeah, so there's this move I've seen on the internet to talk, just sort of a pushback on that, to say, no, these are ethical ads.

26:42 You know, you see this on Read the Docs and other places.

26:44 So I put a little note under our ad saying, these ads are served ethically.

26:48 We don't track you, we don't retarget you, we don't do anything.

26:52 But here's our sponsor, if you like it, if you like the product, you wanna support us, click on it, and that will, they'll know that you came from us because of the URL, and that's all you need, right?

27:02 So I really wish all these places that say, please whitelist us, instead said, could we have a better business model where we don't have to track people and do all sorts of nefarious stuff.

27:12 So we're opting out.

27:14 - Good job.

27:15 - Yeah, thanks.

27:16 All right, well, I believe it's time to laugh a little bit.

27:19 - Yeah.

27:21 - All right, go first.

27:21 - I really like this joke that Derek Chambers submitted.

27:25 It is, what do you call it when a Python programmer refuses to implement custom objects?

27:31 - What's that, I don't know.

27:32 - Self deprivation.

27:33 And then he adds, "Sorry, that joke was really classless." - Yeah, that's pretty good, I love it.

27:39 The classless Python.

27:41 Cool, so I have another one for you, and I pretty much have an infinite supply of these now that I've pipx installed PyJokes.

27:49 So I ran this before our episode, and this one came up, said, "I had a problem, "so I thought I'd use Java.

27:55 "Now I have a problem factory." (laughing)

28:00 I love it.

28:01 Anyway, that's the jokes, and if you find yourself wanting more jokes between now and the next episode we release, you can always pipx install pyjokes and get your fix on the command line.

28:12 - Yeah, oh, here's one more.

28:14 Okay, I just ran it.

28:15 I gotta do this one also.

28:17 There's only two hard problems in computer science, cache invalidation, naming things, and off by one errors.

28:22 (laughing)

28:23 - Nice.

28:25 Yeah, there's good jokes in that pyjokes set.

28:27 I love it.

28:28 - Yeah, there's not an infinite number, so people still keep sending us jokes.

28:31 - Yeah, we're gonna hit the limit eventually.

28:33 It's gotta happen, but definitely fun.

28:35 So thank you for sending that in, Derek.

28:37 And Brian, thanks for doing this with me every week.

28:39 - Yep, thank you.

28:40 - You bet, talk to you later.

28:41 Thank you for listening to Python Bytes.

28:43 Follow the show on Twitter via @PythonBytes.

28:45 That's Python Bytes as in B-Y-T-E-S.

28:49 And get the full show notes at PythonBytes.fm.

28:52 If you have a news item you want featured, just visit PythonBytes.fm and send it our way.

28:56 We're always on the lookout for sharing something cool.

28:59 On behalf of myself and Brian Aukin, This is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.