Transcript #187: Ready to find out if you're git famous?

00:00 Hello and welcome to Python Bytes where we deliver Python news and headlines directly to your earbuds.

00:04 This is episode 187, recorded June 17th, 2020. I'm Michael Kennedy.

00:10 And I am Brian Okken.

00:11 And this episode is brought to you by us.

00:13 There's a couple of things that we're offering that I think are going to be great for you.

00:17 We'll talk more about that later.

00:19 Right now, I want you to bring us back to our youth, Brian.

00:22 Did you ever do the Lego Mindstorm thing?

00:24 No, no. Lego was just bricks when I was a kid.

00:28 Yeah, well, yeah, okay. I love Legos and I'm actually I've got like three kits halfway done right now One of them I've been working on for a long time. I should finish those anyway, cuz there's a new one I want to buy it's not out yet, but like I announced it Mindstorm robot inventor They've had different Mindstorm kits in the past for robotics and they started in 2006 or at least on the Mindstorm series There's NXT was in 2006 They did an NXT 2.0 in 2009 and then the EV3 was in 2013 And I was actually kind of disappointed with the EV3 because it was weird. It was like post-apocalyptic thing going on It was like punk rock robots or something. I don't know anyway So I think we've got an NXT somewhere in the house, but the new Mindstorm robot inventor they finally figured out that people are using these things to try to teach in STEM education and stuff and So the new one this is awesome drumroll. It supports scratch and Python. So that is super awesome it has instructions for five different robots that do lots of different kind of cool things like a car like robot and a upright like robot and and there's a bunch of sensors the Module that it has connects to six different input output ports for the sensors and motors There's even a six axis gyro and accelerometer a five by five LED matrix Five by five is not much but we could probably figure out we can hack more Color sensor and distance sensor, of course in Python. So one of the other neat things about it is The other one I'm not sure about the the older ones, but they were programmable of course with Windows or Mac but this one also has is going to have the ability to program it via an Android or iOS tablet or smartphone and even some FireOS. So like the Amazon Kindles some of them might be able to be used which is pretty awesome because even though this robot inventor is pretty expensive if a school is helping to support it or something and a kid has a you know a $50 tablet at home hopefully that'll work so that's neat. Yeah this is really cool and I think being able to program with a real programming language instead of a blocky type of programming language goes a long ways.

02:43 I think people underestimate how much kids can do with some simple text versus, you know, like, well, it's got to be drag and droppy, so don't ever make syntax errors.

02:54 And you know, if you look at things like CodeCombat.com, kids go through these dungeons and they solve like challenges to open the door, make it across the bridge or whatever with code, but it's all typing Python.

03:08 But the editor is so insanely aggressive, in a good way, aggressive with auto-complete.

03:15 Like if you type A, it'll try to auto-complete hero.attack and suggest arguments.

03:21 I mean, it's like ridiculous.

03:22 And in those sorts of scenarios, I feel like, you know, don't pull the punches.

03:26 Like give the kids a real experience.

03:29 They'll adapt pretty quickly.

03:30 I think people underestimate with the right tooling what kids can do with a text language like Python.

03:35 - Yeah, and I, so I really hope, I think so too.

03:38 And so it's exciting to have it.

03:40 I know you can't, there were ways to put control the EV3 with Python, but it was extra hacky ways and not obvious for people.

03:47 And so hopefully having this supported, and I really hope that we get more of these sorts of robot inventor things coming out from Lego, not every seven years, could we update maybe every couple of years?

03:58 That'd be awesome.

03:59 Yeah, for sure.

04:00 Technology changes fast.

04:01 Yeah.

04:02 And on a related note, I didn't do this as a full story, but I wanted to note, I also saw a project called Microscopy or Microscope Pi maybe. It's an IBM open source project to build your own modular microscope using Raspberry Pis and Lego bricks and a little bit of 3d printing and you can control it like a motorized microscope which is pretty awesome so that's neat too. Yeah yeah that's really cool. Alright well I have a theme that will become clear as I go through my items this week.

04:35 I've somehow just landed, lined up with all the items I picked in the same general area.

04:41 So I want to start off by talking about this article from Kevin Markham from dataskool.io.

04:45 And he's been putting together lots of cool steps and guides to help people get into stuff.

04:51 His area is mostly data science, but obviously on the Python side.

04:54 So he created this thing called a step-by-step guide to contributing to GitHub.

04:59 - Nice.

05:00 - Yeah, so if you're new and you haven't actually yet contributed to an open source project, it's like, here are the 17 steps in order.

05:08 And some of them are obvious, like you have to have a GitHub account, you have to fork the project.

05:14 Others are not as obvious.

05:15 Like I always, whenever I fork something, and I'm like, oh, you know, I really wanna get the changes from the thing I forked, merged, you know, sort of synchronize my fork with the remote fork.

05:26 I'm always like, what is that command again about like remote origins and, or upstream, I gotta set, you know what I'm like.

05:32 So having that stuff all laid out in a nice little do this, then this, then this guide is helpful even just for a couple of those steps if you've done it before.

05:40 So I'll just run you through the steps really quick.

05:43 People can go and see the pictures and the graphics and the explanation.

05:47 So I want to contribute to something.

05:48 I think he contributed something back to scikit-learn, but it could be any project, right?

05:52 So you start by figuring out what project you want to contribute to.

05:55 You fork it to your GitHub account, and then you check it out, you clone it locally, add loaded up, make some changes, and then you make sure you have your origin remote pointed back to the thing on GitHub.

06:08 And then the part I was just talking about, you can add an upstream remote, which allows you to say, give me the changes from the source repository to my forked version.

06:17 You always wanna get those, like maybe you forked it a while ago, but now you wanna make a change.

06:21 So you wanna grab the changes from the upstream, the original repository and bring it over, create a new branch, a feature branch for your changes, 'cause you're gonna use that for a PR.

06:31 make changes, commit your changes, push it to your fork, create a PR by clicking the green create PR button, review the PR, have conversations around it, maybe make some more commits to your pull request.

06:41 So it talks about like, if you submit a PR and they're like, that's great, but you need unit tests, how could you forget the unit test, please add those as well.

06:48 How to do that, right?

06:50 Common story, I'm sure.

06:52 Discuss it, and then once it's merged, or I guess closed even, you could delete the branch, but especially if it's merged, you don't need it anymore.

06:59 So delete your branch, synchronize again your fork with the original project repository through the upstream link, because once they've accepted your changes, your main branch will be out of sync with theirs.

07:12 So you want to do that.

07:13 And then also has a nice little tips for contributing code section as well with just some advice on how it goes.

07:19 So the pictures and like here, type this for the step.

07:22 I think this is pretty handy for a lot of folks.

07:24 - Yeah, people just need to do it.

07:26 It seems overwhelming when you start 'cause it seems like, oh my gosh, this seems like so over the top.

07:32 And actually, so at work, when we switched from a different version control system to Git, we started out with this sort of a model.

07:41 This is not an uncommon model, even within not just open source, but other projects.

07:46 Originally, I thought this is a lot of overkill.

07:49 We don't really need forks and branches, but there's a lot of benefits to doing both and you can just kind of get used to it.

07:56 and it ends up being not that big of a deal.

07:58 - Yeah, one of the advantages for what you're talking about, like inside your company, obviously it's important for open source, mostly 'cause you don't have commit rights.

08:08 So you make changes to your thing and you say, "Accept my changes," right?

08:11 But inside a company, everyone has commit rights for the most part to their project they're working on.

08:17 But it bundles it up in documents, like these are the changes to add this feature, these are the conversations around it, and here's how it got accepted, right?

08:24 It's like a nice way to go beyond just like, here's a commit or a series of commits I did this week.

08:30 I think some of them have to do with this scrum thing I said I would do.

08:33 - Yeah, one of the main reasons we kept the fork model in places so that we can, if somebody accidentally pushes up a large executable or something that they shouldn't have committed in the first place, it's easier to kill a fork off than a branch of a project.

08:51 - I see, it's like a layer of insulation of mistakes.

08:54 - Yep, yep, definitely.

08:55 - Yeah, cool.

08:56 Well, before we get on to a new language, Python-inspired language, I just wanted to talk about a couple things you can do to support the show.

09:04 Obviously, Brian and I are both doing things outside the podcast that we think contribute back to the community, that if you wanna support what we're doing, it would be great if you could check them out and consider them as you're learning Python things.

09:17 So I have courses over at Talk Python Training.

09:20 We have, I think, 170 hours of Python courses probably a couple hundred hours of exercises for people to do over there.

09:27 So if you're looking for courses or to learn stuff with Python in general, check out talk by then training and Brian, you have some kind of book, I think.

09:34 Yeah.

09:34 So I think that anybody that wants to learn how to test better should pick up a copy of Python testing with Pytest.

09:40 So book that I wrote about Pytest, it's not just, it kind of walks through all the different sorts of things you can do in the, with Pytest, but also around testing a package project.

09:53 And I think a lot of these carry over, even like switching databases and stuff.

09:56 These things carry over for all sorts of types of projects.

10:00 And I've gotten a lot of great feedback and I think it's a good thing for people to read.

10:04 Yeah, awesome.

10:05 It's a great book.

10:05 And both of those things are linked at the top of the show notes.

10:08 So you all can just check it out in your podcast players.

10:10 So I'm always fascinated with embedded Python and things like micro Python and circuit Python.

10:16 And you've got something along these lines, right?

10:18 Yes.

10:19 I ran across this, a language called SNEK, or SNEK, I think.

10:23 SNEK.

10:24 S-N-E-K.

10:25 So it's at sneklang.org.

10:29 And it's a Python-inspired language for embedded devices.

10:33 But my first reaction is probably going to be yours is also, don't we already have that?

10:37 Don't we already have MicroPython?

10:39 We already have two.

10:39 I'm confused why we have two.

10:41 Yes, and CircuitPython.

10:42 Well, actually, yeah, we've got lots.

10:44 MicroPython, CircuitPython are the ones that we think about a lot.

10:49 CircuitPython, of course, is focused around Adafruit, but also runs on lots of different other boards as well.

10:55 But what about really small things?

10:57 Even those, they run on these small chips, but there's smaller chips that you might want also.

11:04 So if you only have a few kilobytes of flash and RAM and you still want to run something, can you run Python?

11:11 And that's where SNAC comes in.

11:13 So it's I mean it really runs on small processors even one of the things it supports is the Lego EV3. So if you don't want to wait for the new robot inventor you can run SNEC on your current EV3. So that's neat. But the smallness, its goal is it's not Python. So most SNEC programs will run in Python but not the other way around. You can't run most Python in it. So it's got a limited language, but part of that is an educational purpose.

11:44 So a smaller language footprint as Python's adding more and more new features, it may be overwhelming for some people when they're just starting out.

11:53 So having a smaller language is kind of a neat thing.

11:55 But all of that learning can go towards your, if you're learning SNAC, you can transfer that to Python projects later.

12:03 - Right, it's easy to level up to Python because it's like going from C to C++.

12:08 There's stuff to learn, but it'll kind of work.

12:10 - Yeah.

12:11 Yep, there's even like a dedicated, a new board called the SNEC board that you can, that is available.

12:17 It was through a crowdfunding process, but it runs both CircuitPython and SNEC.

12:23 So yeah, one more thing to be able to run little small chips with Python-like language.

12:29 So this is neat.

12:30 - Yeah, it's really cool.

12:31 And the very, very small devices, I think it's gonna mean, you know, Python can appear in more places, right?

12:37 on incredibly small IoT things and whatnot.

12:39 - Like even if you have larger though, I like the idea of people saying, Python's just kind of a great syntax if we strip some of the things out that full Python has.

12:51 It's still a usable language with a lot of it stripped out.

12:54 So I think it's a good thing.

12:55 - Well, that whole idea, I mean, we could go on and on about that, but the whole idea is pretty interesting because as we see things like Python moving to WebAssembly and running on the front end and talking about maybe having a Python on mobile, as well as the traditional CPython that we know and Python on chips, like having this concept of a smaller focused subset of Python that is universal.

13:19 That's pretty interesting anyway.

13:21 And it sounds like that's a little bit of the philosophy here.

13:23 - Yeah, it is interesting.

13:25 What other things we see like this coming up in the future?

13:27 - That's right.

13:28 So we spoke about Git before and Forks and using Forks as installation, but have you ever made a mistake with Git?

13:35 - Like every day, yeah.

13:36 - Yeah.

13:37 (laughs)

13:38 You're like, "Why did that thing get checked in?

13:40 "I told it to ignore it and now it's in there, right?" Yeah, stuff like that.

13:45 So Andrew Simon sent over a link and recommended a Zine, a little small book.

13:52 - Zine.

13:53 - A Zine, yeah, a Zine by Julia Evans.

13:56 She has a bunch in the programming and DevOps space.

14:00 And she created one called Oh Shit Git.

14:04 And it's like, I'm learning Git and oh my gosh, something's gone wrong, what have I done?

14:11 It's cool, right?

14:12 - This is great.

14:13 - Yeah, so I wanna be clear, this is a paid thing, it costs $10, we have no affiliation with it, but I just like the idea of it, so I thought I would feature it.

14:20 So basically it's this really short little zine book thing that explains Git fundamentals, like what's a SHA and why don't you call it an SHA, I don't know.

14:31 Stuff like that, right?

14:32 And then it goes into a bunch of, how do I fix common mistakes?

14:36 Like I committed to the wrong branch and other fundamental problems, or I have a merge conflict, or I committed the wrong file, or I ignored a file, you know, and going back in time, right?

14:49 Like we wrote the wrong code, the server is down, everyone is yelling at me.

14:55 I know it worked yesterday.

14:56 How do I get the server or something to go back and say, just go back to the way it was and we'll deal with it in a minute.

15:02 when things calm down.

15:03 So like all those kinds of stuff.

15:04 So I thought this was kind of a cool one and people who are like getting started with Git, but they're, you know, they run into these things and it's a big deal.

15:12 It's like, oh no, it's a merge conflict.

15:14 Now what?

15:14 I'm stuck, right?

15:16 Or like I said, committed to the wrong file or to the wrong branch or whatnot.

15:20 I think this would be pretty helpful for folks.

15:22 - I love that the titles of the different sections are the thing that went wrong.

15:27 Like I committed to the wrong branch.

15:30 - Exactly.

15:31 - Yeah, I tried to run a diff and nothing happened.

15:33 I have a merge conflict.

15:34 I want to split my commit into two commits.

15:36 I want to undo something five commits ago and so on.

15:39 - I got to make sure that this isn't a violation of my human resources things to buy this for all of my employees because I think everybody needs this.

15:50 These things are great.

15:51 - Yeah, just put a little bit of black electrical tape on top of that middle word and then you can hand it out.

15:56 - It's a PDF.

15:58 Maybe I get, buy five licenses and printed it five times.

16:01 - Yeah, no, it's pretty good.

16:04 It's like, I did something terribly wrong.

16:06 Does Git have a time machine?

16:08 Yeah, so it sounds interesting.

16:10 Thanks, Andrew, for recommending it, and Julia, cool work on the creative way to address Git issues.

16:16 - Yeah, definitely.

16:17 - So what's the story with versioning?

16:19 You guys got a beef with it?

16:21 - Well, I've kind of always had a beef with it, but I didn't really think about it.

16:26 So Brett Cannon actually asked a question on, it was interesting.

16:31 He wrote an article that I read recently called "Why I Don't Like SemVer Anymore." SemVer being semantic versioning.

16:38 - That's the 2.1.0 style.

16:42 - Yeah, and like as opposed to calendar versioning or what we were, we talked about this earlier of zero-ver.

16:50 - Zero-ver is like an even more negative version of sem-ver.

16:54 - Yeah, so the interesting question is, it's not straightforward as to what, so often it's like the first digit, like if we say x.y.z, x is some major thing, so like some crazy new feature.

17:08 It's either a crazy new feature or it's a incompatibility with the old one, like we're gonna change the interface.

17:13 - Right, when Django went from one dot something to two dot o, they dropped support for Python 2, for example, and that was indicated partly there.

17:20 - Yeah, exactly.

17:21 So what constitutes an interface break?

17:25 And that's what a lot of people think about.

17:27 Well, what about if you add a deprecation warning to something that you're planning on taking out in the next version?

17:36 Is that adding an extra warning, is that a major thing or a bug fix or a minor thing?

17:42 And that's part of the discussion of, most of us I think would think that maybe that's a, either that's just a bug fix or a minor thing, that's not a major thing.

17:51 - Right, to me it makes like no different, there's no new functionality, nothing stopped working.

17:56 That seems like a super minor, like it should change the very last number, because it doesn't even add or change a functionality.

18:04 - But it is adding a warning.

18:06 So if I'm running Python with the flag that turns all warnings into errors, or if I'm running my tests such that, and that's like normal with running tests is you turn all your warnings into failures so that you find them.

18:22 Now you really did change the interface because to get rid of that warning I have to go and either I need to not look at that warning or I need to change my use of that thing.

18:36 So it is kind of an interface break.

18:38 - Yeah, for sure.

18:39 - So that's part of this discussion is that it's not really straightforward to say that what is a major, minor, or micro change, what that really is.

18:47 It's a gray area.

18:49 There's discussion.

18:50 And then also really what the observation that the three digits kind of makes sense if you are maintaining three or more branches.

19:00 So if you're maintaining a current branch plus the features you're working on the next one, that's another branch, plus you're doing bug fixes to the current production one.

19:10 So you've got like development going on in one branch and fixes in the other one.

19:16 And then, you know, minor things going on.

19:18 You might have like even more branches that you're maintaining at once for a large project with lots of people on it That totally makes sense for small projects and side projects and things where you're really you're not maintaining a bunch of stuff You it's one branch and you fix bugs You're not planning on adding new features or if you are, you know, I don't know It's so infrequent that does it matter?

19:39 Maybe two digits is enough just X dot Y or maybe just one digit Because there's a whole one of the reasons why a whole bunch of people are at zero for is they're trying to not be backwards incompatible and they're and They're not gonna add any major new features. It's a simple tool or something. The other thing Brett brings up is Basically, you shouldn't depend on this stuff because it's nebulous and wishy-washy You shouldn't depend on the numbering semantic versioning to see whether or not what versions of a new of a dependent project you're using, you should rely on continuous integration and testing. So do a minimum version for the project you're using, but don't do a max, and use your testing to find out if there's any problems. Always do the latest one, and the version doesn't really matter. You're going to keep ahead, and if your CI breaks, then you might have to pin your dependency to earlier one. But also, you should always pin your dependencies to specific versions and just use your CI and testing system to see if you can move forward. Yeah, absolutely. And if you use something like Dependabot or PyUp or something like that, it'll automatically look at your repository, increment those versions, run some CI if you have it set up, and you'll know if it's acceptable or not. So you can get the system to tell you, "Hey, you should update this pinned version and click here to allow it." Yeah, I love systems like that. And it totally makes it so you can review it and go, "Yeah, that's good." And let the... often those just show up as a merge request that you just accept, right? - That's right. Yeah, very nice.

21:14 - Yeah. So, good discussion about thinking about whether semantic versioning really is appropriate for your project. - Yeah, so, do you remember what the recommendation was? I scanned it and I didn't see like a super clear, like, "Do this instead." - No, the end, there's a kind of a summary that I kind of like, cribbed and put in our show notes. Essentially, it's Try to pin the lowest version, or pin your versions, of course, but have a low end, but don't have an upper end, and just test.

21:43 As for using dependencies, for your own version, it really was, it should match your branching strategy, really.

21:50 So if you're really not supporting three branches, three-digit semantic versioning doesn't make sense.

21:57 You can do two-digit or one-digit versioning.

21:59 Yeah, pretty cool.

22:01 All right, carrying on with my theme, You want to talk about Git?

22:05 - Oh, we haven't covered Git for a while, so that'd be good.

22:07 - Yeah, for sure.

22:08 So there's famous, like, you know, rock star famous, Julia Roberts, movie star famous.

22:17 There's like maybe a step down, but still pretty cool.

22:20 There's geek famous, right?

22:21 Like on the regular street, nobody would recognize you, but at a conference, you're kind of cool.

22:25 I think probably Guido van Rossum definitely fits geek famous, right?

22:28 - Yeah.

22:29 - And then apparently there's Git famous.

22:31 - Oh, is that when you have like your pixelated face as your git history?

22:36 - It's really complicated, but if you time it just right, you can, yeah.

22:39 No, so there's this project, Bjorn Olsen sent this over, said, "Hey, you should check this out.

22:43 "It's quick and fun and kind of useful." If you want to go to a project and answer the question, who kind of created this or who mostly worked on this?

22:52 And I have this all the time when I go look at these projects that we're researching and covering.

22:58 Maybe I want to talk to the person about a question or something.

23:00 I'm like, all right, well, if I can go to the contribution thing in GitHub, maybe it'll show me but that's more of a over time and who's recently worked on it and stuff.

23:08 So it's not super good.

23:09 And if you're not on GitHub, then obviously it doesn't help.

23:12 So there's this thing called Git fame, which is a Python library.

23:16 And the idea is you pip install Git fame, and then associate it with Git, you have a new command, you say Git space fame, and it will go through and it'll like look at all to commit on all the people and how many lines of code were changed and files and whatnot by everyone.

23:31 And then it'll give you a ranking of these are all the people who contributed and here's how many files they've changed, how many lines of code they've changed and so on.

23:41 It's pretty cool and it sorts them by most popular, most largest contribution downward.

23:45 - That's cool.

23:46 - Yeah, and it's super easy.

23:48 It's super easy.

23:49 Like, pip install, git fame, git config and set an alias to fame to run the Python command.

23:55 and then you just type git fame and it just goes grr.

23:57 And it uses the TQDM, I think that might be the right order, progress bar, you know, to show you its progress.

24:04 I ran it on a somewhat large, somewhat large project, small to medium project, I guess, in terms of regular software.

24:12 And it found 596 commits and it took seven seconds to do that and processed 76 files a second.

24:19 That was pretty good.

24:20 - Yeah, I totally like the idea, especially, Brenda, very useful for us and we want to talk to one of the people that's really involved with it.

24:27 - Yeah, exactly.

24:28 - Yeah, and like you said, often some of the most recent ones are valued, of course, but not major changes to the library or something.

24:36 - Right, exactly.

24:37 So it's a little bit hard to know.

24:38 So this kind of gives you the historical view of who's really contributed to this project and how many lines of code have they changed and so on, which is not always a great measure, but it's still interesting.

24:48 - Yeah, I totally missed my guess.

24:50 My guess was it was an alias to rewrite getBlame because Blame is so, I don't know why they named it that.

24:57 - I know, Credit, maybe GetCredit.

25:00 It should be called Credit.

25:02 - Yeah. - There's positive and negative credit, right?

25:04 - Yeah.

25:05 - Yeah, so it basically runs GetBlame over and over and over on each file and then analyzes the file, the result of GetBlame and then builds out this history based on that.

25:15 - That's pretty cool. - Yeah.

25:16 - Neat. - Yeah, pretty cool.

25:17 Super easy to use if you're into it.

25:19 And that wraps up all of our items, Brian.

25:22 Got any extras you wanna share with folks?

25:23 I wanted to thank everybody that's supporting the show through Patreon because I went in and took a peek today and we have 26 supporters.

25:31 And if you wanna, we have links in the show notes and also links on our site, if you wanna to help out the show through Patreon, but you can also go to patreon.com/pythonbytes and many people donate a dollar a month and that is awesome, thank you.

25:46 And if you go above and beyond and contribute a little bit more, so I wanted to do a special shout out to those that are contributing more than a buck.

25:55 So thank you Brent Kintzer, Brian Cochran, Bert Raymakers, Richard Stonehouse, and Jeff Kiefer all donating more than a dollar.

26:04 So thank you very much.

26:06 - Awesome, yeah, thank you guys.

26:07 That really does help support cover things like editing and transcripts and all that kind of stuff.

26:13 Now I have a quick follow up for last time we spoke about DunderPi packages and things like that where you could set up, I think it was PyFlow we were speaking of, where if you interact with Python through PyFlow, basically it will use this Node.js-like behavior that is really still coming, hopefully, in PEP 582.

26:36 So after that, someone, it was Paul Everett, who sent over a message and said, "Hey, did you know Kushal Das, who is one of the folks, core developers, working on this whole idea, as a little Python example, just a single Python file that you can use to basically implement this.

26:52 And it says this would probably be really great for like trainers and students and teachers and stuff like that to kind of sidestep the whole virtual environment story.

27:01 - Okay, that's cool.

27:02 I gotta try this out.

27:03 - Yeah, so a quick little link to a working version that's not just a whole overhaul like PyFlow but a simpler thing.

27:10 All right, now this last one, Brian, this joke here, and I'll wrap it up with a joke as always.

27:15 You've got to open it up because it's an animated GIF.

27:17 First, let me ask you what shell do you use on your Mac?

27:20 - Bash. - Bash, okay.

27:22 So I'm a oh my Z shell kind of guy because I love the history and it keeps a really good track of all the stuff I've done.

27:29 And sometimes I'll type one or two letters and I'll try to go back and I'm like, no, no, that's not, instead of just typing out the stupid thing, I'll just go back and back.

27:35 And so here's this clear super bearded guy who's some kind of sysadmin Linux exaggerated person, I guess you would say.

27:45 And it's an animated GIF, right?

27:46 The guy's just clicking his finger, clicking his finger up, up, up, up, up, up, up.

27:50 Shows him doing that, doing it some more.

27:52 Now he's got a drink, he's clicking on, he's drinking his drink, clicking up.

27:56 And then finally, he's so excited, he's, "Oh, finally!" What does he say?

28:00 - I knew I had that LS somewhere in my history.

28:03 - And eventually he just says, yeah, LS, right?

28:05 He's up arrowed until like forever to just, so he didn't have to type LS.

28:10 - Oh, man.

28:10 - Have you ever been there?

28:11 - No, 'cause I, what kind of key binding?

28:13 Do you use VI key bindings?

28:15 - Okay. - Do you like a backward search or something like that?

28:17 - Yeah, you can just search through your history to find them.

28:21 - But then you have to press more than just the up arrow.

28:23 - (laughs)

28:25 - Anyway, people, this has got a cool little animation cartoon thing. So I just linked over to comicstrip.com where the title is "Definitely Not Lazy." - (laughs) Yeah, definitely. You know, I was thinking about it. I don't even remember the the key sequence to do the searching, I would have to do it.

28:44 I just, it's one of those built-in muscle memory things now.

28:46 >> That's right. Yeah. I was trying to remember it today and I couldn't remember it.

28:49 I'm like, "Oh, whatever. Up arrow, up arrow, up arrow." So yeah. Pretty funny.

28:55 All right. Well, thanks for bringing all these items and sharing with everyone.

28:58 Great to chat with you as always.

28:59 >> Thank you.

28:59 >> Yeah. Bye.

29:00 >> Thank you for listening to Python Bytes.

29:02 Follow the show on Twitter via @PythonBytes.

29:05 That's Python Bytes as in B-Y-T-E-S.

29:08 and get the full show notes at pythonbytes.fm.

29:11 If you have a news item you want featured, just visit pythonbytes.fm and send it our way.

29:15 We're always on the lookout for sharing something cool.

29:18 On behalf of myself and Brian Okken, this is Michael Kennedy.

29:21 Thank you for listening and sharing this podcast with your friends and colleagues.