Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 312, recorded November 29th, 2022.
I'm Michael Kennedy.
And I'm Brian Okken.
This episode is brought to you by the Compiler Podcast from Red Hat.
Check them out. Really appreciate them supporting the show.
Brian, we've got a lot to cover today. You want to just jump right into it?
What I want to talk about is Simon Willison.
This is incredible.
So Simon did a talk at DjangoCon 2022.
And then he wrote up the slides and everything.
And we're going to link to his blog.
His blog title is Coping Strategies for the Serial Project Hoarder.
And then the talk title was Massively Increase Your Productivity on Personal Projects with Comprehensive Documentation and Automated Tests.
Yes, that's a mouthful.
But really, I don't know what a good name for this is other than everybody that works with development needs to watch this talk because it's incredible.
So he goes through a lot of stuff.
I'm going to go through it.
I'm going to...
Luckily, he's got screenshots on here.
But he starts out...
So this is important not just for open source projects or personal projects.
This is also for if you're working in a company.
I think this is equally true.
So he talks about how he got these techniques from working at...
Now I'm going to forget where he worked.
But yeah, it's gone.
A large company with multiple continents.
And it was helpful to do this model.
So what is he talking about?
So one of the things he talks about is the perfect commit.
So we don't really...
As a professional software developer, you're not really doing new code all the time.
What you're doing is maintaining existing software.
So the commit is your unit of work.
And a perfect commit includes the implementation of whatever you've done.
But it also has tests and documentation and a link to the issue thread.
And this is...
It seems like a lot to me.
But walking through his talk, it totally makes sense.
So he gives an example of one of his with some cool highlights.
The highlights that he's got documentation changes also.
And the documentation might just be a single line change or something.
But the tests...
He does pause here and say tests are hard for some people, for some developers.
So it's important to get a working test framework in place quickly.
So that a test developer isn't starting from scratch.
They're just...
Or a software developer when they're writing tests.
It's just...
It's not like comprehensive testing has to be there.
But it is a test that passes when your change is there and fails when it's not there.
Or fails when it's not working.
That's enough.
You can do more thorough testing.
But that's enough to get us started.
And I think that's a good way to think about it.
But he goes...
Talks about...
He throws in this little cool thing of like,
Just keep common types of projects that you have around as cookie cutters in your own GitHub area.
He's got a Python library and a Click app and a dataset plugin for him.
I might have different things like a pytest plugin or something.
And that way you can just keep up with your best practices,
what you think of as best practices in one place.
This is a cool idea.
I'm totally going to steal this.
I've done that for myself as well.
I've built like a...
This predated cookie cutter.
But I built this thing like,
I always want to have logging.
And I want it like this.
I always want to, you know,
connect to this other service.
And like ping it to make sure that the thing is alive.
Or whatever.
Whatever thing we decided for monitoring inside of our...
The company I worked at.
And like all the new projects would just start that way.
And it was so nice.
Because you didn't like,
is it really worth doing the thing to make sure that we can monitor this at some time?
Like you just run the one command line thing and it's there.
Right?
We could give it to an intern and they could run it to start their projects.
It was great.
And then he's got like this thing that supposedly with a GitHub hook.
And I'm going to have to dig into this more.
Because I didn't quite understand how this works.
But he's got a way within the GitHub interface to say,
I want a new project.
And it automatically like gives you the choices of what kind of project.
And then fills out all the defaults from the start.
Instead of just getting the readme like normally.
So this is kind of neat.
And I guess I want to try figuring this out.
The documentation bit.
At least one of the things about including this.
Even if it's difficult.
You can have this be part of the code review requirements.
So don't accept a code review.
And tell the documentation is there also.
So this is a cool idea.
And then it's the bonus trick of testing.
Testing documentation.
Which is a cool idea.
And then the links to the issue.
And I thought this was just sort of a yes.
You should do this.
But this is really the meat of the talk.
Is him doing his entire thought process.
In the issue thread.
And he even gives examples.
Where there's sometimes like up to 50, 60 comments.
And it's just him talking to himself.
But this is brilliant.
And I'm not going to convince you as much as he is.
But it includes screenshots and dead ends.
Like I tried this thing and it didn't work.
And we're going to go back and do this other thing.
This is an...
He calls it temporal documentation.
And I just love this idea.
And I'm going to try to follow this myself.
Because I have like a memory issue.
I write stuff down.
And then I forget where I wrote it down.
And this way he says, you don't have to remember anything.
You just dump it there.
And that way, let's say you get pulled off of a project.
And you don't get back to it for like six months.
Because you've been fighting fires and doing other stuff.
And then you get back to it.
You won't remember where you're at.
And with this line of thinking.
Of keeping all of your thinking in the issue thread.
You can just jump in and go, oh, that's where I was.
And get started pretty quickly.
I love this.
It's cool.
So then the rest of the talk is pretty interesting too.
Talking about how like, you know, scientists have been doing this.
And other engineers have been doing this for a long time.
They called them lab notebooks before.
And we kind of got out of the habit of doing that with software.
But anyway, lots of great techniques.
And I think this is just how to be a professional software developer now.
I love that it's like a casual conversation.
And not like, here are my four recommendations.
But like the playing around and the dead ends are really, really valuable.
Yeah.
Kim out in the audience says, the cookie cutter approach also works beautifully from a DevOps perspective.
For setting up developers to use your firm specific infrastructure.
Yeah, I totally agree.
And that's a little bit of what I was hinting at.
Of like, here's how we integrate with this like uptime manager and stuff.
But obviously DevOps, that was talking, we were deploying to a server in a closet there.
Which, I mean, that tells you all you need to know.
Yeah.
Speaking of stuff you might need to know, Brian, Google Copilot and these code writing AIs, I have more to say about that at the very end of the show, book in this a little bit.
They train themselves on lots of code.
And Google Copilot, for those of you who don't know, you basically can give it a comment.
And it's like, I want to connect to a Postgres database with SQLAlchemy.
And then, boom, it'll like literally write all the code, import the usings, you know, come up with a connection string, all that kind of stuff.
It's pretty fantastic.
Has some privacy issues.
I don't know what it's doing now.
It used to send your source code that you wrote up to GitHub, which made me not want to use it already.
But the big news here is the website GitHubCopilotLitigation.com.
And that's as ominous as it sounds.
It says, we filed, this is what the website sort of announces.
We filed a lawsuit challenging GitHub Copilot, an AI product that relies on unprecedented open source software piracy.
Why piracy?
Because it's trained on things that are like GPL and Creative Commons share alike or attribution.
And then it outputs code based on that original input that has no GPL and it has no, you know, whatever license, right?
The license is stripped and no attribution.
What do you think?
Something we talked about from the very beginning of like, how is this okay?
Yeah.
Not sure.
Absolutely.
If it did things like we're only going to look at MIT licenses and other commercial open no attribution licenses,
I don't think there'd be anything to say about it.
But apparently that's not the case.
So there's a couple of updates as well.
I suppose we should also, like they do on this page, say, we are not a lawyer.
Please don't take legal advice from us.
We write code, not legal documents.
But nonetheless, it says, this is Matthew Butterick.
And they've set up to investigate Google Copilot.
And they filed a class action lawsuit in the U.S. federal court in San Francisco on behalf of a couple folks.
So they're challenging the legality of GitHub Copilot and a related product, OpenAI Codex, which powers Copilot.
The suit has been filed against a set of defendants that includes GitHub, Microsoft, and OpenAI.
Wow.
There's an update down here somewhere.
Let's see.
It says, here's the motivation for their lawsuit.
By training their AI systems on public GitHub repositories, though based on their public statements, possibly much more.
We contend that the defendants have violated the legal rights of a vast number of creators who posted code or other work under certain open source licenses on GitHub.
Which licenses?
A set of 11 popular open source licenses that all require attribution, the author's name, and copyright, including, I guess, the MIT license as well, the GPL, and the Apache license.
And it's listed out there.
There's a whole bunch more details.
And it says, update, November 10th.
That original was November 3rd.
There's an update here.
This is, we filed a second class action lawsuit on behalf of two additional plaintiffs.
The defendants and claimants are otherwise similar to the initial one.
So, there you go.
It's going to be interesting.
It's not going to be just interesting for Google, for Google GitHub, Copilot, but basically AI in general, right?
It says it's going to challenge that AI strips the ownership and other requirements of inputs and outputs, right?
And maybe it does, maybe it doesn't.
I mean, we heard that APIs are not copyrightable in the Google Oracle Java lawsuit.
So, we're going to find out here.
Oh, interesting.
Yeah.
I mean, like, when we looked into this a little bit earlier, if it's helping you fill in parameters to a function, or what likely things you're going to fill in for a function call, that's one thing.
But when it plops down, like, 20 lines of code for you, where did it get those 20 lines of code?
And then, I mean, open source doesn't necessarily mean you can copy it.
It's just open to read.
I mean, you can have a, you can put your own license in there.
You can make up your own license that says, anybody can read this, but you can't copy it, use it, or do anything else with it at all.
Can't even fork it.
And there's nothing stopping you from doing that sort of a license.
Right.
Or the default, if you put it on GitHub, I believe, if you put no license, means you have no license.
You're conferring no license whatsoever, right?
Yeah.
It means it's just like, it's like writing a book.
You can't, when you write a book, you have the full copyright, unless you give it to somebody else.
So.
Yeah, absolutely.
All right.
Well, let's stick with my screen for a second.
I want to tell you all about our sponsor for this week, Compiler.
So this episode of Python Bytes, this episode of Python Bytes is sponsored by the Compiler podcast from Red Hat.
Like you, Brian and I are fans of podcasts.
I listen to them more and more these days, actually.
And I'm happy to share this one, Compiler, an original podcast from Red Hat.
So if you want to stay on top of tech without dedicating tons of time to it, check out Compiler.
They present perspectives and topics and insights from the tech industry free of jargon and judgment.
They want to discover where technology is headed beyond headlines and create a place for new IT professionals to learn, grow, and thrive.
Compiler helps people break through barriers and challenges, turning code into community at all levels of the enterprise.
One recent interesting episode is their great stack debate.
I love, love, love talking to people about their architecture, their code, all the trade-offs and conventions.
As you will see later in the show, I'm going to talk a bit about that at the end as well for us.
And the costs that come with this, the challenges, things that are awesome, the things that are not.
So this episode is like that.
So you can check it out to see if software is like an onion or like lasagna or it's more complicated.
It's the first episode in a compiler series on the software stack.
So listen to more about Compiler at pythonbytes.com.
Yes, you can just go type compiler into your podcast player.
And that's what I would do in general.
But please use our link so that the folks at Red Hat know that it came from us.
Yes.
And thanks to Compiler for keeping our podcast going strong.
All right.
Over to you, Brian.
What's the next one?
So this is a silly thing.
But sometimes I've got Python code that I want to have a pop-up, a window pop-up.
And I've always been using, what is it, PySimpleGUI?
Well, not always.
But that's what I've been using lately for really easy, just a simple pop-up thing, especially if I needed to use run on Macs and really anywhere.
Because it's totally fast to get it done, and I don't have to think about it anymore.
However, PySimpleGUI doesn't, I haven't mastered the art of getting it to look just like a native dialog box.
And maybe there's some tricks that you can do that I just don't know.
But if I know it's on Windows, maybe we could just go ahead and use the Windows DLLs and do a native Windows dialog box.
Just call straight into the Windows 132 API for message box 3B2 or whatever it is.
That shouldn't be too hard, right?
No.
It sounds scary to me.
But I ran across Matt Callahan's blog.
Matt Callahan has an article called Display a Message Box in Python Without Using a Non-Standard Library or Other Dependency.
Actually, you can just do this.
You don't have to install anything.
And I got this.
I want to, where did I get this from?
Give credit where credit is due.
I got this from the PyQuarters Weekly newsletter.
So thanks to them.
Anyway, this is not hard.
So he has a little pop-up example.
And I should have read the article, but I just skimmed for the code.
Here's some code.
That's it.
This makes a dialog box pop up.
And it's calling the, so it calls, it's just like a couple flags.
It's like 10 lines of code.
It calls ctypes, win DLL, user 32, message box, EXW, whatever that means.
And with some stuff in it, like a title and a message and everything.
So it's using ctypes, which I don't use much, but you can get into DLLs.
So ctypes is built into Python.
And so this message box, I wanted to play with it a little bit more.
So as I was playing with this, looked into the Microsoft documentation, the message box dialogue.
There's a, one of the flags is this U type.
And it's like this hex value thing or a bit field.
And you can orient a whole bunch of stuff.
So you can use this to, to get like an okay box or an okay cancel box, different types of dialogue boxes using this, this flag.
And then once you've got this popped up, how do you, you need to know like what users clicked on and stuff.
So there's, there's return values from this and you can just like check the return value.
And it's defined to be like, you know, a three for abort and a two for cancel and one for okay.
And you can just check this value.
So with just a little bit of code, you can have a native dialogue box pop up if you need to in your code.
Yeah, that's awesome.
And it does things like natively that you would expect.
Like for example, you hit escape and you have an okay cancel, it'll return cancel.
I hate some of these, these like UI things, they show up and you're like, well, it's got one text input and a submit button.
You hit enter, it does nothing.
You're like, yeah, great.
Okay.
Apparently this is not real.
I'm going to have to just, you know, go click it or whatever.
Right.
So hooking into the native OS is sweet like that.
This looks like a thing that would be ripe for a short, simple little package that wraps up, say all the.
Okay.
Cancel.
Yeah.
Okay.
Cancel.
What kind of icon you want?
Do you want like a warning?
Do you want an informational icon?
The buttons?
Yeah.
It seems really great, but this is fantastic.
So, so neat and, and built in neat.
So anyway.
Just a quickie.
Yeah.
It comes included.
And yeah, I really like it.
And it's also a bit of a roadmap to show what you could do beyond that.
Right.
There's more than just really simple dialogue boxes.
For example, like the open file dialogue box on windows could probably be real similar.
Right.
Oh yeah.
Probably.
Right.
Yeah.
So when I was looking it up, there's a whole bunch of dialogue boxes you got access to.
Yeah, exactly.
It's like a roadmap to like, well, I can like create a file or, you know, any of these things, which I think is pretty cool.
All right.
Let's flip away from OS specific to OS general, but stick with PyCoders for a minute.
So this one also comes from PyCoders.
I don't know if it's the same issue or not, but very cool.
It says write Chrome extensions, which also mean like Brave and Vivaldi and others.
Edge maybe.
Write Chrome extensions in Python.
Oh, how does it work?
Hi script.
Of course.
So, yeah, we, we just take PyScript and this, this is an article by Pete Fiston and it sort of walks through how he was able to use PyScript, which is Python on WebAssembly running in the browser to use that to power a Chrome extension.
And it doesn't really matter if it's a bit of a nine meg download because you install it once and it's local on your computer, right?
So it just, if you want to do this, it walks you through all the things you got to do in order to use PyScript to write Chrome extensions or Python to write Chrome extensions.
What do you think?
Cool.
Even shows you how to put an icon.
That's pretty cool.
Yeah.
But I have more for you.
So just so in case people don't know, this is an extra, extra, extra hear all about it section because I want to hit a whole bunch of things.
So as of recently, just published this episode.
Let me look.
30, 31 minutes ago.
And it says PyScript powered by MicroPython.
So one of the challenges that PyScript has had traditionally is it's based on the full, nearly the full CPython runtime compiled into WebAssembly, which after you strip a bunch out, that doesn't work in the browser.
It comes down to like nine megabytes.
Okay.
It's for like this browser extension thing.
That's reasonable.
But for, you would never use in place of like Vue JS on a popular page because you want that page to load quickly.
You want it to be good for SEO, all those things.
But you know what's small and fast?
MicroPython.
Oh, neat.
So I just had Brett Cannon, Nicholas Tolerwey, and Fabio Flieger, on Talk Python to talk about the work that they're doing to make PyScript not run on full CPython, but to run on MicroPython.
Oh, wow.
MicroPython, you can get that to load up in a hundred milliseconds on your page.
And it's only a couple hundred K.
All of a sudden that starts to sound a lot like a pretty rich front end framework level of stuff you got to download and get started and you cash it.
Then you're, you're good to go.
That's exciting, huh?
That's super exciting.
Yeah.
So this Chrome extension thing is cool.
When you look at the shipping version, I don't know if you can call it shipping because the price script is still like super alpha, but what you can get today.
So Nicholas said probably spring that they'll have something to share, but in terms of being able to use MicroPython.
But I think that's pretty excellent.
That could really, really unlock some, some super cool features.
If now we could build like a Vue.js type thing, but with Python.
And one of the goals that they stated is that they're looking to build this as a framework or excuse me, a platform that you can build frameworks on top of.
So it's not just, here's how you write some Python code in the browser, but here's a foundation that people could create like a PyView or a PyAngular or, you know, whatever they wanted to create.
Right.
Yeah.
So question just for my own personal use is, is, would Chrome extensions work on Vivaldi?
Yeah, yeah, they do.
Okay.
One of the things that's interesting about Vivaldi, and I think it probably affects its reporting a little bit.
When you look at the user agent of Vivaldi, it's exactly the user agent of Chrome.
So it lies to the world and tells the world it's Chrome.
There's no user agent for Vivaldi.
It's just whatever version of Chrome it's like using, you know?
Okay.
So when you go to the Chrome web store, it's like, put this in Chrome.
You click it and yeah, it goes.
So it worked perfectly.
Sure.
Cool.
Yes.
And John Sheehan says, yes, they do.
All right.
Next, extra, extra, extra.
Brian, I've been excited a little bit about Mastodon.
I don't know if you noticed.
Yeah, me too.
I know.
It's fantastic.
It's really tons of great interactions.
And I started putting in our show notes, which you'll see when I publish this, your Mastodon account and mine.
So people can connect with us and have even more conversations over there.
But there was a really interesting article by Eugene, the guy who created Mastodon.
I've been looking and looking.
It's about scaling Mastodon and the challenges they were having.
And boy, it's...
I would love to link to it, but I just can't find it.
But it's so...
It's written in Ruby, right?
And so it talks so much about these are the challenges of scaling out threads.
And, oh, we have this thing called a GIL.
And it really doesn't allow you to use threads very easily.
And here's...
There's just...
It was so interesting to look at how a technology that doesn't have asyncio and async and await getting all tangled up trying to do IO-based things.
So it's like, well, can we have...
Maybe we should have 10 to 20 threads to do the network communication.
But if we have more than 20, then we get like a context switching and contention in the operating system, you know, that just comes with having OS threads.
Well, guess what?
You can do really well with no threads or one thread.
You can talk to web...
You can call other websites.
You can receive web requests.
And the mechanism for doing that in Python is async and await.
And asyncio requires no additional threads, very, very little overhead, no contact switching.
So this project by Andrew...
I'm sorry if I am not getting...
Andrew Godwin, sorry.
I forgot his last name for a moment.
I have Django channel said, what if I rewrote this, but in Python with an async and a wait?
Okay.
So there's a bunch of challenges of running Mastodon.
People want to have their own server because they're like, oh, I want my own server.
So I'm not stuck in one of these communities.
And as beholden to them, the problem is every one of those is like a standalone DevOps adventure.
There's tons of like things working together.
And it's a lot of work, right?
It would be better if you put like host more of them on one machine and sort of scale that up in a nice way.
So this one lets you host multiple domains for small to medium instances.
And it's written with async and await, which is pretty awesome.
So yeah.
Anyway, I think you should check this out.
I didn't know if I caught you trying to pronounce it.
Takahe?
I don't know.
I'm going to go with that.
And of course, Andrew Godwin just said, you know, I can probably write this in Python and like get it out in a couple of weeks.
I think it was like five days or something.
So key features, multiple domain support, multiple identities per user, which is kind of interesting.
Desktop mobile and PWA compatible.
Again, how many days?
And easy deployment.
A web worker, a background worker, and one database.
Not all this crazy, crazy stuff.
So anyway, people can check it out.
Let's check out the requirements.
See what we got going on here.
UVicorn for an HTTPX.
I mean, that pretty much says it right there.
Oh, interesting.
It's based on Django HTMX.
It's pretty interesting in some of the building blocks.
But yeah, super cool.
So there's another one.
All right.
We just had our Black Friday sale over at Talk Python.
And that was really excellent.
Sold a bunch of courses.
We sold some pytest courses, by the way.
Yeah.
But I...
I'm just excited because sometimes we have these sort of conversations about, you know,
like cool sales and stuff.
And I'm glad that I get to be a part of that now.
We've done other fun things where, like, we couldn't sell your book through them because
it's through the publisher.
And I guess, yeah, it gets tricky, right?
So I'm really excited as well.
So we did our Black Friday sale.
And guess what?
I noticed something a little bit unusual.
It said, after a little bit, I opened up Glances on the main web server and said,
CPU usage is 85%.
I'm like, oh, that's not so good.
88, 91, 92.
Uh-oh.
But what was super interesting was Nginx, not Python, was the thing getting hammered.
So both Nginx workers were like almost 100%.
And Python was just chilling.
I'm like, okay, that is a really interesting story for Python performance that something
amazing like Nginx that people say is fast all the time is the bottleneck.
And it turned out it survived, but just barely, right?
If it were like twice as bad, it would have keeled over, which had been bad.
So I talked to a bunch of people about this.
And I realized that there's one HTTP response.
I've got to spell that better.
And 12 CSS files, 43 images, and one JavaScript file on the page I was sending them.
So I'm like, all right, maybe I should try to use some interesting CDN, which I had got
a recommendation from one of our listeners, but otherwise hadn't heard about.
What a cool service.
So now we have 112 different locations serving up those static files and just processing.
So I went back today when we did our Cyber Monday and I said, when I, that was yesterday, when
I pushed out the announcement for Cyber Monday closing and I pulled up the real-time data,
look at that traffic.
That's CSS and JavaScript and images.
1.4 gigabytes a second.
Oh my gosh.
It's insane, dude.
And check this out on the server.
This is the most important part, 3% CPU usage on NGINX and across the whole computer,
across all of the micro-WSGI processes, just a couple more percent.
CDN to the rescue.
Exactly.
But the thing that's also interesting is that Python is just like, yeah, it was nothing.
Like, we can take that, but it's all those static files.
So anyway, I put that right up together for people in order to serve out that data, pay $2,
right, for 0.35 terabytes.
And by the way, it's going right now.
Oh, it's got to refresh here.
They have these cool real-time maps and whatnot.
But that little spike right there is when I released the Talk Python episode.
And that's about four and a half terabytes per second, which is just insane.
So anyway, I totally recommend people check this out.
It's super fun.
You're reaching people all over the world.
That's pretty cool.
Yeah.
Isn't that amazing?
You get all these different locations.
I think it lost its web socket connection because it stopped updating.
It's like, there's a little warning.
This live monitor is like a little bit of a suggestion of how things might be.
But yeah.
Anyway.
Yeah.
What's up with the Alaska people not listening?
Hey, Alaska.
Yeah, man.
Come on.
Yeah.
They're going to have to CD in over to Canada or anyway.
So not that.
This final one here.
No, not final one.
Second, final one of the read all about it or hear all about it.
Reader 5.
I've actually been really getting back into RSS.
I've never left.
Yeah.
What's your RSS story these days?
No, I use Feedly on my phone just to keep up on stuff.
Nice.
I'd switch to things like Zite, which is sadly gone, and Flipboard and these sort of Apple
News-like things where they kind of curate a bunch of different sources.
I'm like, you know what?
There's a bunch of great places I would really like to just directly get them from and curate
a little more than just I suggest more Python.
Because do you know how many times my Python channel in Flipboard has women scared of Python
that comes out of the toilet?
Like, you know, no, not that Python.
Really not.
Oh, no, no.
And so I've just been super loving.
I've been using Reader 5 with two E's.
What a nice piece of software this thing is for $10.
Okay.
Really, really cool.
Yeah.
I'll check it out.
Yeah.
And another thing I would like, if people have awesome recommendations for blogs, especially
Python blogs that I should be following or people, listeners should be following, put that
on the YouTube channel comments or send it to us on Mastodon or Twitter.
And maybe I'll give a shout out to the ones that are extra good.
But very, very cool.
Let's see.
Check this out.
There's a podcast called Sing for Science.
And on season three, episode eight, which just came out six days ago, Rivers Cuomo of Weezer
and Guido Van Rossum sit down for a conversation.
How cool is that?
That's pretty cool.
That's really cool.
So have you listened to it?
Yeah, I listened to it.
I grabbed my phone and my dog and went for a walk and listened to it because the sun came
out and that was rare right now.
Yeah, it's really interesting.
Neat.
It's a lot of the host talking to Rivers and talking to Guido and a little bit of interaction.
I would love a little more facilitation of talking directly, but both great people.
Rivers is awesome.
He does really cool stuff with Python.
I had him on Talk Python 327, little automation tools, which was fun.
So yeah, he's a legit developer these days, which is pretty neat.
All right.
Final thing, Brian.
Final extra, extra, extra.
We started with, I started at least my segment with AI coding and I'm going to end it with
AI coding Kite.
Do you remember Kite?
It was like the original GitHub co-pilot.
Yeah.
Unfortunately, they are shutting down.
So they've been around for 10 years or so.
Not quite.
Seven years, something like that.
Really?
Quite a while, but they're shutting down.
So thanks for all the code, I suppose.
And that's it.
That's all I got for all my extras.
I want to add one.
So we talked to Simon Willison, talked to one of the one thing I didn't mention about in
his talk is he encouraged people to write blogs because there's not that the blogs were huge
for a while and then everybody was doing it and now not so much.
And so you do get noticed more if you're writing a blog.
I think that that's a good thing.
Plus, we can link to it easier if you got your article on a blog.
Absolutely.
But also, and RSS wise, Planet Python is something I still check out.
So planetpython.org, if you haven't heard of it, you can either have the full content so
you can read and it pulls all of this through RSS from different blogs.
So if you have, and titles only, if you have a Python blog or you're starting one, check
out Python, planetpython.org and try to get your name on the list.
Maybe put out like three or four articles first and then try to get your name on the list or
your blog on the list.
And that way it gets seen by people like us, even if you don't notify us.
Yeah, that's excellent.
I didn't subscribe to that because I feel like it's a little bit too much of everything.
But I went through all the recent posts and said, this writer looks interesting or this
source looks interesting and like subscribe directly.
So I kind of used it to start my exploration of those things I wanted to subscribe to.
Yeah, not a bad idea.
And you know, they have RSS feeds because they're in here.
So exactly.
Since you brought it up, I just want to also point out like one of my roadblocks of writing
a lot was, well, I don't have time to write like an article, something well thought out
and, you know, a thousand words and that, you know what?
My new philosophy has been, let's just write like really short posts.
Like here's one about a fun thing I did with spammers and it's like three paragraphs.
Or here's one about installing something as a PWA.
It's two pictures and four paragraphs.
And you don't, you don't have to write essay like long essays to contribute interesting
things and ideas, I think.
So I just following up on that.
Yeah.
My thoughts are if it's going to be a thread, make it a post instead.
Yeah, exactly.
Exactly.
All right.
Well, my jokes have vanished.
I had a cool joke on social media and it got taken down.
It was, it was, it was really funny.
It was totally benign.
I don't know why it's gone, but whatever.
And then by the way, following up on this, Jeremy Page.
It says you can also RSS Mastodon users.
Okay.
That's.
And Mastodon hashtags as well.
You can RSS those.
Okay.
Yeah.
I follow the Python hashtag over there.
I could RSS it, I suppose.
Excellent.
All right.
Brian.
So do you have a joke for us?
Yeah.
So speaking of Mastodon on Mastodon, I said, I'm getting, I'm getting a lot of great Python
content on Mastodon, but I need some joke people to like, I need some nerd jokes.
So I'm asking for people.
And this, somebody didn't ask, tell me a person to follow.
I'm still looking for people to follow with good jokes.
So if you send them my way, if, or send me their way, if, if you know of people.
But here's one that I got from somebody on Mastodon.
So I got it from, who did I get this from?
I should probably give credit.
So this came from Steven Box.
Nice.
Thanks, Steven.
So exit condition from monkeyuser.com.
So it took me a while to get this.
So there's a couple of people sitting at a desk, paraprogramming, I'm guessing.
And then somebody else is frustrated.
They hear, wait.
And he says, the frustrated guy says, that's it.
And, and, and he starts going towards a door that's labeled recursion.
And somebody says, wait, there's no, I'm going in.
He goes in and he gets into the other side and says, wait, he's the person trying to say, wait.
Oh my gosh.
There's no exit condition.
So that's a dumb joke, but that's right.
It's really good.
And it's got some clever, the cartoon is clever where like the, the speech of the other one is off screen.
So it kind of looks like it comes from the original group, but in fact is coming from the recursion of the first one.
And then, yeah, it's, yeah.
Okay.
Well, one more.
Somebody said, I should follow Olafur White.
Anyways, I just thought this was dumb and funny.
Bobby pin.
No, I go by my full name, Robert Pindle.
And it reminded me of the Bobby tables thing.
So yes, exactly.
I love it.
All right.
Well, thank you everyone for listening.
And Brian, thanks for being here.
Thank you.
Yeah.
Bye everyone.