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

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. I'll

00:16 tell you all about that shortly. Check them out at pythonbytes.fm/digitalocean and get a

00:21 $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

00:31 rapper doing the thing. Yeah, I'm going to drop it at the end of this episode.

00:34 Yeah. Anyway, no, people can't see. Yeah. Like, so I've got my microphone on a different stand. So

00:40 we'll see how it sounds. But yeah, I think it's working. All right. Yeah. Nice. All right. So

00:44 I find dictionaries sometimes get used in Python, like every now and then people will like make you

00:52 so that's fancy data structure. Yeah, definitely. One of the hard things,

00:56 and I don't have a link to this. Maybe we could drop it. But one of the things you need to do with

01:01 dictionaries is pull them apart and put them together and stuff. There's a PEP 584. It's

01:07 had the plus and minus operators to the built in dict class. Yeah, that makes a lot of sense to me. I

01:11 mean, we already have it for list. Well, not the minus, but we have the plus list makes sense because

01:17 it operators are neat. And the thing that throws me off is the massive difference between if you do

01:24 dictionary one plus dictionary two, it's different than dictionary two plus dictionary one,

01:29 because the second thing always wins. Right. If there's duplicate keys, the second one,

01:37 it's going to overwrite the first one. So you're saying that addition might not be

01:40 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. So maybe it's okay. We'll link into the pep. Actually, I think it's nice because

01:58 if you look at the alternates, the alternates are gross. Like you can unpack both dictionaries and

02:04 then create a new dictionary or you can copy one and then update it with the other that all of those

02:09 are not obvious. And, and so I think plus would be good. So we're going to link to that article,

02:15 but also Guido Van Rossum wrote an article called why operators are useful that partly talks about

02:22 this. And then also there's an email link of why apparently one of the options for combining

02:29 dictionaries was to use the pipe operator instead of plus. And so I've got a link to that too, but

02:34 actually, so this is just a, we don't know if it'll go in, it's in draft status and it just got

02:39 proposed, but I think this is a, would be a neat thing to add to Python.

02:43 Yeah. I'm honestly a little bit surprised. It's not already there. it would be nice.

02:47 I certainly prefer plus over pipe. Like pipe is not something that's commonly used in Python for

02:54 combined stuff. Maybe if this was C or something, I don't know, but, it's certainly in the Python

02:58 world plus seems like a more natural choice here. So this next one comes from Matthew Rockland,

03:04 a guy behind ask and other data sciencey things. I recently interviewed him on talk Python, but you

03:09 know, time shifting, it will be in the future when that comes out. But I was,

03:13 reading through some of his articles and found something I thought, you know, well,

03:16 at least it's super resonated with me. I don't know how your world is Brian, but mine is like a

03:21 constant stream of like inbound inquiries, requests, comments, like watch the talk Python

03:30 Twitter account at my personal Twitter account. We share watching the Python bytes Twitter account.

03:36 I have a getter channel. I'm on a couple of slacks. I'm on like Cisco teams or something like this.

03:42 Email is insane. And there's just too many places that stuff comes at me. And I spend like,

03:49 there's times where I'll take a week and I'll take a full two days off to just write email and respond

03:54 to messages. And I'm still not all the way caught up. 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,

04:04 this definitely resonates with me. Because when you get that much inbound stuff, like anything that's

04:09 transient is super hard to keep track of, right? Like at mentions on Twitter, like maybe I'll catch

04:14 them. But if I don't, like, I'm sorry, but I just, you know, it's I'd lost it. It went by in the stream

04:19 somehow on accident, or something on Slack, right? Like it's 100 messages back. And you know, I dropped

04:26 in there, I didn't check it, marked messages red and left. And now it's just gone, right? It's never

04:31 going to come back. So I feel like those kinds of things, while kind of fun and interesting and more

04:36 lively are also, you know, just adding stress and not not really positive. So Matthew wrote this cool

04:43 article said, saying why avoid Slack focused on for open source maintainers of projects,

04:49 right? Like, should we have a Slack channel for open source project? He says, no. So he says,

04:55 instead of doing something like that, I mean, I guess a Gitter channel would be basically equivalent.

05:01 So as I encourage colleagues to have technical and design conversations on GitHub or some other system

05:06 that is public, permanent, searchable and cross referenceable. What do you think?

05:10 Actually, especially for that case of open source projects, and, and those types of conversations,

05:16 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

05:22 issues and their conversations and PRs and whatnot around it are better than Slack would be because

05:27 you can engage collaborators who aren't on Slack, right? Not everyone is on Slack. But if you're working

05:34 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

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

05:49 like mine, like, hey, everybody just needs a couple of minutes of your time, every couple minutes,

05:55 you know, and it completely derails any form of productivity.

05:59 Yeah, so it's super hard. And the reason is, they'll drop in a Slack channel or some other

06:04 conversation and go, hey, why is it like this? Or just quick question about that. And it's like,

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

06:14 We talked about it for a week. Here's a whole detail, right? Also, you can serve the silent

06:19 majority. That is people who go to Google, and they type in a thing and say, I need help with this

06:24 thing. Or why does this work that way? GitHub ranks super high on Google. And those issues

06:29 often come up and you can see the whole conversation.

06:32 Oh, that's a great idea.

06:33 Yeah, the other one is encourage more thoughtful discourse. So if you're writing like one on one

06:39 or a couple of people on a Slack channel, you're willing to just throw out kind of quick,

06:43 off the cuff comments. If you're writing in a public permanent forum that's associated with

06:48 your GitHub profile, it's much more likely that you're going to write something thoughtful. And

06:53 finally, you get a cross reference issues. So you can say we talked about part of it here and part of

06:58 it over there and this other issue. And then there was this PR and then we're bringing it back here.

07:01 Slack is siloed. You can't cross reference people and conversations and things like that. So here's a

07:07 call to say enjoy Slack, chat in Slack, but don't use Slack for design decisions and other stuff,

07:15 right? Like maintainers come and go. Maybe you want to have a history of these things and not just a

07:20 transient chat stream.

07:21 Yeah. And the bigger a Slack channel gets, the more useful it is in some respects. You get answers

07:26 really quickly. But also the more it reflects like kind of just a topical party at somebody's house

07:33 with lots of conversations going on.

07:34 Right. There was a cool chat about this thing on the couch, but that doesn't, that's not the same as

07:38 like we wrote up our thoughts on that thing.

07:40 Yeah, exactly. I'll have to read this.

07:42 Yeah, it's pretty good. It's not much longer than actually what I talked about, but it's still

07:46 really helpful, I think.

07:47 Yeah.

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

07:49 That reminds me, actually. No, I had a leak in my memory. No, that's bad.

07:52 That's pretty good, actually. It's so bad it's good. I like it.

07:57 There's an article from Zendesk from YQO that's called Hunting for Memory Leaks in Python

08:04 and we've covered memory leak stuff before, but I really like this write-up. And it's specifically,

08:11 they've got, Zendesk has a bunch of machine learning in Python written. And one of the problems they run

08:18 into is some of them will have really big memory spikes or memory leaks, and they want to try to

08:24 figure that out. So this was a specific use case. So he's not covering all of the options, just some of

08:30 the tools that were used there. And I think it's cool. 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

08:42 where you can easily run, without doing anything to your code, you can run some Python code and then

08:48 get a visual graph of the memory utilization, which was cool. If you're hunting into stuff and trying to

08:54 break things around, there was a discussion of using, adding some code to your code to use,

09:00 it looks like Muppi, M-U-P-P-I.

09:02 Yeah, Muppi.

09:03 That will dump, heap dump in certain places. So if you, if you think, sometimes time really doesn't

09:09 help you too much, but you can add certain places where you think you're at a stable state,

09:13 doing a heap dump, especially if it's somewhere, something that's looping, you might be able to

09:18 catch something there. A reference to object graph or object graph to profile memory object lineage.

09:25 So objects that create other objects.

09:27 Yeah, that can be tricky because you've got, maybe you have some object, it's a class and it's got some

09:33 field, that field, it's a list. In that list, it has a bunch of objects. One of those happens to hold on

09:37 to a pointer to some other huge dictionary that you thought like should be gone, but right, there's still

09:42 some reference keeping it alive, right? So this object graph will like tell you that basically.

09:46 Yeah. Nice.

09:47 Like for example, when he dumped some of the heap dumps, some of those examples,

09:52 it's just that you've got like so many megabytes towards strings. Well, I don't know if that really

09:58 helps you too much. Having a, finding out where it came from might be helpful.

10:02 Yep.

10:02 And then he ends the article with a, with a bunch of tips, do quick feedback. If you think something,

10:07 one of the things I liked, which is probably really good is if you have a memory intensive tasks

10:12 or something you think might be the problem, separate that into a separate process so you

10:17 can debug it separately. The Python built-in PDB has a bunch of stuff that can help you as

10:22 well. And then also watch out for leaky packages because the leak might not be in yours. It might

10:28 be in your dependencies.

10:30 Yeah. You might've pip installed a memory leak for sure.

10:33 Which I was surprised that he said, for example, pandas. And I'm like, really? Pandas is like,

10:37 must be tested the heck out of it. But apparently there's some known pandas problems in some corner

10:43 cases, but oh well.

10:44 Yeah. It probably is kind of tricky with like the C layer holding onto PI object references and all

10:50 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,

10:55 so it must be a real pain in the rear. But these tools don't look that bad to work with if you need

11:00 to.

11:00 This object graph looks really cool. And it will actually create a PNG visual graph of the

11:07 relationships, which is cool. And you can even ask for back references. Like it seems like this is the

11:12 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,

11:24 a graph theory graph of all the back references to this object, which is pretty cool.

11:28 Oh, nice.

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

11:30 Yeah. Right. If you think it should have been deleted and it's not, it's because somebody's

11:34 still referencing it.

11:34 Right. So who is that? Tell me about that. I need to know about that right now.

11:37 Yeah.

11:38 Yeah. That looks really cool. It's definitely something I'd like to explore. Actually,

11:41 let me rephrase that. I don't want to explore it. I don't want to have memory leaks,

11:45 but if I do, I will find it very useful.

11:47 Yes, definitely.

11:48 There you go. Also useful, DigitalOcean. Let me tell you a cool thing that they just released.

11:53 And this came from one of the listeners. They sent me a message like, Hey, this looks really

11:57 cool. Do you know about this? So they announced this thing called the DigitalOcean Marketplace.

12:02 So the idea is that different companies and other people can create these pre-configured

12:08 virtual machines. And then you can just do one click app, install them. Like if you want a ghost

12:13 ghost blog server configured with Nginx and all that, you just click ghost blog server,

12:17 pay your $5 and now you have one.

12:20 Nice.

12:20 Or maybe you want like GitLab Enterprise, a MongoDB server, or even you can say, I want a Django server. And it'll give you Django,

12:28 Nginx, G Unicorn, Postgres, CertBot, a whole bunch of stuff pre-configured all to work together like in a few seconds.

12:34 That's pretty cool, right?

12:34 Yeah, definitely.

12:35 Yeah, yeah. So I think this is a really nice feature. You know, it's already great to run

12:40 infrastructure there. And now if you can like get it much closer to the end, it's a little bit,

12:45 I'm sure it's a Docker inspired, right? 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

12:53 who are willing to do the work to put it together. That's great.

12:55 Yeah, it's beautiful.

12:55 All right. So check them out over at pythonbytes.fm/DigitalOcean, create an account. And then once you

13:02 get into your account, there's a little marketplace tab over there. So super cool. So speaking of Docker

13:07 and all these other things, there's a cool article by Craig Kirstens, and it's called Give Me My Monolith

13:14 Back, or Give Me Back My Monolith, as opposed to a whole bunch of microservices, right? So there's

13:20 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,

13:34 and maybe it's doing all these different things. And wouldn't it be better if we could take the credit

13:38 card processing and make it its own service with its own database? If we could make the caching its own

13:45 service, its user accounts, its own service, all that kind of stuff. And then that user account part is

13:50 super simple, right? Because the whole purpose of this application is, who are you? What can you do?

13:56 Can you log in? Can you reset your password? Or something like this, right?

13:58 This seems good, yeah? Yeah. There's a lot of really good uses for this. Like,

14:02 if you have a large team of people working on a large web app, it might make more sense to break

14:08 into these small pieces and have some people in charge of each piece. I think that actually

14:13 legitimately makes a lot of sense. It's easy to bring on a junior developer who can say,

14:16 all right, I'm going to work on this caching bit or whatever. And I don't have to know the whole

14:21 thing. I just got to work on my little API. It does court, async or whatever it does.

14:25 That makes a lot of sense. But most people who are working on web apps aren't in that space of having

14:30 like 30 people on their team, right? That's really rare, right? You've gone down this rant of you're

14:35 not Google, you're not Facebook, you're not LinkedIn, right? You don't need all these patterns because you

14:39 are not them. You're a little relatively smaller company or project. Anyway, this guy feels like,

14:46 you know, that adds a lot of complexity and challenges. And he lays them out of like,

14:52 why does the world have to be so hard? Wasn't it easy before? And now it's not,

14:56 not from the article, but just a thought of mine. Like when I think of this microservice architecture,

15:02 what you're doing is you're taking code complexity, and you're moving it to infrastructure complexity.

15:07 Yeah, definitely.

15:08 Instead of having one kind of complicated bit of code, I now have 12 super simple bits of code,

15:15 but they all have to work together in like fairly complicated network environments, failover,

15:20 you know, all this kind of stuff, this topography and whatnot. So my thought is at least, you know,

15:26 like, well, which of those two things are you good at? Infrastructure or code? You know,

15:30 that drives a lot of these decisions. But he runs down a couple of things that he said

15:34 used to be simple, but now we get to revisit them, get to. So setup went from like chemistry to quantum

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

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

15:53 half a day. And now we've ventured into microservices, this onboarding time is skyrocketed,

15:58 and it's super complicated for them to understand all the moving pieces. And then the next one,

16:04 is so long for understanding our systems. You know, back when we had monolithic apps,

16:08 you had an error, it had a stack trace, you click on the hyperlink generated by your little

16:13 editor to take you to the line where the stack trace is. And now you have different services that

16:20 talk to another service that cue something on a message bus that another service pulls it out,

16:24 and then you get an error. What caused that? Right? How do you try? How do you follow that through?

16:29 How do you debug that? So it says, well, if we can't debug them, maybe we can test them talks

16:33 about the challenges of continuous integration, and whatnot, but also talks about some services

16:38 that were made into some apps that were made into microservice that are now moving back,

16:43 sort of in a reverse migration to these monoliths. And, you know, I got to say, I'm pretty sympathetic

16:48 with this. Like I, I see the value of microservices, but I also know that I'm not Google.

16:54 Right? And so, yeah, anyway, for me, I don't think this whole microservice world makes as much

17:00 sense in my space, but I don't know. What do you think?

17:02 We should go back to HTML and Perl.

17:05 That's right. Can't we just have static files? All this like logic is bust in your brain.

17:10 CGI used to be easy. No.

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

17:14 I think that there's different ways to solve problems. And I think that making sure that

17:19 you're paying attention to it, I think is a good, good idea. And make sure that people understand

17:23 that microservices are a, are sometimes it's a funny, funny, it's a shiny new thing to go learn. And,

17:31 and sometimes that's not bad if you're willing to take on the risks, but, but it is a changing

17:37 from what you know to what you don't know is a risk.

17:40 So it's definitely exciting. I mean, you can bring in Docker and Kubernetes and do all sorts of fun stuff,

17:45 but at the same time, just be aware of the trade-offs you're making.

17:48 Some of the things that it's solved are now solved by Async.

17:51 Yeah, that's true. Absolutely.

17:52 One of the things also is if you're in a single language or not. So one of the things that

17:57 microservices gives you is the different teams can do whatever language they want, as long as they

18:02 provide an interface that's compatible with everybody.

18:05 The authentication bits in Node.js, the, the caching tiers and something else. And you know,

18:10 the front ends in Python or whatever.

18:12 Yeah, definitely.

18:13 Yeah. Makes sense. Again, it's not something you will do that often when you're just a couple of people,

18:18 but if you're a big team or set of teams, then sure.

18:21 Makes a lot of sense.

18:22 Yeah.

18:22 All right. So I know of some famous laws and rules in software development, like the solid principles,

18:29 single responsibility principle, open, close principle. These are all good. You found some more

18:34 amusing ones, didn't you?

18:35 Yeah. Some of them are serious and some are amusing. 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, but it's the famous laws of software development.

18:48 And there are 13 listed. I think I counted that many. I'm not going to read all 13. I guess it was written in 2017. It's not that old.

18:57 But okay, so Hofstetter's law, which is great. It always takes longer than you expect, even when you take into account Hofstetter's law. So it's self-referencing.

19:07 I love it. Yeah, I love it. There's some many good ones here.

19:11 So that's just funny. There's Conway's law, which it's not supposed to be funny, but it's sometimes depressing. Any piece of software reflects the organizational structure that produced it.

19:22 Yeah, I think that's true.

19:24 Like microservices are great for lots of teams. One team, one monolith or something. I don't know. But I've seen that before. Also, the hierarchy of different teams shows up in the software as well. 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. That's great.

19:54 Yeah. And then the 90-90 rule, which I haven't actually heard before, but it's just hilarious. Have you heard this before?

20:02 No.

20:02 The first 90% of the code takes 10% of the time. The remaining 10% takes the other 90% of the time.

20:08 That sounds about right to me. 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. I noticed that some people, a guy named Corey 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:30 And then someone also responds, maybe its omission was a conscious choice to invoke it.

20:39 That's awesome.

20:39 Yeah, it's really good. There's a bunch of nice ones in there.

20:42 Yeah, that's like real though. I mean, the best way to get people to help you on the internet is to start blogging the wrong stuff.

20:48 Yeah, enable comments and start writing. That's cool.

20:54 I got a quick one to round it out here. We talked about a plugin architecture before for building plugins that ran like within your app.

21:01 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 One of 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.

21:24 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.

21:42 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:57 Yeah.

21:58 It's pretty cool.

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

22:04 So, that's pretty cool.

22:05 It talks about what you have to do to get it running.

22:07 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.

22:24 It's pretty cool.

22:24 Nice.

22:25 Yeah.

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

22:29 So, yeah.

22:30 Anyway, it's pretty neat.

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

22:34 All right.

22:35 Well, that's it for official items.

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

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

22:44 This will go out as Test Encode 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...

22:57 Yeah.

22:57 He's one of the original founders of it, right?

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

23:01 Yeah.

23:01 Is that right?

23:01 Andy Hunt and Dave Thomas wrote the Pragmatic Programmer.

23:05 And that was released in 99.

23:06 And then in 2003, they formed their own publishing company.

23:09 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:19 And 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...

23:27 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'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

23:49 project to make the web better, right?

23:50 So here's what it does is it lets you share files securely, large files, like up to two and

23:58 a half gigs per file.

24:00 And it does end to end encryption, where the decryption key is actually stored in the

24:09 URL.

24:09 So if you don't share the URL, like even the Firefox Send people can't decrypt it or whatever.

24:14 Okay.

24:14 Interesting.

24:15 So basically, it's a way to serve these files around like without putting it into Dropbox

24:21 or OneDrive or Google Drive or whatever, where it's like permanently there, it's going to be

24:26 backed up.

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

24:30 Whereas here, the maximum life of one of these files is seven days.

24:35 And you can even say it can only be downloaded one time and delete it in an hour or something

24:39 like that.

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

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

24:47 Interesting.

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

24:49 Yeah.

24:49 It's a free, quick little thing.

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

24:55 say and stay anonymous.

24:56 But yeah, definitely, I think it fills a cool need.

24:59 And it's kind of nice to see Mozilla just, you know, making the web better in that way.

25:03 And it's, it doesn't depend on Firefox.

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

25:07 Okay.

25:07 Nice.

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

25:10 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 and that may have malicious content and

25:22 JavaScript in it.

25:23 So please whitelist us.

25:25 And every time I see that, I think if you, and these are not small little blogs or like

25:31 little article sites.

25:33 These are CNN, the weather channel, like major, major places.

25:38 Right.

25:38 And I always think, you know, look, if you want to serve ads to me, why don't you do it on

25:43 a system that is not broken on a way that will not put my computer and my information and everything

25:51 else at risk?

25:52 You could easily talk to your sponsors, put an image on your site, let people click on

25:59 it and it takes them to their offer.

26:00 But no, they want to run, you know, all sorts of retargeting and tracking.

26:04 And they want to figure out like, oh, are you, you are, are you a woman who is 36, who is

26:09 also search 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 on pythonbytes.fm

26:20 and also talk python.fm.

26:22 We don't pop up these.

26:24 Hey, it looks like you're running an ad blocker.

26:25 Please stop it.

26:26 Because our ads still show when there's an ad blocker, because all they are is images.

26:31 We're not trying to retarget anyone.

26:33 Isn't that cool?

26:33 That is very cool.

26:34 Yeah.

26:34 Yeah.

26:35 So there's this move I've seen on the internet to talk, just sort of a pushback on that to

26:40 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.

26:49 We don't retarget you.

26:50 We don't do anything.

26:51 But here's our sponsor.

26:53 If you like it, if you like the product, you want to support us, click on it.

26:56 And that will, that will, they'll know that you came from us because of the URL.

27:01 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

27:07 have a better business model where we don't have to track people and do all sorts of nefarious

27:12 stuff?

27:12 So we're opting out.

27:14 Good job.

27:14 Yeah.

27:14 Thanks.

27:15 All right.

27:15 Well, I believe it's time to laugh a little bit.

27:19 Yeah.

27:20 All right.

27:21 Go first.

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

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

27:31 What's that?

27:31 I don't know.

27:32 Self-deprivation.

27:33 And then he adds, sorry, that joke was really classless.

27:37 Yeah, that's pretty good.

27:39 I love it.

27:39 The classless, classless Python.

27:41 Cool.

27:41 So I have another one for you.

27:43 And I'm, I pretty much have an infinite supply of these now that I've pip X installed PyJokes.

27:48 Okay.

27:49 So I ran this before our episode and this one came up, said, I had a problem.

27:53 So I thought I'd use Java.

27:54 Now I have a problem factory.

27:59 I love it.

28:00 Anyway, that's, that's the jokes.

28:03 And if you, if you find yourself wanting more jokes between now and the next episode release,

28:08 you can always pip X install PyJokes and, you know, get your fix on the command line.

28:12 Yeah.

28:13 Oh, here's one more.

28:14 Okay.

28:14 I just ran it.

28:15 I got to do this one also.

28:16 There's only two hard problems in computer science.

28:19 Cash invalidation, naming things and off by one errors.

28:22 Nice.

28:24 Yeah.

28:25 There's good jokes in that PyJokes set.

28:26 I love it.

28:27 Yeah.

28:27 There's not an infinite number.

28:29 So people still keep sending us jokes.

28:31 We love them.

28:31 Yeah.

28:31 We're going to hit the limit eventually.

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

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

28:38 Thanks for doing this with me as every week.

28:39 Yep.

28:40 Thank you.

28:40 You bet.

28:40 Talk to you later.

28:41 Thank you for listening to Python Bytes.

28:43 Follow the show on Twitter via at Python Bytes.

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

28:48 And get the full show notes at pythonbytes.fm.

28:51 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:58 On behalf of myself and Brian Okken, this is Michael Kennedy.

29:01 Thank you for listening and sharing this podcast with your friends and colleagues.