Python Bytes - #122 Give Me Back My Monolith

Episode Date: March 22, 2019

Topics covered in this episode: [play:0:55] Combining and separating dictionaries [play:3:02] Why I Avoid Slack [play:7:57] Hunting for Memory Leaks in Python applications [play:13:06] Give Me Back My Monolith [play:18:23] Famous Laws Of Software Development [play:20:54] Beer Garden Plugins Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/122

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your butts. This is episode 122, recorded March 20th, 2019. I'm Michael Kennedy. And I'm Brian Ocken. And this episode is brought to you by DigitalOcean. They have some big news to share with you. I'll tell you all about that shortly. You can check them out at pythonbytes.fm slash DigitalOcean and get a $100 credit for new users.

So, tell you more about that later. Brian, how are you doing? 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. Yeah, I'm going to drop it at the end of this episode. Yeah. Anyway, no, things are good.

People can't see. Yeah, like, 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. Yeah. Nice. 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. Yeah, definitely. 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. There's a PEP 584. It's to add the plus and minus operators to the built-in dict class. Yeah, that makes a lot of sense to me. I mean, we already have it for list. Well, not the minus, but we have the plus. 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 right if there's duplicate keys the second one it's going to overwrite the first one so you're saying that addition might not be commutative that might be a problem well maybe but i mean like strings are like that like if you've got i don't know that's true you don't get the same result of like hello plus world or world plus hello yeah exactly so maybe it's okay we're linking to the pep actually i think

it's nice because if you look at the alternates the alternates are gross like you can unpack both dictionaries and then create a new dictionary, or you can copy one and then update it with the other. All of those are not obvious. And so I think plus would be good. So we're going to link to that article. But also Guido van Rossum wrote an article called Why Operators Are Useful that partly talks about this. 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. And so I've got a link to that too. 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 would be a neat thing to add to Python. Yeah, I'm honestly a little bit surprised it's not already there. It would be nice. I certainly prefer plus over pipe. Pipe is not something that's commonly used in Python for combining stuff. 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.

So this next one comes from Matthew Rockland, a guy behind Dask and other data sciencey things i recently interviewed him on talk python but you know time shifting it will be in the future when that comes out but i was reading through some of his articles and found something i thought you know well at least it's super resonating with me i don't know how your world is Brian, but mine is like a constant stream of like inbound inquiries, requests, comments, like watch the talk Python Twitter account at my personal Twitter account. We share watching the Python bites Twitter account. I have a getter channel. I'm on a couple of slacks. I'm on like Cisco teams or something like this. Email is insane. And there's just too many places that stuff comes

at me. And I spend 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. And I'm still not all the way caught up. It's like, it's really a problem. So when I read this article called why I avoid Slack by Matthew Rocklin, I'm like, Oh yes, this definitely resonates with me because when you get that much inbound stuff, like anything that's transient is super hard to keep track of, right? Like at mentions on Twitter, like maybe I'll catch 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 somehow on accident or something on Slack, right? Like it's a hundred messages back and I dropped in there and I didn't check it,

marked the messages red and left and now it's just gone, right? It's never gonna come back. So I feel like those kinds of things, while kind of fun and interesting and more lively are also just adding stress and not really positive. 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 he says no so he says uh instead of doing something like that i mean i guess a getter channel would be basically equivalent says i encourage colleagues to have technical and design conversations on GitHub or some other system that is public, permanent, searchable,

and cross-referenceable. What do you think? Actually, especially for that case of open source projects and those types of conversations, I think I totally agree.

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. 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. But most people can get to the web and they can read or even Google search and then find some kind of thing. Also, you can record the conversation because it sounds like his life's a little bit like mine. Like, hey, everybody just needs a couple of minutes of your time every couple of minutes. And it completely derails any form of productivity.

So it's super hard. And the reason is they'll drop in a Slack channel or some other conversation and go, hey, why is it like this? Or just quick question about that. And it's like, if you have it in an issue and discussed or something, you can say, that's issue 17725. We talked about it for a week. Here's a whole detail, right? Also, you can serve the silent majority. 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, GitHub ranks super high on Google. And those issues often come up. And you can see the whole conversation.

That's a great idea. Yeah. The other one is encourage more thoughtful discourse. So if you're writing like one-on-one or a couple of people on a Slack channel, you're willing to just throw out kind of quick off-the-cuff comments. If you're writing in a public permanent forum that's associated with your GitHub profile, it's much more likely that you're going to write something thoughtful. And finally, you get a cross-reference issues. 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. Slack is siloed. You can't cross-reference people and

conversations and things like that. So here's a call to say, enjoy Slack, chat in Slack, but don't use Slack for design decisions and other stuff, right? Like maintainers come and go. Maybe you want to have a history of these things and not just a transient chat stream. Yeah. And the bigger a Slack channel gets, the more useful it is in some respects. You get answers really quickly. But also, the more it reflects like kind of just a topical party at somebody's house with lots of conversations going on. 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. Yeah, exactly. I'll have to read this. Yeah, it's pretty good. It's not much longer than actually what I talked about, but it's still really helpful, I think. Yeah, exactly. Oh, I'll have to read this. Yeah, it's pretty good. It's not much longer than actually what I talked about,

but it's still really helpful, I think. Yeah. What's the next one you got for us? That reminds me, actually. No, I had a leak in my memory. No, that's bad. That's pretty good, actually. It's so bad, it's good.

I like it. There's an article from Zendesk from Y.C. Yao that's called Hunting for Memory Leaks in Python Applications. And we've covered memory leak stuff before, but I really like this write-up.

And it's specifically, they've got, Zendesk has a bunch of machine learning in Python written, 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. So this was a specific use case. So he's not covering all of the options, just some of the tools that were used there. And I think it's cool.

I didn't know some of these things were around. So 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 you can run some python code and then get a visual graph of the memory utilization which is cool 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-P-Y. Yeah, Muppy. That will dump, heap dump in certain places. So if you think, sometimes time really doesn't help you too much, but you can add certain places where you think you're at a stable state doing a heap dump,

especially if it's something that's looping, you might be able to catch something there. A reference to object graph or object graph to profile profile memory object lineage so objects that create other objects 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 it's a list in that list it has a bunch of objects one of those happens to hold on to a pointer to some other huge dictionary that you thought like should be gone but right there's still some reference keeping it alive right so this object graph will like tell you that basically yeah nice like for example when he dumped some of the heap dumps some of those examples it's just you've got like so many megabytes towards strings well i don't know if that really helps you too much having a finding out where it came from

might be helpful yep and then he ends the article with a bunch of tips. Do quick feedback. 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. The Python built-in PDB has a bunch of stuff that can help you as well. And then also watch out for leaky packages because the leak might not be in yours. It might be in your dependencies. Yeah, you might have pip installed a memory leak for sure. Which I was surprised that he said, for example, pandas. And I'm like, really?

Pandas must be tested the heck out of it. But apparently there's some known pandas problems in some corner cases. But oh well. Yeah, it probably is kind of tricky with like the C layer holding on to PyObject references and all sorts of funkiness, right? 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. But these tools don't look that bad to work with if you need to.

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?

And you can say, draw me a graph or not like a mathematical graph, not a parabola type graph, a graph theory graph of all the back references to this object which is nice yeah so you can ask it in both directions yeah right if you think it should have been deleted and it's not it's because somebody's still referencing it right so who is that tell me about that i need to know about that right now yeah yeah that looks really cool it's definitely uh something i'd like to explore actually let me rephrase that i don't

want to explore it i don't want to have memory leaks. But if I do, I will find it very useful. Yes, definitely. There you go. Also useful, DigitalOcean. Let me tell you a cool thing that they just released. And this came from one of the listeners. They sent me a message like,

hey, this looks really cool. Do you know about this? So they announced this thing called the DigitalOcean Marketplace. 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.

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. Nice. 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 nginx g unicorn postgres certbot a whole bunch of stuff pre-configured all to work together like in a few seconds that's pretty cool right yeah definitely yeah yeah so i think this is a really nice feature you know it's it's already great to run infrastructure there and now if you can like get it much closer to the end, it's a little bit, I'm sure it's a Docker inspired, right? It seems like that, but for their infrastructure,

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. Yeah, that's beautiful. All right. So check them out over at pythonbytes.fm slash digital ocean, create an account.

And then once you get into your account, there's a little marketplace tab over there. So super cool. So speaking ofcker and all these other things there's a cool article by craig kirstens and it's called give me my monolith back or give me back my monolith as opposed to a whole bunch of microservices right so there's been a lot of hype excitement i don't know take your choose your side of the fence around microservices. 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. And wouldn't it be better if we could take the credit card processing and make it its own service with its own database? If we could make the caching its own service, its user accounts, its own service, all that kind of stuff. And then that user account part is super simple, right? 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? That seems good,

yeah? Yeah. There's a lot of really good uses for this. 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. I think that actually legitimately makes a lot of sense. It's easy to bring on a junior developer who can say, all right, I'm going to work on this caching bit or whatever, and I don't have to know the whole thing.

I just got to work on my little API. It does court async or whatever it does. That makes a lot of sense. But most people who are working on web apps aren't in that space of having like 30 people on their team, right? That's really rare, right? You've gotten down this rant of you're not Google, you're not Facebook, you're not LinkedIn, right?

You don't need all these patterns because you are not them. You're a little relatively smaller company or project 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 wasn't it easy before and now it's not not from the article but just a thought of mine 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. Yeah, definitely. 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 like fairly complicated network environments, failover, you know, all this kind of stuff, this topography and whatnot. So my thought is at least, well, which of those two things are you good at, infrastructure or code?

That drives a lot of these decisions. But he runs down a couple of things that he said used to be simple, but now we get to revisit them. Get to. So setup went from chemistry to quantum mechanics. A lot of this has to do with bringing new people onto a team or junior developers and things like that. So it says onboarding a new engineer,

at least for the initial environment, used to be like half a day. 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. And then the next one is so long for understanding our systems. Back when we had monolithic apps, you had an error. It had a stack trace. You click on the hyperlink generated by your little editor

to take you to the line where the stack trace is. And now you have different services that talk to another service that cue something on a message bus that another service pulls it out, and then you get an error. What caused that? How do you follow that through? How do you debug that? So it says, well, if we can't debug them, maybe we can test them talks about the challenges of continuous integration, and whatnot, but also talks about some services that were made into some apps that were made into microservices are now moving back, sort of in a reverse migration to these monoliths.

And, you know, I got to say, I'm pretty sympathetic with this. Like I see the value of microservices, but I also know that I'm not Google, right? 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? We should go back to HTMLtml and pearl that's right can't we just have static files all this like logic is cgi used to be easy uh no no it actually was never ever easy 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 good idea and make sure that people understand that microservices are a, sometimes it's a funny, it's a shiny new thing to go learn. And sometimes that's not bad if you're willing to take on the risks, but changing from what you know to what you don't know is a risk. It's definitely exciting. 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. Some of the things that it's solved are now solved by async.

Yeah, that's true. Absolutely. One of the things also is if you're in a single language or not. 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 the authentication bits in node.js the the caching tiers and something else and you know the front ends in python or whatever yeah definitely yeah makes sense 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 yeah 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. You found some more amusing ones, didn't you? Yeah. Some of them are serious and some are amusing. All of them have kind of a little bit of truth. 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 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 but uh 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. I love it. Yeah, I love it. There's some money good ones here. So that's just funny. There's a 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. Yeah, I think that's true. 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. Sounds like a quote from the Despair calendars or posters. That's great. Yeah. And then the 90-90 rule, which I haven't actually heard before, but it's just hilarious. Have you heard this before? No. The first 90% of the code takes 10% of the time. The remaining 10% takes The first 90% of the code takes 10% of the time. The remaining 10% takes the other 90% of the time. 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. So the comments are good too. I noticed that some people guiding Corey through 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. And then someone also responds, maybe its omission was the consul's choice to invoke it. That's awesome. Yeah, it's really good. There's a bunch of nice ones in there. Yeah, that's like real though. I mean, the best way to get people to help you on the internet is start blogging the wrong stuff.

Yeah, enable comments and start writing. Yeah, that's cool. 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. So basically ways to let people interface like simple bits of code into your other systems and version plugins and all that.

There's another one called beer garden plugins, which is pretty fun. And one of the listeners suggested this. So the idea is it's a framework that will convert your functions. These are like regular Python scripts. They don't know anything about the web or plugins or whatever.

Convert those into composable,able production ready services as in restful http services with minimal overhead 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 it will just go serve that. And it even does cool stuff like it does swagger documentation of the services and whatnot. So yeah, it's a pretty interesting little quick way to convert code that was not meant to be a service into services.

Oh, very cool. Yeah, it's pretty cool. It's apparently based on MongoDB, RabbitMQ, and it supports modern Python. So that's pretty cool. 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. 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. And then you can give it these

little apps and whatnot. It's pretty cool. Nice. Yeah, so I think the idea is you run your code and it plugs into the server there. So yeah, anyway, it's pretty neat. People can check that out if that sounds like something they're looking for. All right, well, that's it for official items. Anything else you want to cover here at the end?

Just had a really cool interview the other day. This will go out as a test and code 69, which should be available for everybody before you listen to this. But it was with Andy Hunt, who is now at the head of Pragmatic Programmer. Yeah, he's one of the original founders of it, right? Him and one other guy, I think. Yeah, Andy Hunt and Dave Thomas wrote the Pragmatic Programmer, and that was released in 99. And then in 2003,

they formed their own publishing company and they've been going strong. And the PyTest book was under their publishing company. And so now Dave doesn't have a play an active role in the publishing anymore, but Andy does.

And so it's a really cool conversation. Andy was also one of the original signers of the Agile Manifesto. And so we talk a lot about. Oh, right. That's cool. Yeah, we talk a lot about that and quite a few other things. So that's a fun thing to listen to.

Excellent. I'm definitely going to check it out when you release it. That's a good one. How about you? So I have two quick things to share with you. First, there's this thing called Firefox Send. Have you heard of this? I have not.

Yeah. 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. 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 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 it's a way to serve these files around without putting it into Dropbox or OneDrive or Google Drive or whatever where it's like permanently there. It's going to be backed up. It's, you know, who knows, like if you would ever truly delete that thing, right?

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. And, of course, the encryption key is not stored with the Firefox folks. So, like if it gets lost, you know, it's not that big of a deal. Interesting is not stored with the firefox folks so like if it gets lost you know it's not that big of a deal interesting i have to check that out yeah it's a free quick little thing you can either sign in and have a larger larger file options or smaller ones if you want to say and stay anonymous but yeah definitely i think it fills a cool need and it's kind of nice to see mozilla just you know making the web better in that way and it's it doesn't

depend on Firefox. It just happens to be made by them. Nice. Speaking of making stuff better, do you know what I really hate? I hate going to weather.com and them saying, oh, it looks like you're running an ad blocker. 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 and these are not small little blogs or like little article sites these are cnn the weather channel like major major places right and i always think you know 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? 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. But no, they want to run all sorts of retargeting and tracking. And they want to figure out like, Oh, are you, you are, are you a woman who is 36, who is also search for this, right? Like it's really shady. So this is not a change for us. But this is more of a make it

explicit for us on Python bytes.fm. And also talk Python.fm. We don't pop up these, hey, it looks like you're running an ad blocker, please stop it 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 in that cool. That is very cool. Yeah. Yeah. So there's this move I've seen on the internet to talk. This is sort of a pushback on that to say, no, these are ethical ads. You know, you see this on read the docs and other places. So I put a little note under our ad saying, these ads are served ethically, we don't track you, we don't retarget you, we don't do anything. But here's our sponsor, if you like it, if you like the product, you want to support us, click on it. And that will, that will, they'll know that you

came from us because of the URL. And that's all you need, right? 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. So we're opting out. Good job. Yeah. Thanks. All right. Well, I believe it's time to laugh a little bit. Yeah. All right. Go first. I really like this joke that Derek Chambers submitted. It is, what do you call it when a Python programmer refuses to implement custom objects? What's that? I don't know. Self-deprivation.

And then he adds, sorry, that joke was really classless. Yeah, that's pretty good. I love it. The classless, classless Python. Cool. So I have another one for you. And I pretty much have an infinite supply of these now that i've pip x installed py jokes okay so i ran this before ours episode and this one came up said i had a problem so i thought i'd use java now i have a problem factory

i love it anyway that's uh that's the jokes and jokes. And if you find yourself wanting more jokes between now and the next episode release, you can always pipx install PyJokes and get your fix on the command line. Yeah. Oh, here's one more. Okay. I just ran it. I got to do this one also. There's only two hard problems in computer science.

Cache invalidation, naming things, and off by one errors. Nice. Yeah, there's good jokes in that PyJokes set. I love it. Yeah, there's not an infinite number, so people still keep sending us jokes. We love them. Yeah, we're going to hit the limit eventually. It's got to happen, but definitely fun.

So thank you for sending that in, Derek. And Brian, thanks for doing this with me every week. Yep, thank you. You bet. Talk to you later. Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S.

And get the full show notes at PythonBytes.fm. If you have a news item you want featured, just visit PythonBytes.fm and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Ocken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.