Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 368, recorded January 23rd, 2024.
I'm Michael Kennedy.
And I'm Brian Okken.
This episode is sponsored by us.
Support us by checking out our work.
We do lots of things.
We have many, many courses over at Talk Python Training.
We have the complete pytest course.
We have Patreon supporters, which you can become one in the show page, the episode page.
And connect with all of us, all three of us, Brian, me, and the show over on fosstodon.org.
And if you want to be part of the live episode, it's pythonbytes.fm/live.
Usually Tuesdays at 10 a.m.
We've changed it.
We have a new time, Brian.
New time, yes.
New time.
So that's the plan for now until it's not the plan.
But we love it when people show up for the show.
And now let's dive right in.
Go for it, Brian.
What you got?
Well, I wanted to talk about debugging a little bit because we've got a blog post.
Actually, it's a blog post and really a newsletter episode from Eunice.
It's a site called Syntax Error.
And it looks like it's a newsletter about debugging, which is kind of nice.
And somehow I missed it in the past year.
It started, it looks like February of 2023.
But we're on episode 11 or issue 11.
And it's kind of a summary.
So it's pretty neat.
Talking about debugging Python.
I really love just the concept of this, of the newsletter, but also just it's really good content in a small thing.
So what is he talking about?
So if you're debugging some code, the first thing you got to do is you got to get in the right mindset.
And then you can use some tools.
So I'm glad that he starts that with the mindset.
Just talking about mindset.
Take a break.
Stop, breathe, and then come back to it.
And this breaking away from you're frustrated with your code to clearing your head is really important.
Don't skip that.
I think it's essential.
Go grab a cup of coffee or something.
And then using a step-by-step process.
Don't just, I mean, it's hard to say not to just jump to the thing that you think might be broken and try to fix it.
Okay, after you did that and it didn't work, then come back to this.
And then do a step-by-step methodical process.
And I think it's very helpful.
There's a little comic here, which is great, of Gru from, oh, I forget the name of the movie.
But he says, need to debug an issue, set a breakpoint to get started.
The breakpoint never hits.
It's pretty funny.
Anyway, so being methodical about it will help.
And then I'm glad he brought this up, talking about rubber ducking or talking to ducks.
And this is an age-old, and I don't know if it ever actually happened in my computer science classes in our lab.
We had a stuffed monkey that if you asked the TAs or the grad students that were hanging out in the lab for help, they would say, ask the monkey first.
And so this is just essentially getting a description of the bug, the situation, the background information in your mind in a way that you can say it out loud will sometimes completely solve your problem.
It's an incredible tool.
And one of the things that was interesting is he talks about brain dump as an alternative solution is write it on paper.
If you're not the kind of person that verbalizing helps, writing it on paper might help.
Okay.
Now let's get into the tools, the tools that help with debugging.
And I used to feel guilty about this all the time, but I reach for print all the time.
So, or some sort of log.
They said, don't do print.
Come on.
So his technique is to start with print because it's low friction.
Everybody knows how to do it.
Plus we have f-strings now.
And with the, with the equal sign, if you do like curly braces and then their variable name with the equal, it just says it's great.
So anyway, it's, it's really easy to debug print, which is good.
And it's, it's a little friction.
It's easy to add.
Snoop is a, is a interesting, cool toolkit that he talks about for helping to see what's going on within your code.
At each step.
It's pretty cool tool as well.
Let's just quickly go through some of the other two.
That's, those are the two like printing logging sort of things.
There's also ice cream that he mentions.
And there's debuggers.
So talking about debuggers, this is not, interestingly, he doesn't mention like IDEs, which that's what I usually, usually reach for is like either a PyCharm or VS Code debugger.
But sometimes you don't have access to those.
If you've like, if you're SSH into something or whatever.
So invoking, being able to use PDB.
I think he talks about PDB, which is the Python debugger.
I, I learned how to actually had learned how to do this mostly just to talk about using PDB with pytest for the book.
And now I use it once in a while because sometimes it's, it's, it's even more convenient, especially when using PDB with talks.
It's great.
So PDB, IPDB, which is an interactive REPL sort of thing.
PUDB, which is kind of like a, it got panels and stuff.
It's a nice terminal UI.
Web PDB, which the same thing within a browser.
It's kind of nice.
Bird's eye is something I hadn't seen before, which is kind of cool talking about bird's eye.
It has these kind of neat diagrams with like boxes around stuff as things change.
It's a interesting interface.
It's pretty, yeah.
Yeah.
I don't know if it's for me, but if it resonates with you, that's great.
It might be worth trying on a, on a project.
Kind of neat.
Anyway, and then a quick shout out to some Django tools.
So if you're, if you're debugging Django, there's the debug Django tool, the Django debug toolbar and a, an extension for VS Code called Colo.
So anyway, some great advice about debugging specifically Python, but really kind of a lot of this advice applies to everything.
So nice.
And kind of nice that there's a newsletter around that.
Yeah, it is a nice newsletter.
There's something kind of good about permanency of written stuff rather than, I mean, what we do is great.
And I think it connects with a lot of people, but it's, it's harder to go back to it and like search it.
So, yeah, and I kind of like the idea of, I know that a lot of newsletter, newsletters, software like Substack and things like that can keep it around for you in medium.
But I like the idea of somebody doing a newsletter and putting the newsletter things on blog posts at the same time for people to reach out to.
So neat.
I might have more to say about that later.
But I also have something to say about what you just pointed out, what you just talked about.
And I have just done a new project.
I have some things that I've been working on.
You know, I already talked about the leave in the cloud and the interview with Mark Persinovich and how that inspired me to kind of rethink how our infrastructure goes.
And it is just paying so many dividends.
I'm going to talk about it in some interesting ways.
And as part of that, I've had to write a little bit of new software and I'm like, I need some logging.
I'm going to try Log Guru.
Log Guru?
No, no.
The G is combined.
And wow, is this a nice piece of logging software.
So what I would suggest, Brian, if you're feeling the print coming on, if you're like, oh, I'm going to print this.
I'm going to print my way to this bug solving this problem.
Maybe consider Log Guru-ing your way.
You just create the Log Guru thing and you can say use color and all of that.
And it will also do print statements just to sys out, right?
But you can see like right here on their homepage, it says like how to do like color and stuff like that.
And then if you just logger.info or whatever, it'll print it out, but way more structured and with color.
And then if there's an exception, you're going to like say print E or the exception.
You could just say logger.exception and it will create the traceback showing the local variables at every step.
So instead of having to jump into the debugger, you can just print your way to like, oh, here's the entire call stack and all the values.
That's pretty cool.
I super, super recommend it.
I've been using Log Book.
I'm a Log Guru fan.
I'm resisting the urge to go and rewrite all my logging for all of my things because it's not that productive.
But boy, my logging look cool.
All right.
That's not what I want to talk about.
But I want to talk about things that were kind of inspired by that.
So first, I want to talk about Umami.
And this has a Python loopback really, really quickly here.
But let's start from the outside in.
Okay?
Okay.
So Brian, I set up Umami at umami.is, which is like Google Analytics, but not evil.
That's awesome, right?
So the idea is it's privacy preserving.
It is GDPR and CCPA compliant.
It's open source.
And you can buy it as a service.
Right?
I can go over here and say pricing.
For nine bucks, some period, I will get some number of websites.
And it'll give me, you know, analytics like Google Analytics for my site.
Right?
That's pretty cool.
Yeah.
But what's better.
The problem with that is it's still third-party JavaScript.
Even if they don't use cookies, but it's still third-party JavaScript.
And by way of that, it gets blocked a lot, especially by the developer crowd.
Right?
And I'm not, that's not a criticism.
I'm like on the high end of blocking.
Right?
Like, I'm like, no, no, we're not doing this.
No, you don't need this kind of stuff.
Right?
But if you run it on your own infrastructure, under your own domain, the app is doing nothing
nefarious.
It's talking to itself for some things and it's going back and talking to itself for other
forward tracking.
So this is really, really easy to run under Docker as a multi-tier Docker app on your own
domain, which is what I'm doing.
And so now I can have some really nice insights into what are happening on Pythonbytes.fm,
the courses, all that, without sharing any data with anyone ever and without being blocked
because it's just code running on our own server, just like everything else on the website.
That's cool.
Awesome.
Right?
The problem is if you go over here and you're like, awesome.
Okay.
Developers.
This is me.
I'm a developer.
Let's go.
Let's take me to the docs.
And cool.
Look, there's an API section at the end down here.
Okay.
And now look, there's an API client.
I don't want to write code.
That's great.
NPM install API client.
Oh, crap.
The only API client for Umami is JavaScript or TypeScript.
I don't know.
It doesn't matter.
It runs in JavaScript.
It's not Python, right?
Actually, TypeScript.
This whole app is basically TypeScript, right?
That was until this week.
So some guy down here named Michael released this thing called Umami-Analytics, put it on
PyPI, go over to the homepage.
And you can see it talks about how it works.
Basically, one of the things that's really nice about Umami over certain other systems,
like plausible.io is one that has been thrown around in the same space and it's similar,
is that with Umami, you can send custom events that have nothing to do with direct web actions.
So for example, suppose somebody signs up for an account and then opts into your newsletter.
You just talked about newsletters.
And then that's a double opt-in.
So they get an email, which then goes back to some other place where they actually say,
yes, I really, really do want to get this.
It'd be cool if you could know, okay, that happened, right?
And so the whole point of this Python library is to add Python-based events to your analytics
on top of just what the JavaScript is like.
You're on this page and then you went to that page and you came from this place and you're
on this browser.
It'll let you send in things like somebody bought a course, somebody confirmed their email
address, somebody logged in with the mobile app for the first time.
Like all of these things that have no straight HTML JavaScript experience, you can just pump
those in right alongside all of your other analytics.
Still all privacy preserving, not sharing data with anybody, no retargeting, no cookies, none
of that crap.
Just, I want to view into what's happening in my app.
So this thing lets you add a custom event.
And also you can like register multiple sites.
You can list them out.
It has both synchronous and asynchronous programming models based on Pydantic and HTTPX.
And yeah, super easy to use.
Very cool.
Isn't that neat?
Yeah.
So recommend Umami, but one of the problems with Umami is there's not really a great client
to like round that out.
So check out the one that I created.
Nice.
This is going to be a theme this week.
So apparently we didn't plan this.
Like, no.
Yeah.
If we did, we would have both worn blue shirts.
Oh, wait.
We're both wearing blue shirts.
We are wearing blue shirts.
Oh, my tent is off though.
All right.
Over to you.
I had an extra from the last one because there was a link from Eunice that about fstrings.help,
which I think I've seen before, but I kind of forgot about.
But just looks like a Jupyter notebook about fstrings, which is okay.
Well, I'll have a link in the show notes.
I wanted to mention that.
So I did an open source thing also.
So I released a thing called pytest Suite Timeout.
And there's a little, I guess, a story around it.
So what happened was I recorded an episode of Python Test about repeating tests.
And I noted that pytest Repeat doesn't have a timeout.
But pytest Flake Finder does have a timeout.
And it'd be kind of neat if repeat had a timeout also.
And by timeout, I mean, there's like the entire suite.
So if I want to say like, hey, I want to run like, I have an example.
I want to run my suite like a thousand times or a test a thousand times because I'm looking
for flaky behavior or something.
But I want to make sure that it only runs like 10 minutes.
Then I want, that's the behavior I wanted.
Like the entire suite, not individual tests, but the entire suite to only be like 10 minutes
or an hour or whatever.
That's the behavior I want.
And I couldn't figure it out.
And so I wrote this.
Now, it could have been in pytest Repeat.
But while I was thinking about it, I thought, well, I have other times where like I've got
parameterized tests that are like big lists, like 20 different waveforms or something that
I'm passing through something.
And sometimes I don't really know how long those are going to take.
It'd be kind of nice to be able to say, hey, I want to make sure that the whole suite isn't
longer than so much.
So I made it its own plugin.
So here it is.
pytest Sweet Timeout.
You just pass it a flag.
It's still, I just sort of did this a couple of days ago.
And I think there might be bugs in it.
So I guess don't put it in production yet.
That's why I never did.
Well, production.
Yeah.
It's a little lower bar for test production rather than I took down the website.
It just took down CICD is possibly what you might take down, which is still a problem.
Yeah.
Well, I think I just ran across this morning.
I was playing with it.
At least one use case, the word doesn't actually time out.
But so that's the behavior when it fails is it won't time out.
But we'll work with it and fix it.
That's super cool.
One of the, I announced it on Mastodon.
And Mike Felder said, that's pretty cool.
But have you tried pytest-Timeout?
Which, yeah, there's another one called Timeout.
And it seems like that should be like what I want.
It's just the timeout is the pytest timeout is per test.
It just makes sure that individual tests themselves don't run longer than a certain amount.
And this is kind of like, you should know this, right?
Probably about how long your tests run.
But there's, it's Python and software.
So sometimes infinite loops happen or some use case that you never break out of.
And also, like, just the fact that it's taking way longer than it should might be something you want to trigger as an error, right?
Like, if for some reason you want to talk to a database or an API directly and you're not stubbing it out, if those things are down, it could take 20 seconds for them to say, nope, every single time.
And you might want to say, if this ever takes more than five seconds, something's wrong and just kill it.
You know what I mean?
Right?
Like, I think that would even be reasonable.
Yeah, so that's the idea around pytest timeout is if it takes longer than a certain amount, attempts to kill it.
And it does.
It does, like, SIG events and stuff to try to kill the process that's taking too long.
Excellent.
Whereas the new one, sweet timeout, is nice.
It won't kill anything.
But it also, it won't stop, something like that.
But it'll just, between tests, say, hey, this is taking kind of too long.
Let's stop now.
Okay.
Well, you might not want to SIG kill either.
Because what if it's going to put something in a database, do some stuff, and then take it back out or make a file change and then clean up the temporary files or, you know, whatever, right?
Yeah.
The other part of this, though, is I think it's too nice so far.
It doesn't throw any exceptions or errors or anything.
It just stops the counting.
So if you normally, like, in this example, if I had 1,000 and I only get through, like, 150, it just stops, passes everything.
But it only ran 150 instead of 1,000.
I'm trying to figure out a way to, like, alert the user a little bit more that there's something wrong.
So we'll see.
It'll grow a little bit after this.
Cool.
Oh, excellent.
Excellent.
This is a crazy episode of where it's just we all created a bunch of things.
So let's go back to things we created, huh?
Okay.
Next one.
This one is also a thing I didn't create, but outside in again.
So I've been using MailChimp for years.
And when I first started using MailChimp, you know, MailChimp is I want to let you subscribe to my newsletter and put you into groups so that if I only want to talk to the Talk Python people, I can send that message.
If I only want to talk to the Python Bytes people, I can send that message, right?
And the price has just been going up and up and up, like hundreds of $100 this month.
The next one, then another $100.
You're like, what is going on with these people?
You know, Intuit bought it.
And it used to be like kind of a cute little company, and now it's just an accounting firm grinding its users.
And I kind of don't want anything else to do with it.
And I would much prefer to not share all of the people, customers, people who just want to subscribe their data with a third party either, right?
So I went on, I think I talked about this before.
Remember I talked about the 10 different options that people had sent out of possible newsletter places?
Yeah.
I wish I remember who told me on Mastodon, but somebody said, well, there's these five open source ones.
I'm like, wait a minute.
Okay, that's interesting.
And so after a bunch of research, I decided to turn on ListMonk.
And ListMonk is written in Go, and it's an open source.
There's not even a SaaS version.
It's just self-hosted version of basically MailChimp, right?
You can have different lists.
People can subscribe to them.
You can put them into groups.
You send them emails, all that kind of stuff, right?
Yeah.
So again, because I have all this cool Docker infrastructure stuff set up now, it was super easy to just move that over
and run that in Docker, right?
Just like you, Mom.
You're like, okay, how do I talk to it?
There's not even an official API client.
The ones you find are like, well, here's one for PHP.
There's actually several for Python, but they're really bad and they don't work.
I mean, really bad.
So some of them, for example, are just, they look at the Swagger docs or the open API docs and they're just auto-generated.
But somehow it's like stuck in time, auto-generated on an old version that doesn't work anymore.
I don't know.
It's like even the auto-generated one doesn't work.
I'm like, ah, man, I really need this even more than the umami thing.
I need code to be written.
So like someone creates an account when they buy a course and they say, yes, I want to be, you know, I ask them, do you want to be in the middle of this?
Yes, I want to be there.
How do I make that happen?
Right?
Well, Python, of course.
So over the next project, ListMonk email app API client for Python or just pip install ListMonk.
So over here, this is the next one.
Super nice.
You can add a subscriber, get details about them.
One of the things that's cool in ListMonk is there's a arbitrary JSON Python dictionary type thing associated with each user.
So whatever data you want to put in there, you can.
And with this thing, you can manage it.
Like, for example, if one thing that's common is you have a rating or things along those lines or actions.
So you can put that into the user as part of their user record.
So you can manage it with that.
You can search them, check the health of your self-hosted thing, segment on your list.
Obviously, you've got to unsubscribe and delete users.
You can even send transactional emails.
So super, super cool stuff.
Again, one more nice open source thing that's not, you know, some big, super expensive privacy questionable SaaS service.
And instead, running good over here.
It does take a little bit of work.
Umami is like perfect.
This is a little clunky in some little edge cases, but it's still quite nice.
So that's the next project.
Also available on PyPI today.
Nice.
Well, that's it for our items.
Cool.
Between all these things, we can help people write one, a little bit better test.
And two, depend a little bit less on just giving up a little bit of privacy to trade it in convenience.
Like Google Analytics, for example.
Or to a lesser degree, some of these mail platforms.
Yeah.
And save some money while you're at it.
All right.
Well, normally we would jump into some extras and I don't have any extras this week.
So do you have any extras?
I do have extras.
Well, let's see what have I got here.
Yeah.
Okay.
So the first one is if I'm running self-hosting these things, right?
I'm running them in a Docker cluster.
So it's really easy to basically just do a Docker pull, restart, you know, relaunch the app.
Off it goes.
Right.
So that's awesome.
That's one of the reasons I'm willing to run like you, mommy.
Rather than like I have a server and all these database things that get a patch and whatever.
Right.
Just literally one command to manage like 15 multi-tier apps.
It's awesome.
But how do you know when there's a new one?
Right.
Obviously, you could just set it up to just do it continuously.
But what I realized is every GitHub repository, this has nothing to do with you, mommy.
It's just an example.
Every GitHub repository, if they use releases, right?
If you go over here and you say like the releases, like I have a V0 1.10 for my you, mommy thing.
And there's actually two of them.
If you have that for any project, you can just go to the GitHub URL for the web, not the dot
get thing.
And just to slash releases dot Adam.
And that's an RSS feed for the releases for any GitHub project, even if they don't have a blog.
Wow.
That's cool, right?
Yeah.
I can put this in Feedly then.
Yes.
I put it in Reader for me.
And now I have Lismunk and you mommy and a few other things.
And I'm like, if this gets changed, I probably want to just go take a little action on that real quick.
And now it's in my RSS feed.
That's pretty cool.
Yeah.
So very simple.
Anyone can just watch whatever they want.
Brian, we both tried to do this one.
Yeah.
Colo.
You mentioned it in your article.
I ran across this because I, sorry, I don't remember the last name, but I saw one of my
Mastodon followers, Lily.
She somehow interacted with me and her profile came by in my app.
And I saw that she works on this thing called Colo, debugging for Django apps.
I'm like, oh, that's interesting.
What is this?
So this is a thing that's in beta.
It says, see everything happening in your running Django app.
And they have a really nice design of their webpage here.
So probably best to see visually.
It says debug your Django app 10 times faster, get instant access, et cetera, et cetera.
So this is a plugin or extension for VS Code.
And it just has tons of information all available to you.
So it has a tab or whatever the thing on the left is.
You can see it as a plugin, and it shows you the request response, kind of like dev tools
in a web browser.
So you can see headers, HTTP requests, responses as kind of a running history of the HTTP exchange
your browser is having with your Django app.
That's cool, right?
And I think it's showing you, I'm not entirely sure, but I think it might be showing you even
Python code, not just web things, right?
It has local variables, arguments, and then it has even like this tree thing for visualizing
code execution paths.
So, yeah.
So you click on the, sorry, you click on the request.
It shows you the code, and then it actually shows you the local variables that were passed
around as well.
It's pretty neat.
Yeah.
I don't know that the tree, the visual thing is super pretty, but I don't know how full
it is, but I haven't played with it yet.
I agree with you.
It's awesome.
Wouldn't use it.
Yeah.
You can do, what is it?
Inspect all the outbound HTTP requests made.
That's kind of neat.
And SQL queries, you can, it'll track all the SQL queries that were made.
Really good for understanding what's happening.
What's up, Brian?
Good.
No, it's just really nice because you never know when you're,
queries get out of hand and you're making way more than you need to.
Exactly.
Especially in the ORM space, because it's so easy to do lazy loading and say, give me all
the customers for each customer.
Get me this thing about them.
And that's a relationship.
So every time through the loop, it's another database query, the so-called N plus one performance
problem.
Right.
And you would just see like, whoa, the SQL thing is full.
I thought there were like two or three requests and now it's just full.
What is happening here?
Right.
So that's great.
Yeah.
Anyway.
Ooh, background jobs.
Yeah.
Even contract your salary background tasks.
So right now it's in beta.
I'm pretty sure this is a thing that costs money at some point.
Yeah.
So if you VS Code, check this out.
It's kind of interesting.
Yeah, definitely.
Neat.
All right.
Another thing that's cool is I've talked about warp before and I've been using warp at the
terminal a lot.
one of the drawbacks of warp for all of its beauty and cool features is that it doesn't,
it only works on Mac for now, which is a limitation, let's call it.
Not for me.
For other people.
Not for me, but for a good chunk.
Now I say it's only somewhat of a limitation.
So like on my Mac, if I SSH into my Docker cluster thing that I've been talking about, warp will
like inject the warp behaviors into the Linux shell over there.
So I get like end to end warp as a Mac user.
But if I was actually a Linux user, I couldn't use warp because it's a Mac app until pretty
much now.
Right.
So coming soon is warp on Linux.
So people want to sign up for that.
I put a link for in the Linux terminal signup page to get on the wait list.
And warp is just a super neat way to work with, with your terminal.
It's more like an editor.
It's got AI built in, which most AI built in things I hate.
They're really bad.
But you can say things like just say hash.
And then you'll say something like, you know, search this directory for all files with this
pattern, except that directory.
And then it'll go, here's the command that you type, you know, like that kind of it's
because it's that kind of stuff that I'm like, what's the parameter to this?
How do I grep that again?
I don't have no idea.
So anyway, it's pretty cool.
I wonder if it's set up.
I'm just curious if it's since they're doing different platforms, if they've got a UI layer
and then a warp core.
Oh my God, they probably do have a warp core.
And if they didn't name it that they've really lost a chance here, right?
Yeah, hopefully.
So I talked about this before.
I realized through search about two and a half years ago, something called BPytop.
So BPytop is an awesome, if it gets too small, it thinks it's going to hide all of its graphics,
way to look at how your server is going.
And it is so neat the way that this app works.
I definitely, let me just, I'll put it up.
Here's the live running version of the one that I've been messing with lately.
And Brian, you can see you've got your memory.
There's not a whole lot of action going on right now.
So it's kind of blank graphs.
But like if the memory jumped up, you would see it go up.
It shows you how much memory is free, how much is being used, how much of that is being cached.
Disk activity.
You can see the network traffic.
The multiple, you know, it has four CPUs.
And it shows you graphs for all four CPUs as well as like the combined.
And I'm not going to show the processes because they might show command arguments that I don't
know.
I just don't want to share.
But it seems like it probably somehow could be a bad idea that I'm not aware of.
But we'll learn later in a hard way.
But isn't that an amazing way to just, this is over an SSH session.
Oh, that's pretty cool.
That's amazing.
Yeah.
And watch this.
So if I just hit escape, you get even, it's like an old video game options with mouse support
and everything.
Oh, that's pretty cool.
Yeah.
So another thing to sort of announce here is there's bPyTop, which you can pipx install.
But they've also, as part of this, released a bTop rewritten.
And I think it must be C++.
So anyway, that's cool, right?
People can, I think that's supposed to be a little bit more high performance.
Although to me, they kind of seem like the same type of thing.
Anyway, really cool.
If you've been using like Top or something like this, you know, there's a really much better
way and glances is good.
But bTop is the new, the new winner in my world here.
And you know, those sort of graphs, even if you don't need them, you can have a second monitor
and have one of those running.
Everybody in your life will think you do something cooler than you actually do.
Whoa.
You're a hacker, aren't you?
That's a terminal.
Yeah, I am.
Okay.
Yeah.
Don't cross me.
Don't you cross me.
All right.
Nice.
Right.
I think that's our extras.
It is.
Chris Tyler, just real quick, has a recommendation.
Switch to bottom.
BTM, which is similar, but written in Rust and a little more performant.
Also cross platform like BITOP.
Hmm.
Okay.
Well, maybe, maybe that needs to be checked out as well.
Maybe my time with BTOP was short.
I'll be over to bottom before I know it.
Top and bottom.
That's just terrible.
Yeah.
These are funny.
Yeah.
Thanks, Christopher.
All right.
I think I'm ready for a joke.
Yeah.
I got something, you know, I've been talking about consolidating all these servers and running
different things.
We just talked about the monitoring your server and Docker.
So I thought it might be fun to share this post on InfoSecExchange Mastodon from Jeff Hall.
And it's got this, you described this for us, Brian.
It's just a mess of cables coming out of the back of what?
A bunch of, I don't know.
Network equipment.
Yeah.
It's just like the world, you couldn't imagine a worse set of tangled wires.
And they're dirty too, right?
It's not just like, they're covered in all these routers and others.
They're white, but they're most, they're significantly brown as well.
With like a whole bunch of hubs hanging in between and stuff.
Yeah.
And a lot of these pieces are just suspended by the wires and it just says the cloud.
Yeah.
It's very nice.
I love it.
Yeah.
That's very cool.
So.
Indeed.
Funny.
All right.
Well, that's it for the show, I suppose.
And, you know, we don't normally have a final call to action, but go check out your new Pi
test thing, your timeout and check out some of these other self-hosted things.
Yeah.
It's really cool.
A lot of stuff people can adopt.
And yeah.
Thanks for being here.
Thank you.