Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 207, recorded November 4th, 2020. I'm Michael Kennedy.
And I'm Brian Okken.
And this episode is brought to you by us. We'll tell you more about that later.
Brian, how you been?
I am excellent today. A little tired. How about you?
Yeah, quite tired, actually. Quite tired. But I'm doing all right.
Life goes on, and we continue to work from home and all those things.
And, you know, luckily our industry and our tools were built for that world.
Yes, I'm very fortunate. Yeah, absolutely.
So speaking of fortunate, I think we're fortunate that Sebastian Ramirez created FastAPI,
because we've talked about FastAPI before. It's super neat.
We've talked about Pydantic before, which is a really cool way to take data class-like things
and automatically bind them with automatic conversion, validation, and whatnot for data.
That just comes from a JSON dictionary somewhere or just a Python dictionary.
But it often is JSON being submitted to a web, some sort of web API.
The reason I bring up FastAPI is I've been doing a lot of stuff with it,
actually working on a series of courses around FastAPI as well, which is super exciting.
And maybe I'll mention that briefly later.
But one of the things that bugs me about FastAPI is it's so API-oriented that it's tricky to know what to do
when you just say, I just want to create a website that has like a couple of pages and then some APIs.
So for example, if you just create a couple of APIs now and they're like, say it's about weather,
it'd be like slash API slash weather slash report, API slash weather slash latest or whatever, right?
Well, if you just click the, you know, you run it, you just click the little link in your IDE or VS Code or whatever
and open it, what do you get?
404.
Probably not the best response that you could imagine is that like the default behavior is just to like open up the site
and it says not found.
So you got to like type in this stuff.
Anyway, it supports Jinja in like a sort of manual way, the same way that Flask does, I guess, more or less.
But I wanted a better way to have HTML pages inside of my FastAPI app.
Because if you're going to build an API, there's a very good chance there's like two or three pages that you need, right?
Yeah.
So I wanted to have a couple of things.
I would like to be able to have a simple function that is a web view method.
It could be something that is like a HTTP endpoint for an API, but more likely it's going to be one of these pages.
And I want to just be able to have it return dictionaries and say that it takes some kind of template, right?
So put a little decorator and say this one has a template home slash index.html.
And it's automatically going to take that dictionary, send it over to whatever template engine you choose, turn it into HTML and send it back.
You know, set the content type to be HTML, all of those things, because by default it's JSON.
Okay.
So you'd like it to be the JSON data, but have it be formatted like HTML.
Well, often with these templates, what you need to do is like, suppose you've got a bookstore and you want to say, here's the categories.
You have to somehow pass data over to like categories.html and it'll get like a list of categories.
And then you'll iterate over them and generate the HTML to that dictionary being passed over.
That's the data that you're basically providing to the dynamic HTML, right?
So what I did is I went and I created this thing called FastAPI dash chameleon.
Oh, nice.
So if you want to use the chameleon template language, which previously was not really in any direct way supported, you could import all the libraries and just make it do it yourself.
But that's kind of painful.
Now you can just put a decorator, you know, from FastAPI underscore chameleon import template and just say at template and point some file at it and boom, you return a dictionary.
Now you have chameleon as your template language.
Oh, cool.
That's neat, right?
And it also, I found a way to write a decorator that will automatically adapt whether it's an asynchronous or a non-asynchronous method, right?
Because normally the decorator, what it does is it has like a wraps and has an inner and then like the inner function does stuff and then calls the actual thing it's decorating.
Well, if the thing it's decorating is async, you got to do one thing.
If it's not async, you got to do another thing.
So how do you tell?
There's a cool library called inspect, which will let you actually look, even if it has a little wraps decorator that tries to lie to you about what it is, it'll show you whether or not it's a coroutine, which is pretty cool.
Oh, nice.
Yeah.
So on top of this, Mark Brooks saw this and said, that's awesome, but I don't really like, I don't use chameleon.
I like Jinja.
So he forked my repo and created a FastAPI dash Jinja.
So now you can do exactly the same thing if you like Jinja.
And guess what?
If there's someone out there that really, really wants to use, I don't know, Django templates or Mako or whatever, right?
That's like five lines of quote away from doing that as well.
The reason I think it's important to add these other template languages, not just say, well, it supports Jinja, so you're good.
The reason I think it's important is if you've got some web application that has APIs, it already has chameleon templates or in the other example that doesn't exist yet, some Django thing.
And you want to convert it to use mostly FastAPI, but you don't want to rewrite all the HTML, CSS and JavaScript.
If you can make it render those templates, then it's so much easier to move from some other web framework over to FastAPI because you don't have to touch the HTML.
You don't have to touch the CSS.
You don't have to touch the JavaScript.
There's just that middle part where you like handle the request and that's actually pretty limited.
Yeah.
So that was my idea for creating this was hopefully to make make it possible for people who have other stuff written in chameleon to move to FastAPI really easily.
And then also just to like sort of inspire a cleaner programming model.
Yeah.
I actually was going to ask you if it was possible to do something like that with Jinja and you already answered that.
Yeah.
It's actually, it's built in, but the way it's built into FastAPI is not with like a template decorator.
It's, you know, you actually go in and you say the actual file name and then you pass a bunch of it's like, it's not super clean.
So it is, it is quite clean the other way around, which is cool.
Yeah.
Nice.
Cool.
Nice.
Carrying on about APIs.
Yeah.
Maybe a little less clean of a way.
So yeah, we've been very excited about FastAPI recently for APIs and in the Django world, there's the Django rest framework is quite popular.
But what if you just want to use vanilla Django and write a rest API?
Adam Johnson took that on and said, yeah, of course you can do it, but you can also do it in one file.
So we're going to link to a little article where he has a simple rest API completely written in one file as a one file application.
It's a, it's a little API that gives you information on the characters from Rick and Morty, specifically just Rick and Morty.
And that's it.
But it's a good example.
I'd like it.
It shows, shows you how to do, how you can do redirects.
And so like, like for instance, the endpoint, one of his endpoints is characters.
So if you type your application slash characters with a slash at the end, it should return, Jason data with the information about Rick and Morty.
Now, what if you just don't put anything, if you put characters without the slash or don't put characters at all, like your homepage thing, he shows you how to do redirect.
So you can redirect two characters and, you know, it's pretty simple example, but it is kind of neat that you can do it off the shelf, Jason or off the shelf Django.
He also shows he's got some hard coded data classes within the application, but it's easy, you know, not that difficult to imagine that you can extend that to something that reads it out of a database or some other part of your system.
Yeah, absolutely.
And it's like 63 lines of code, which is not too much for a non-trivial little example API.
You know, I'm not necessarily on board with putting this in one file, but I am on board with this idea of like these simplified things.
You know, when you hear about Django, you always say, go ahead.
If I want an API, I'm going to have to add Django rest framework and all these other things to it.
If say you're in Flask and you want to work with users, like, well, I've got to add the Flask SQLAlchemy add in.
I've got to add the Flask users add in as an extension.
And maybe I want session.
So I got to add Flask session.
Like none of those things are necessary per se, especially on the, on the Flask side.
Like there's so much of it.
It adds like one or two lines of code that you don't have to write.
And now you have all the overhead of depending on making sure that that thing works right.
And the way you work with it is the way you want.
And so having just a, here's the bare bones view and you can add in stuff if you like.
I'm a fan of that.
Yeah.
I'm also thinking like, let's say you have a Django application already and you built it,
not intending anybody to use it as an API.
And somebody says like maybe an internal application, your business or something.
And somebody says, oh, this data here where this graph is, can we get that as an API so that we can, you know, use it in something else?
And this would be, you know, a good example to be able to just add.
You can use Django REST framework, of course.
But if there's just something simple you need to add as an API, this is a way to do it.
Yeah.
No, it's cool.
And like, I do feel like these add-ons and these extra layers that you add, they better add a ton of value because they're also adding overhead and dependencies and breaking changes and like all that.
So yeah, if you've got something working, you want to just add a little bit of, you know, here's a few JSON endpoints.
Let's do that.
Yeah.
And for people that really enjoy this article and want to hear more from Adam, I've had him on Test and Code a couple times.
So we'll drop links to those episodes in the show notes.
Yeah, right on.
Now, before we get to the next one, which is a pretty big item, I just want to say this episode is brought to you by us.
Of course, it's over at Talk Python Training, Test and Code Podcast, and something to do with pytest.
Do you do anything with pytest?
I heard that pytest is a thing that people use.
Do you do anything with that?
Yeah.
So, yep, wrote a book on pytest.
I still think, and I still get call outs on Twitter saying it's the best book they read to get started with testing,
and they got excited about testing with reading Python, testing with pytest.
So it's a good book.
Yeah.
Awesome.
Yeah.
And over at Talk Python Training, I'm now working on a three-part series, so like three, four-hour sections or so,
on building FastAPIs and also like testing them and putting them in production and fun stuff like that.
Oh, that's exciting.
Can't wait to watch that.
Yeah, that'll be fun.
Yeah, yeah, that'll be super fun.
So anyway, that's coming.
People can go over there to training.talkpython.fm, you know, sign up to get notified and visit
Testing Code and listen over there as well.
Yep.
We also have Patreon, right?
Oh, yeah.
So had somebody reach out to us for the Patreon and say, hey, you guys mentioned that a whole bunch of people sponsor you for a buck a month,
but they said, that's the only tier you have.
And so Michael and I are definitely going to talk about in the future whether we should add some more tiers.
However, there is an option.
Even if you sign up for a dollar a month, if you want to send us more, you can change that within the Patreon thing.
So we'd appreciate it.
Yeah, much appreciated to everyone who supports us.
In all the ways.
Every way is valuable and appreciated.
Speaking of valuable and appreciated, we often talk about the Stack Overflow Developer Survey.
I mean, in my mind, there's two major surveys that take the pulse of the developer community.
One is the Stack Overflow Developer Survey.
The other is the PSF survey, which, by the way, just got extended to three more days.
By the time this comes out, that'll be already in the past.
But, you know, that's hopefully people have taken that.
We've talked about it before.
And we talked about the 2020 Stack Overflow Survey coming out, I believe, and I told folks to go take it or you did.
And then we just didn't follow up, right?
But the survey results are out, so I thought it might be fun to run through the survey results.
Yeah.
Yeah, and I just want to be clear.
Like, I kind of lost track of this.
I don't know exactly when this came out, but it's not brand new.
It's like four, five, six months ago.
But I just, you know, we didn't talk about the results.
We just talked about the survey.
So let's run through some of the things that are here.
Now, the 2020 Stack Overflow Survey is focused a lot on demographics and background and education and all those sorts of things.
And if you're interested in that, definitely go check it out.
There's a lot to see there.
Just because of the format.
I'm going to focus mostly on the tech side that they covered here.
Okay, so not whether we have a full-time job, how many of us work from home, none of that.
So some of the most popular technologies, and I just want to point out, I think the PSF survey and the JetBrains folks who worked with them to put that together is in a much better place.
This is a wacky, wacky, wacky survey, but it does have some good questions.
Yeah.
I'll expand on the wacky a sec.
But if we look at the most popular languages, most popular technologies, web frameworks, databases, and so on, certain languages, we have JavaScript, Python, and Java.
And JavaScript has 68%.
Python has 44%.
Java has 40%.
That's good, right?
I mean, like, everyone knows JavaScript's pretty popular.
So what's wacky here?
Why is this weird?
And I'm not necessarily saying there's not 68% of the people doing Node.js.
They may well be.
But do you know what language is between JavaScript and Python?
CSS.
Dude, I know no application that is shipped running on CSS.
I can't even compile CSS.
I could probably compile SAS or less over to it,
but I can't compile CSS to a running application.
It's not a programming language.
Yeah.
And SQL.
Perhaps it's true and complete, but yeah, and SQL.
SQL is a thing you use within a language.
Yeah.
It is not a programming language that builds things, right?
Yeah.
So they have this, this is what I was talking about where it's wacky.
And JavaScript is in this world, right?
They needed to ask very, very clearly, do you work exclusively in JavaScript as a Node.js developer or a pure front-end developer?
Or did you check, I also use JavaScript and CSS and Python?
I also use JavaScript and CSS and Java, right?
And so the JavaScript one has like bundled up all these, I do anything in the web on any language plus the Node.js developers, right?
I think the contention there is a little bit closer, but it still wouldn't surprise me if JavaScript was actually in the lead.
I don't know, I feel like I'm all hyped up on like percentages and trajectories given all this election talk that we just went through.
Well, I remember checking the box for JavaScript once and like, yes, I use JavaScript.
Yeah, exactly.
But what does that mean?
I have an app that does use a little bit of JavaScript and I looked at the code once.
Right.
Did you do $document.ready?
You're a JavaScript developer, like not really.
Yeah.
On the other hand, if you build an app with Vue.js or Angular, you're a JavaScript developer.
If you build something with Express a Note, you're a JavaScript developer.
So I think it's a little bit weird that they didn't like really clearly make that distinction because you can't put two buckets and add up those numbers next to other buckets and make that make sense, right?
CSS is the same thing.
Like no one would check it if you said I primarily code in CSS to build apps and ship on the CSS platform.
Anyway, okay.
So web frameworks, you know what the most popular web framework is?
Well, I do now that I just looked.
Do you believe it?
But I wouldn't have guessed this.
Do you believe it?
No.
It's jQuery.
Nobody.
How can jQuery be in the same category as like Django?
Yeah, yeah, yeah.
It's even on the front end side of the JavaScript front end frameworks.
There's Vue, there's Angular.
All those are really legitimate things.
jQuery is not the primary way in which people write web applications.
But a lot of people use it.
So it's in there.
All right.
So anyway, those two are a little bit weird.
I take away.
Python is really quite popular and up there.
The Python web frameworks, I think there's just so many.
They don't filter very high to the top individually.
Databases is much clearer.
You know, you don't have to talk about other funky stuff.
So for the most popular ones, we have MySQL at 56%, PostgreSQL at 36%, Microsoft SQL Server
at 33%, and MongoDB at 26%, which is actually pretty high in my understanding of the world.
But that's pretty cool.
For platforms, as a developer I work on, not I deploy my code too, we have Windows at 46%,
macOS at 28%, and Linux at 27%.
So again, most common platform for development is Windows.
So we can't forget them when we build our packages and whatnot, right?
Steve Dower goes on and on about that, which is good.
My favorite part of these surveys, though, that these are legitimately good, is the most
loved and the most dreaded, the most wanted section.
So the most loved languages are Rust, TypeScript, and Python.
Those are neat.
TypeScript personally drives me a little bit crazy, because it's like so picky.
It's like the type annotations, but you don't get it exactly right.
It's not going to work.
Anyway, it's still pretty neat.
Rust, I would like to learn.
Python, I know something about.
The most wanted languages, I think, is also interesting.
So most loved is I work with it and I love it, versus I dread it.
Or I don't get to work with it very often and I'd like to do more, is the number one,
Python.
Number two, JavaScript.
Number three, go.
Go figure.
Nice.
Yeah?
Most dreaded?
VBA and Objective-C.
Does that surprise you?
Well, in Perl's number three is still interesting.
It still brings dread.
So that's the languages.
And then the databases, most loved, Redis, Postgres, Elasticsearch.
Again, Elasticsearch is like CSS a little bit to me.
Is that really a database?
Anyway.
And MongoDB.
So those are all quite high.
Most wanted database is MongoDB and Postgres are neck and neck at the top.
Okay.
And you still do both.
You do a lot of Mongo, right?
Oh yeah.
I love Mongo.
I think it's sweet.
Okay.
So clean and easy to work with.
It's been years since I've had to do a database migration and production.
I love it.
As in, like, I changed my schema and now the app won't run unless I apply this script.
Yeah.
So anyway, rounded out, most dreaded database, IBM DB2.
Doesn't surprise at all.
Anyway, that's the survey.
I just want to give a shout out or like a call to the community.
If you have any influence on this, find a way to separate things that are unequal, right?
Don't put just I do some JavaScript from I do some C++.
Those are not equivalent.
Or I do some jQuery and Angular and I do Django.
Those are just not even in the same category.
And it really drives me crazy that they're put this way.
And it just makes me appreciate the Python Software Foundation survey more because it had
less of this weirdness.
Yeah.
There's some weird things that get bucketed together.
Yeah.
Interesting.
I would say the PSF one is more regular, wouldn't you say?
More regular.
Oh yeah.
Nice transition.
Thank you.
But before we move on, there was another.
Nobody else will care about this but me.
But what was the other survey that is closing in a couple days?
The PSF survey.
The one at python.org, I believe.
Let's see.
Is it still up there?
Okay.
I don't know where it went.
But yeah.
Yeah.
It's right there in the middle.
Can I mail in my ballot and get it as long as it's postmarked in time?
Well, if you postmark it at the right time, yeah.
Sorry.
Couldn't resist.
So, regular expressions.
So, I'm sure we've talked about regular expressions before, but they occasionally crop up in my work.
I always forget them.
I learn them and then I forget them.
I have to learn them all over again.
So, this is going to be helpful.
Yeah.
So, Amit Chaudhary, I think, wrote a visual guide to regular expressions.
And this came out recently.
And this is kind of a very nice, gentle introduction to regular expressions by building up.
And I think it helps you build up a correct mental model of how they work.
He utilizes visual highlighting as if he kind of went through it with a highlighter pen and highlighted the different things that could be matched.
So, it goes through a whole bunch of stuff.
It starts with just a specific character.
So, like, if you have a string and you're matching, like, the character A or something like that, what would it hit?
And then moves on to white space and digits and word characters.
And a lot of these gentle introduction type things go through some of the basics and then sort of stop there.
And what I really love about this is he talks about some of the more advanced things like pattern negations.
So, like, and why they're weird.
Like, slash lowercase d is digits.
Slash uppercase d is everything that's not a digit.
And some of these exclusions.
Talking about anchors, like, beginning and the end of the line.
Character sets with brackets.
And then ranges with a dash within the ranges.
You're talking about repetition.
And this is kind of something that threw me off when I first learned about them.
Using curly brackets.
I was used to using star for zero or more items and plus for one or more item.
I think.
Or maybe it's the other way around.
Yeah, that's right.
And then, but you can use a question mark for it.
Only can be one, but it can be there or it doesn't have to be.
And then the, if it has to be a certain number of times, you can use curly brackets for saying it needs to be two of these or something like that.
And then it goes on and says, okay, well, now you've learned all this stuff.
How do you put it in place with Python?
And with Python, you use the, one of the ways is the RE module for regular expressions.
So it goes through a quick example of using find all, match and match group and search.
So if you're a Python developer and you have to deal with some regular expressions, I think there's definitely something to check out.
Yeah, it's really nice.
And it's a very gentle introduction.
So people can just go through and the coloring and stuff.
Yeah.
Because normally a lot of these presentations of regular expressions, man, it's like write only.
You know, you look at it like, whoa, that is a mess.
And then, you know, then it's gone.
Like you could write it, but you could go back and read it again type of thing.
Yeah.
So this is nice.
This is good.
Yeah.
Cool.
Nice one.
Yeah.
I can't take credit for that one though.
Somebody else wrote it.
You probably shouldn't take credit for it.
Right.
Did you, did you create it?
I mean, like you probably shouldn't.
No, I just brought it up.
So I don't really know the whole story with this next one, but it's, I entitled it taking credit.
And this was based on a GitHub project and a tweet by Tim Nolet.
Tim Nolet, I'm not entirely sure how to say his name.
Hopefully one of those works.
And he created this project, which is called, let me check it out, Headless Recorder over
at Playwright, I believe.
Let's see.
It is, yeah, it's called Headless Recorder.
And so what it does is it allows, it's a Chrome extension that allows you to create scripts that
interact with either Puppeteer or Playwright that do just like web automation.
You know, a little bit like non-programmatic solenium or those types of things, right?
Yeah.
Fine.
That's all cool.
So there's a bunch of JavaScript that you write in there.
That's pretty interesting.
And the tweet says, I'll just read the tweet and then we'll go from there.
It says, oh, AWS Cloud, I really do love you.
But next time you fork my open source project and present it as your new service, please
give the maintainers a short, nice, good job, kids, or something.
I mean, it doesn't necessarily have to follow the APL version 2 license and stuff, but at
least a little credit would be great.
Wow.
So there's also a linked announcement about this thing called AWS CloudWatch Synthetics
launches a recorder to generate user flow scripts for Canaries, which is, you look at the syntax
in the examples, it does now say credits based on headless recorder at the bottom, but I'm
pretty certain that it didn't say that in the beginning.
I mean, I don't have like a diff of the webpage, but it would not be surprising.
I wouldn't think he would put that up there if at the bottom it said that.
So now it does.
Anyway, this is not relevant to this project really at all.
It's more just a conversation about what do you do when big companies adopt your open source
project, but don't give you credit.
I think that's lame.
Well, I think it should be even more than that.
I mean, I think anybody that personally, if somebody else, if I had like, let's say I've
got a couple of small projects that I don't really do much with.
And if somebody else took that and forked it and then like did something big with it and
started making a startup or some money with it, fine.
Good for them.
But if it's a big company like Amazon.
It's a Google, Microsoft, Apple, AWS sort of thing.
Anytime.
I think credit is due.
If you're not the one that came up with it, if you just forked it, ran with it, I think
giving some, and that's typical.
I mean, we often give credit to say, hey, I ran with it.
It started here, but I did a whole bunch.
That's fine.
But a big company, I think they should both give credit.
And I think some cash should go to the original idea starter.
Yeah.
I hear you.
If it's not cash, which, you know, that might be a hard sell.
How about as we maintain this project, we sort of forked from your stuff.
We'll push changes back to make yours better.
Right.
At least some sort of, hey, we've based this on your thing, but by doing so, we're going
to make that thing better because we've made a commitment to at least, you know, do
a little bit of give back PRs, improvements.
Right.
And also, I don't know, like, I don't know this guy, but at the AWS reInvent conference,
when they announced this, if they said, hey, this is based on this cool project by Tim,
you know, that would raise his profile and I'm sure he would really appreciate it.
Personally, a lot of my stuff's under MIT.
And so people don't have to mention me, do anything, say anything, whatever.
A few things are not, but it's, you know, a lot of it's just example code and people
are like, well, can I use this example in my commercial application?
I'm like, yes, I really don't care if you like recreate my random sample in your project.
That's fine.
Right.
I don't want anybody to have those feelings, but if I was building something useful, I'd
at least want, you know, a shout out.
I guess that's all he's asking for as well.
Yeah.
Anyway.
And they did it.
So that's good.
They did come around and do it.
Yeah, they did.
I'm pretty sure that was not the beginning situation, but now it is.
And so that's quite good.
And just given the amount of people who are in the Python space, who listen to the
podcast, they do open source.
I thought this story would be interesting, even though it's technically JavaScript.
Yeah.
I bet you could even write that JavaScript on a Raspberry Pi, Brian.
Maybe.
So I was just curious, what was the first computer you programmed on?
So the first computer that I programmed on was one of those Apple IIEs that was beige and
had a green screen, I believe.
Okay.
You started on a IIE as well.
Yeah.
But that was like in middle school or now, maybe even elementary school where it was just,
you know, something that I went for class.
The very first thing that I actually got to sort of sit down and program on, my brother
had a Commodore 64, but I didn't really use it for anything constructive.
I would say a 286.
IBM 286.
Okay.
I programmed to Apple IIE at school, but it wasn't confusing enough to me that I didn't
run with it right away.
I kind of dropped programming after that.
But anyway, I bring this up because there's a new computer out and it reminded me of this
about those early computers.
So, or the Commodore 64 is kind of the same category.
So the Apple IIE was kind of like-
This is cool.
It was, yeah, it was a higher end.
I had to, or Commodore 64 was a little bit lower than a IIE, I guess, I would think.
And then below that is the TRS-80 from Radio Shack.
That's what I had.
I had my, but anyway, so the, the Raspberry Pi 400 is out now or it's announced and it's
going to be out by the holidays, apparently.
It's really cool.
It's like, it kind of reminds me of these Apple IIEs because it's the, it's the computer
in the keyboard.
So the, the keyboard is the computer and you can even hook up two large monitors to it
because it does, it supports two displays, 4K video.
It'll do a two 4K monitors out of your keyboard.
Yeah.
And that's cool.
This one's got four gigabytes of RAM.
You both do wifi and LANs.
It has a hard landline entry point, which is good.
Four core 64 bit processor.
It just looks fun.
They're telling it as a whole kit for like a hundred bucks.
So you get a, like you can start somebody up on a computer.
Um, I'm covering this cause I'm, I was thinking, geez, do I want to get this for my kid or do
I want to get it for me?
Yeah, exactly.
And it comes with a beginner's guide and shows you how to get started and even includes getting
people a little bit started on Python and apparently.
So that's good.
Yeah.
It seems super neat.
And the processor is pretty good actually.
Four core, four gigs of RAM.
And it looks like just one of these little, you know, wifi, USB, like over the little RF
or radio frequency dongle thing keyboards that you would get.
But that's the whole computer on the back of the keyboard.
It's got the HDMI ports.
It's got the other ports, the power, everything.
Yeah.
So you got to get your own monitor, of course, but plug it in and you can get started.
And there's videos on the, on the Raspberry Pi site that are amazing watching this thing
go.
It's, it's powering two big monitors and it's just feels, it looks like it's as zippy as
a normal computer.
So I think it'd be cool for educational use and lots of uses.
So it's pretty nice.
Even for just a travel computer.
A travel computer.
Yeah.
Right.
Imagine when, remember when people left their house.
So imagine it were like that again.
And then you could go places.
But if you were just going on a trip and you're like, ah, maybe I'll just like need a computer.
I want to plug in.
You know, bring a HDMI cord, plug it into the, the TV at the hotel, plug it into some sort
of monitor at like some office you're dropping in on.
You could just take that and have, you know, do presentations and stuff.
It's cool.
Yeah.
Cause like that's true.
Cause the HDMI output, it's a lot of TVs just take that now too.
So yeah, exactly.
Just bring a little short HDMI cable with you if you need to.
And then you're good.
I'm including a linking to a video from Lee Moore Freed from Aja Fruit in there.
She says that it reminds her of the Apple TUI as well.
Nice.
I'll check that out.
Super cool.
So that's our main items.
That's quite an adventure.
Brian, you got any other, other things you want to just throw out there real quick?
Once quick thing.
I got reminded.
I ran across this a while ago and I, somebody reminded me of it on Twitter recently is a
Vim adventures.
It's Vim dash adventures.com.
Remember the dash, but it's a kind of like this adventure game, like these old going through
a dungeon sort of thing and picking up treasure and things like that.
And you just is to help you practice your Vim key bindings while playing an adventure game.
So if you're having trouble getting learning Vim, maybe try this.
Yeah.
That looks quite cool.
Actually, it's a neat little adventure game.
Now, I just want to throw out something I got from Tyler Pedersen just a little bit ago.
And this kind of comes back to the language talk around Stack Overflow that I mentioned.
And this is an update for the TOBE index, T-I-O-B-E index for November 2020.
And my feeling and my theory is that things like Stack Overflow and whatnot, those places
are often measuring like the pulse of the industry right now, whereas TOBE seems to have a little
bit of a latency, like how many legacy apps of this style are you working on and this technology
and whatnot, right?
So it's a little bit of a longer term moving average.
Well, anyway, the headline is November headline, Python is unstoppable and surpasses Java.
For the first time since the start of the TOBE index, nearly 20 years, Java and C don't make up
the top two positions.
Okay.
In 20 years.
Wow.
So Python's not a top, but it's right below C.
It's right below C.
And it's, you know, it's been a long time coming, right?
So anyway, I think this is pretty neat.
And Tyler, thanks for sending that along.
People can check it out.
Yeah.
Cool.
Ain't no joke.
But how about a joke?
A joke would be great.
All right.
So we've got a cartoon, but this one is super simple.
And I think just the words will do it.
So this is from Geek and Poke, which has some fun things.
And the title is, You Build It, You Run It.
It's all about microservices.
Okay.
So there's a woman developer and a guy developer just kind of staring at each other.
And it says, when we decide to create a new microservice, we just need 30 seconds to
get a blank microservice running in that Kubernetes cluster.
So amazing.
They kind of stare at each other for blankly for a minute.
Then the woman says, and what?
You just need another week to come up for with a funny name for it.
Two weeks.
Two weeks, says the guy.
Yeah.
Anyway, I thought people running a funky name to microservices would definitely appreciate
that one.
Yeah.
Name is the hardest thing in programming.
That's right.
It sure is.
All right.
But not this podcast.
That was a lot of fun.
Thanks for being here.
It was.
Yeah.
Thank you.
You bet.
Bye.
Thank you for listening to Python Bytes.
Follow the show on Twitter via at Python Bytes.
That's Python Bytes as in B-Y-T-E-S.
And get the full show notes at pythonbytes.fm.
If you have a news item you want featured, just visit pythonbytes.fm and send it our way.
We're always on the lookout for sharing something cool.
On behalf of myself and Brian Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.