Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 296, recorded August 9th, 2022. I'm Michael Kennedy.
And I'm Brian Okken.
Hey, Brian. We have a new sponsor. I just want to say thank you to Mozilla and the IRL podcast
for sponsoring the show. Check them out at pythonbytes.fm/IRL. And more on that later.
For now, I want to hear what you've discovered to share with us. Can you constrain your excitement?
Yeah. I want to talk about pip constraints. So there's a, I think I knew about pip constraints,
but I kind of forgot about them. But there's an article called pip constraints files by somebody
named Luminisman. So this is what, so they're kind of neat. So one of the things I was just using a
pip requirements.in file recently in a course that I'm taking. And I like,
using requirements.in to generate my requirements.txt file. But there's, and then there's,
there's a, yeah, anyway, that uses pip-tools. So you have to get pip-tools. But so there's that.
And then there's also pinning. So especially with applications, we see it more in applications,
less in libraries of pinning the application. But you can, even in libraries, there's regularly
sort of constraints around stuff to say, Hey, for this library, I need this, this range of versions,
or it has to be greater than this or something. Cause I'm depending and that's fine. But this is a way to
say not what libraries I want to want to use, but if I use a library, which version? So, or constraint on the
version without saying, I want the library. So, and in the, actually in the pip documentation,
it says constraint files are requirement files that only control which version, not whether or not it's
installed. So how would you use this? So this, this article talks about it and it basically says you,
you kind of use it normally pip install requirements.txt, but you might have,
if you do like a freeze for instance, or something, or you just pin everything, you might have all of
the versions, but you might only want like constraints on like one of them. Say, let's say
you want your, your including pandas, but you want a certain version of pandas or, or you want a certain
version of numpy, even though pandas requires numpy or something like that. You can have a constraints
file that lists, this just looks like a, a pip freeze file, but you can, you can put like less
than or less than equal if you want, or, and you don't have to have everything. So you could just pin
one of the things. And that way, like, let's say you were doing pandas and you wanted to constrain numpy
to be a certain version of numpy. You can do that with a constraints file and not have it, not have to
specify everything, just have it be separate. And the kind of the, the article talks about actually just
sticking the constraints, specifying your constraint file within the requirements file. And that way
they're separate. And, and I was thinking about that. And that's an interesting thing to say,
the dependencies of my application don't change, but the constraints might because of testing or
whatever. And this, this separating of these two files would help with like, you know, when you
have the two files of version control, you've changed your constraints, but you haven't changed really
what you're depending on just the versions of those. So it's kind of a neat to have that separate
possibility. So, yeah. So for people who are listening, literally the first line of the
requirements.txt file is --constraint constraints.txt, which I had never considered
doing that. That's interesting. And then one of the things I thought is, but I'm not, and this works
if you're handwriting your requirements file, but what if you're, what if you're not, what if you're,
you're using, requirements.in instead, and this article doesn't go into it,
but I tried to just, instead of putting that constraint thing in a, in a, requirements.txt
file, putting it in a requirements.in and using, pip compile to generate it. And it, the pip compile
seems to also watch the look at this. So it, this constraint works for pip compile as well.
okay. So that's cool. Yeah. So, kind of a neat thing to, to, to check out. the usage of it's
pretty easy. just, yeah. Anyway, pinning your requirements is good, but don't pin them too
tight. If, especially for application for, for libraries and then for applications. yeah,
I kind of like this because there's a lot of times where I, I know there's a bug in something
or I've heard about it or, or I haven't gotten around to fixing my code to deal with the new
version yet. So I'm going to pin something and I don't necessarily need to pin everything. I just
need to pin certain parts of it. So that's kind of neat. So I like this, just also a little bit
of a sidebar with the pip compile from pip-tools, you know, you give it the end file and it generates
the TXT file and it basically obliterates the TXT file, whatever's there previously.
Yeah. And that can be a hassle, especially if you want to have like a requirements dot dash dev
and then a production requirements. And if you install the dev, the dev one that you want to
also pick up like a -r on the main ones and the pip-tools blows that away. So what I ended up
doing a lot for my workflows is having pip-tools generate some base TXT file and then having like
requirements.txt just have a dash R, you know, requirements production. And then the dev
have -r requirements.txt, you know, broad and like sort of like put those commands just in
real simple and have it actually generate a separate file. So it kind of makes it a little bit messy,
but it, it gives you lots of flexibility.
Cool. Yeah. I'd like to see that written up. That's neat.
Yeah. Maybe I should actually, blog something like in the last three years.
Blog.
Uh, Pam, yeah. What is that? Is that with words?
Written words, not spoken words.
Pamphil on the audience says, does it take over requirements? Like if pip would resolve numpy to
one dot 19 and you say at one 20, it sounds to me like it does, but what do you think Brian?
Well, like I tried it, with, typer. So I knew, I know typer pulls in a click for instance,
and they're both command line things.
Yep. and so then I said, okay, well, the typer has a broad range of click things that it can do.
And if I constrain click to be a lower number, will it work? And I blew everything away and tried it
again. And, and sure enough, it, it did it like add those extra constraints on top of even like,
so I was, I was only declaring typer, but typer was specifying click and I could specify which version
of click I wanted. So yeah, this is cool. Yeah. it's, I guess what adding one more
complexity to your packaging, workflow. So, but exactly.
But useful if you need it.
But flexibility.
Yeah.
Yes. Good flexibility.
All right. Well, let, I'll cover something simple. Async caching.
Simple.
It is simple in a sense. we've had, we have some nice stuff built into Python,
like async, I'm sorry, with like functools, and the LRU cache and whatnot. But from what I
understand, those are synchronous only. Basically they're decorators, those decorators wrap
functions and the decorators themselves are synchronous. And so it only makes sense for
them to wrap sync functions. Yeah. Okay. And so if you will have an async function, but you want to
do the LRU cache where you just put the decorator LRU cache. And then if it gets called with the same
arguments, again, it doesn't even call the function. It just goes, you know what? You already called it
with that. Here's the answer. So like if you're in a tight loop and you're pulling in some values and
you've got to compute something with it through a function, but there's a good chance of repeat
of those values. You can put an LRU cache. And long as that pretty deterministic and you call it again,
you expect the same output. You can make it fly by just adding one of those caches on it. Right.
So a short version of this is, this is the same idea, but for, async functions. So I can have some
function I want to call. And I just say at LRU cache, and this one, you can give it a maximum size
of results that it's willing, you know, inputs and matched up results. It's willing to cache up.
And if you call it with the same arguments, it'll give the same response back. So that's pretty cool.
That's the, sort of last used version. And then you also have time to live a time to live
an async TTL. So you can say any results. I don't care, how many I've used, but just within the last
60 seconds. And one thing that's really, really nice about that is it will expire results. So maybe
you're calling an API and you want to do rate limiting, but you know, you only want to be,
call it maybe once a minute, right. That'll both make your code faster, but also not overrun your rate
limiting that you might have with your API key and so on. So here's a real simple way to add rate
limiting is just say time to live. I guess you got to have the same input arguments, but you know,
assuming that you have the same arguments, that's, that's one way to do it. And you can also
specify the max size, which is pretty cool. Yeah. Or if you're grabbing something off of a service,
like, what's the, like, what's the temperature out? I don't really care if
it fluctuates every second, but every minute I might check it. sort of thing. Yep. Yep. Precisely.
And I don't, there's not a T T L on the normal LRE cache. Is there? I don't believe so. Yeah. So
that's actually cool. I like the time to live part. Yeah. I do too. I like that. That really resonates
with me. And the other thing that's pretty cool here is you can pass ORM objects and pass request
objects. You can pass custom classes, even if the classes are not hashable, it will still go through.
And actually, so one of the problems you can run into is if you pat, say, if you've got a customer
object or a product object or something, you call it once you've created this object. Maybe you got it
from the database and you say, call the function with the LRU cache. And it says, well, what object
is this? Have I seen it before? And maybe yes or no. And then you call it again. it might have the
same effective value, but it's not actually the same object, right? You might get it from the database
again. So it has a different pointer, a different ID and so on that. I'm not sure what the behavior
there is, but this one will actually, look and see, Oh, is it actually a class? Well then let's
just get the dictionary and use the dictionary, the underlying field dictionary of the class to use
as the, the match to see if I'm calling it again. So there's some really cool, functionality here,
simple little class, but if you want to quickly add some performance boost async functions, you can add
this. Oh, nice. Okay. This is neat. Yeah. Yeah. Yeah. It's fine. Also. Yeah. Thanks. Also it's entirely
possible. I don't think it does, but it's entirely possible to add, async and synchronous support
to a single decorator. if, if you need to, right. for example, I have the, what was it called?
The million templates, FastAPI one that I created. Let's see. Look at that. Number one result.
What a search search thing. So there's, so there's this FastAPI chameleon framework or library that
I created that allows you to just do a decorator and say dot template and put a HTML template in the
chameleon language on a FastAPI response. And it returns a dictionary and that just turns it into an
HTML response. Okay. This one in FastAPI, you can both have synchronous and asynchronous functions.
So this thing has to look and see if the inbound thing is a co-routine and async co-routine,
and it will dynamically generate the right wrapper and async one or a synchronous one based on. So
it's not super hard. It's, it's also not super easy, but I did it so it can be done. Cool. Anyway,
uh, that's a little bit of a diversions, but this, this async cache versus a non-async cache,
I feel like, you know, it could just be, it could be one thing if it really, really wanted to be,
but I feel like the person who created it probably is just like, I need this for async methods.
Let's go.
Yeah. It's almost kind of too bad that the normal oil or your cache doesn't just do that.
Yeah. And you know, maybe it's been updated too, and I don't know, but I don't believe it does.
I don't think so. Right. Not currently.
Yeah. Yeah. Not that I know of people can write us if we're wrong and we'll let people know next time.
Be great to, great to do it.
I am never wrong.
Oh, okay. Sometimes.
And because like I said, it's because it's a decorator, like you could, you could make it start
working that way. That's a good featured ad. Cool. All right. Before, yeah. Before we move on,
Brian, let me tell you about AI in real life. Wow. Yeah. So this week's sponsor, this episode of
Python Bytes is brought to you by the IRL podcast, an original podcast from Mozilla. So thank you,
IRL and Mozilla for supporting the show. If you're like us, you care about the ideas behind technology and
not just the tech itself. Obviously we do a podcast on these things all the time. So we love talking
about it, thinking about it. And everyone out there knows that tech has an enormous influence on society.
Many of these effects are hugely beneficial. Just, you know, you think about walking around with your
cell phone. You have basically the entire sum of human knowledge just constantly with you. Other
influences can have, you know, negative effects. And I really appreciate that Mozilla is always
looking out for and working to mitigate these types of negative influences tech has in all of us.
all of us. So if these ideas resonate with you, you should definitely check out their podcast,
IRL, the IRL podcast. It's hosted by Bridget Todd. And in this season, IRL looks at AI in real life.
Who can AI help? Who can it harm? The show features fascinating conversations with people who are
working to build more trustworthy AI. So just some of the examples of episodes, there's an episode about
how our world is mapped, like Google Maps style mapped with AI. And what's really interesting is
the data that's missing from those maps tells as much of the story as the data that's there. So also
an episode about gig workers who depend on apps for their livelihood. And it looks at how they're pushing
back against algorithms that control how much they get paid, seeking new ways to gain power and autonomy
over data and creating better working conditions. And finally, for political junkies, there's an episode on the role that AI plays when it comes to the spread of data.
This information around elections, a huge concern for democracies. You hear a lot about the US democracies, but more broadly, absolutely across the world. And I just listened to the first episode,
the tech that we won't build, which explores when developers and data scientists should consider saying no to projects that can be harmful or strongly against their beliefs,
even though, sure, you could technically build them, you know, just because you can, you know, should, should you? Anyway, if this sounds like an interesting show, try an episode for yourself,
just search for IRL in your podcast player or visit pythonbytes.fm/IRL links in your podcast blur show notes. And thank you to IRL and Mozilla for supporting our show. Thank you.
And strong.
Yes, thanks.
So I want to talk about organizing your code to actually organizing your Python code kind of structure structuring projects and everything. But there's more than that. So I ran across this article called organized Python code like a pro. And yes, it's got a lot of great advice. And it's opinionated. It's by one person, of course, but but I think it's, it's for the most part, really good stuff.
And also, a couple of things that I don't normally see in these kinds of articles, and there's not too much weird stuff. So, sometimes it's a little, sometimes it's a little too opinionated, but this is obviously where you can see where some of the opinions are held.
So, take a look at, it talks about structuring your project. for instance, one of the first things is use a source directory, SRC. and so I try to do this and I used to do it because there was a, there was an article about, about having your tests be seen.
So basically if I, if I'm doing a pack installable package, I'd like to have my tests, see the installed package, not the local files.
And, that happens sometimes if you're running like say py test or unit test from the top level directory, and it might, it might see the top level module and you don't want it to.
So source is a way to hide that, but there's ways to get around that and testing. So, I don't, I don't really, it's not really a solid, solid argument as it used to be.
This argument really is just, it looks nice, in your, in your code editor that you, if you, if you like, here's an example of a non, a non source project where you have a couple of modules within the project.
And, but alphabetically they fall below there around your, your, you've got your test directory and your pyproject.toml and your source codes on both top and bottom of that.
That's confusing. So I actually kind of love this simple argument of just combine all the source in one place. It's nice. so I do like that too.
I know the, the, the first reaction to this though, is you're going to put a package level directory anyway, and having a package level directory in there instead of your, if you have a package,
instead of, this, you know, source or something that works too. But anyway, this is kind of interesting.
The one thing that, that kind of gets me and it shows up here is this, this, this author is considering what I, so we have a problem in Python of what a, what a package is.
A package is something I install from PyPI, but it's also within this Python documentation. Sometimes it's just a directory with an init file in it. I don't know how you, so Python or Michael, you teach people about that.
Do you ever like, do you stumble with this part or just.
Both seems complicated and overly simplistic for me. I think one of the challenges really I often run into is how do I organize my files? If I want like a sub module, I want simple import statements, you know?
So, okay. So do you think I don't have, yeah, go ahead.
Do you think of directories with stuff directories within a net as a module or as a package or do you use.
I do, but often I, I try to dodge that bullet and just not.
Not talk about it.
Not really get. Yeah. Well, honestly not talk about it. If you're building a library, this matters very, very much. If you're building an application, a web app or a CLI app or something, it often, it doesn't matter because you're just running the top level, some top level, like main or app.py or something.
And then it, it'll just pick it up, whether it's a module or, you know, a package or just a directory.
So I guess, regardless of like what we call directories, whether we call them modules or packages, this, this article calls them modules.
So then it goes on to talk about some other cool stuff. Let's, let's go down naming things. So it, it talks about that. There's really no files. There's a, there's modules. So, it also, also there's no directories.
They're all modules, but the, that that's okay. So this is some of the opinion stuff that you can, it's interesting. You can skip over it. But the, the, the thing that I thought was interesting is these module names, they should be, they could be plural names.
And I never thought about that. And it, it kind of makes sense. like if you have, it gives an example like drivers, drivers would be a module. Yeah. It'd probably be the S on there makes sense. So it's a, you know, keep a, keep config and main as, as single, but, most things that have an S on the end. I never really thought about that before, but it does make sense of like, from crawler storages, import, get storage or something.
I don't know. Yeah. Yeah. it's, it's just a nice little extra thing. and then talks about naming functions and, and stuff. so functions, I, this is something people get wrong all the time. So it's good to talk about it. Name your functions with verbs. It makes your code a lot clearer if your functions or methods or verbs. And even unless you have to jump through giant hoops to make it work. But if you have to jump through giant hoops to make a verb work, maybe it's not really one function. Maybe it should be two or three, but we'll see. Anyway.
Yeah. Or property instead of a function or property. Right. and then class names. One of the things I never thought about it also was class names should be, singular. So classes should be singular unless it's a, it's, unless it's really a container. So don't name, don't name a class orders because it's going to describe multiple orders. It's, it's an order. It's an order class, not an orders class. So that's a, I, it's a good thing.
That the, the, one of the things I loved about this article also is there's two things that we kind of talk about. We use a lot, but nobody, I don't think very many people talk about it too much. And well, it's the dunder init thing. I'm going to hop down the, not the, the dunder name equals dunder main that's used all the time. and so it's good to talk about that of, if you want to execute a module itself, use that. But the, if you, one of the things I tried to do recently that I kind of didn't know how to do right off the bat is a directory with an init.
But if it also has a dunder main, then you can use the dash M, thing on it. so if you include like dunder main, then you can use, like, Python dash M module name, when you're interesting.
Okay. and cause I had a, I had a library I was working with and it was like, I'm, I'm using dash M for everything else. I'd like to have the entry point for my application be usable. If I do dash M also, how do I do that? And this is how you do it. So it's kind of neat to have this in right away. Cause I don't, I don't know if it's really a beginner thing, but it's still kind of cool.
Yeah. I like it a lot. It's like entry points, but simpler.
Yeah. anyway, so decent, decent article. there's some, some opinions there, but that's okay. We like opinions.
Absolutely. We do. We do. All right. Well, do you know what else we like, Brian? Follow up.
Yay. I was going to do this. I'm glad you're doing it.
Too late. I grabbed it. I grabbed it. Cause this one is a good one. So remember last week you spoke about CLI apps and doing OAuth.
OAuth and you've got to remember the tokens you get the example you gave us from Twitter, but it could be from all over the place.
So Trent, we got a, multiple pieces of feedback. One about encrypting the stuff that goes into your user profile.
I can't remember who, but I apologize about forgetting the name, but someone sent in a message that says, well, the AWS CLI just puts your tokens straight there unencrypted. So there's that.
Um, I said, maybe you should encrypt them somehow. And I agree with that, still, but Trent sent in this project called key ring and key ring is hearing or vault vaults, those types of things.
There are ways sort of more, managed central stores of this type of information, right?
So you can see that on macOS you hear, and it put it in your OS X key chain, right? You probably heard that or the windows credential store or those, those things that the actual operating system is protecting from other apps to go look at it.
So it's basically just encrypted login password or, or tokens. Yeah. So this key ring thing that suggested was, is something like that, but it works to Python library.
It works across platform and it works with different backends based on both what platform you're on and other things you might decide.
So it's, a library that gives you access to system key ring services from Python, which I think is fantastic.
So on macOS that's key chain on, Linux, it's the secret service or the KDE four and five K wallets.
And then on windows, it's the windows credential locker. Okay. Right. And so in there you can just call, set password and get password and off it goes.
And that's pretty much it. Right. But it's stored in a nice encrypted, not just encrypted, but protected access, way for the OS.
Yeah. So I actually forgot about this. where I actually use this for testing, all the time, but I never thought I didn't think about using it for a command line application.
Um, so it's okay. How do you use it for testing?
So we have, so some of the issues are we have, we have, different devices that we're testing against that are password protected devices.
And so you had, in order to, to access them, you need a, login and password, to run, run commands against them.
And then, so to be able to do that, we need the, like if you're SSHing into something or something like that, that's part of your process.
Uh, you've got to, you've got to, you have to have those credentials somewhere and we don't want them in our source code.
Uh, that's the gist of it is, is we don't want them.
We don't want them, just to, to be, yeah, we don't want them in the source code and checked in to get lab and to have the whole company be able to read them.
Um, it's, it's still protected.
It's internal thing, but maybe you're on get lab, or github or something.
And it's, it's a public repo.
You don't want any passwords right there, but you can have them stored on your local machine and then pull them out with key ring.
Um, right.
It's surprised me a little bit that they're just, that get passwords a thing.
I kind of expected it to be like a, like get the, get the password hash or something.
But I have to remember this isn't, this isn't verifying passwords.
It's having them to be able to send them to another system.
Uh, so right.
Ideally that one is storing the hash, not the real thing.
Yeah, exactly.
So, yeah, yeah.
I don't know if it would want to see.
So I don't know if this would be, this is still cool and I'm glad we're covering it, but I was,
my original question was around, is this a re what's a reasonable thing to store passwords for sessions for command line application?
And I don't know if key ring would work, but I haven't tried it yet.
And maybe if you have a set password, maybe it will work.
Maybe it stores something locally.
So I'll have to try it out.
Yeah.
I think that it will.
Okay.
The question that I was wondering is what about the get password?
You know, is that restricted to the process that put it in there?
Yeah.
Or is it anything running on the system?
Yeah.
Yeah, exactly.
Okay.
Can you just start arbitrarily asking for stuff?
Probably some restrictions there, but I don't know exactly what they are.
Uh, handful out in the audience says, I'm not mistaken.
Poetry is using the it's, it's installed.
So that's where your PI PI credentials get installed.
And you can check out issue 210 from poetry.
And down here somewhere says, they talk about ways in which you could store.
And it says, why not just make key ring a dependency?
Okay.
Yeah.
If this approach, why not simply make hearing and so on?
It talks about, basically using this to store your PI PI credentials and that's a CLI app.
Perfect.
Then we have, it sounds like a pretty good match.
Yeah.
Nice example.
Yeah.
You can just follow along what they're doing there.
So thank you, Penfield for pointing that out.
Yeah.
Well, anyway, I don't currently have any use for this.
I think it might be useful even outside of, I have this interactive application, for example,
storing secrets.
You know, if you want to have the database connection string to your app, right?
This might be a good way to do it.
Uh, and one other thing that's interesting is you can have third party backends.
So you could have just encrypted text files.
You could have, the D bus API for Linux.
Um, Google sheets.
I don't know about this, but.
It does say for use with IPython secrets.
So maybe it encrypts them, but more realistically, we've talked about Bitwarden before, open
source password manager, which is really nice.
I use that for a few things.
Okay.
So that has a CLI aspect.
You could have Bitwarden as a backend.
Uh, you can write your own as well.
And one password has a CLI option as well for storing SSH keys even.
So you could even put your SSH keys in there and whatnot.
I don't know if this would pull it back correctly, but there's a lot of,
ways to store things and say one password and then access it with a CLI.
And maybe you could plug this in.
So just, it's another provider, which is cool.
Yeah.
Anyway, it seems really nice to me.
Uh, if I have a use for it, I'll definitely look into it more.
Yeah.
Cool.
Nice.
Yep.
All right.
Hey, that might be all of our topics for the day, huh?
I think so.
Yeah.
So you got any extras?
I just, I just wanted to say that I am, I'm working on a couple of things.
I'm editing my pytest course, of course, still working on that.
Um, but the other thing that I just started, which I'm super excited about is I just started
taking a FastAPI course.
Oh yeah.
It's really neat.
The instructor's awesome.
Yeah.
Awesome.
Yeah.
Thank you.
That, yeah.
That's the FastAPI course.
This live course that I'm doing this week and next week.
Right.
Yeah.
So I'm taking it from Michael and, if anybody, if anybody is, you've never taken a
pick in one of the online courses with Michael or a live course, it's just really excellent.
He's a good instructor.
So it's good.
Thank you very much.
Yeah.
I love it.
We're having a good time just playing with code as a group.
Yeah.
How about you?
I have, I think I have some extras just really quickly here.
Um, Brian skin, who's been a co-host before sent us a tweet and said, attention, Python
bytes.
And that went over to, this message from Jeff, Jeff Huntley.
And it says, get lab.
Are you all right?
And this is a link to an article from the register and says, get lab plans to delete dormant projects
in free accounts, hoping to save a quarter of the hosting costs by binning repos that haven't
been touched for a year.
Thanks.
Is that, that's a little nerve wracking because just cause it hasn't been changed doesn't
mean it's not useful.
Yeah.
Yes.
Oh, maybe I keep my recipes up there and I haven't added any recipes.
Yeah.
Maybe nothing's changed or whatever.
So a couple of things, PSA, if you have a get lab, get lab project, you know, maybe
just touch, just add a period to some text file or something and check that in.
Spam your own repo with like, trivial PRs.
Yeah.
Exactly.
Yeah.
Exactly.
I fixed this misspelling here by changing the word and the more, oh, Mario Munoz says
they may be reverting this.
Okay.
So this was just from four or five days ago.
Yeah.
Okay.
And Pamphil says, yes, they did.
Okay.
Well, it sounds like they had the same face.
Many people had the same reaction that we are going, oh boy, this seems like a bad idea.
I'm glad this was changed.
Yeah.
Uh, Pamphil says because of the huge backlash I can imagine.
Yeah.
All right.
Well, I guess they'll have to continue to pay their million dollars extra per year
to host things that people put up on there where they said they would host it.
Yeah.
Well, hopefully they, okay.
Even if you did that, hopefully they would like email people at least.
Hopefully your current email is there.
Yeah.
Kind of like Google voice.
Please log in with the next, within the next 30 days to keep your phone number or whatever
it is they always did to me.
Okay.
Well, with that, I think, brings us to some jokes.
You got some jokes to tell and I brought a quick one as well.
Okay.
Want to go first?
Uh, sure.
I'm, I'm not going to read the ones up here, but I got them.
I got a couple of jokes from a place called, from a GitHub repo.
That's a dad style programming jokes, which is perfect for me.
So, I got a couple, how do programming pirates pass method parameters?
I don't know.
With varargs.
Awesome.
Okay.
Second one.
Um, how do you get code?
How do you get the code of your bank vault?
Like, so you can break into the bank.
I don't know.
You check out their branch.
This is bad.
Nice.
I love it.
And then, I, one of the things I liked on the top of this, it says, unfortunately,
these jokes only work if you get them.
Uh, bad.
Oh, so good.
And it's a GitHub repo.
So that's actually fitting.
So anyway, it's very, self-referential, very meta.
Okay.
How about you?
Uh, here's a quick one before I put it up on screen.
You know how there's this constant not built here syndrome.
Like, sure.
This key ring is cool, but did we build it?
No, I bet we could build a better key ring than that.
And like, we'll get a team together to build key ring.
Right.
So here's a picture of, normal people acting like developers.
So there's these two construction workers with their hard hats on and there's a screwdriver
with a $2 tag on it.
Cause it was just purchase.
And one guy's outraged.
What did you buy a screwdriver instead of building your own from scratch?
Exactly.
Yeah.
Um, yeah, pretty good.
What you're using Hugo.
Why didn't you build your own blog engine?
Exactly.
First, I'm going to build my own markdown parser so I can have better tables.
Let's go.
Exactly.
Yeah.
Yes, indeed.
So, all right.
Well, excellent podcast as always.
Thanks for being here.
Thank you.
Yeah, you bet.
And thank you everyone for listening, watching, however you've been part of this.
Yeah.