Python Bytes - #38 Hacking Classic Nintendo Games with Python

Episode Date: August 9, 2017

Topics covered in this episode: [more]* Hacking Classic Nintendo Games with Python * Bokeh Mosh (mobile shell) (bonus) Twilio Voices Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/38

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 38, recorded August 7th, 2017. I'm Brian Ocken, and we have guest hosts filling in for Michael while he's on vacation. This week we have Matt McKay from Fullstack Python. Hey, Brian. Hey. Now, you also worked with Michael on the Python Entrepreneur course, right? Yeah, exactly. And I've been on Michael's podcast a couple of times. So he's always a great interviewer. Yeah, I was having trouble not grinning and laughing during that because I'm usually waiting for Michael to get done with the intro. So, hey, thanks a lot for stepping up and helping us with this show this week.

Yeah, I'm happy to help while Michael's taking a nice little vacation so he can come back all rested and ready to go. And first off, I've got you starting because why not? This is from a talk at PyCon. Is that right? Yeah. So I was at PyCon this year. I try never to miss it. I would unfortunately miss PyCon last year and I vowed never again because it's just my favorite event every single year. So I caught this talk. This is actually my colleague, Sam Agnew's talk, which was called Hacking Classic Nintendo Games with Python. And the gist here was he was using a Nintendo emulator named FCEUX. I actually don't know if that has a better pronunciation or whether people say it by the letters all the time, but he used that in order to change old school Nintendo games he was playing and interact with the audience during that PyCon talk.

It was pretty awesome. I missed it. So tell us a little bit more about this hacking Nintendo games. Yeah, sure. So Sam was inspired by the PyNES project and he basically saw that you could use Python to interact with Nintendo games. And since he grew up on playing the old school NES Nintendo system, he wanted to use some of the old games that he had and basically emulate the games

themselves, but also the way that the old Game Genie system worked, which was by hex editing the memory of the game itself. And so what Sam did in this talk was he created a little Lua script, which would change the hex values in memory of a game. And then he created a Python application that attendees at the talk could text in different hex codes. And he was playing the game while attendees were changing the game on him. So it was kind of like adding cheat codes to the game while he was playing. So it was really cool to see sort of how he was able to interact with the audience, but also play some games that kind of brought out a little bit of the nostalgia factor. Oh, that's cool.

Yeah, I'll have to check that out. And the one other thing I really liked about it was he made certain topics that sound pretty intimidating, like hex editing memory values into what I think is like a relatively beginner friendly way to introduce it. It basically takes the hex memory values, shows you, explains what they do, and then you can see the results when you edit the values. So definitely a topic or a talk worth checking out. And he also wrote a companion blog post that explains everything about what he did throughout the talk. Okay. I've admit morning I watched just a small portion of it, and I just got to the point where he changed the time.

There was a game running, and we were watching the time left. He paused the game. Yeah, in Super Mario Brothers, the first one. Yeah, Super Mario Brothers. And then he changed the time back down to zero, and suddenly his character died. And he said, okay, so that's how you hack it. The talk's over.

Exactly. And he did that just through editing hex memory values directly to change the time, which was pretty nuts. So there was Lua involved also. So I was confused. I haven't watched the whole thing. But is the editing of the game in Lua and the Python was for the Flask app? Yeah, so the emulator itself, there's multiple emulators you can use in order to run NES games. But the one that he was most comfortable with actually had embedded Lua in order to script editing the hex memory values.

So really, Lua was only being used to input the hex values into the memory and then read from a file that Python was writing to. So you can think of like there was a file on the system where his Python application was inputting into that file and then Lua was reading from it and just shoving it into memory to change the game. So it was basically a file was being used as a bridge between Python and Lua. Okay, great. Cool. I love what, I love that the, uh, the PyCon talks are, um, they're recorded. And I, to be honest, when I was there, I didn't go to very many talks, but I just spend the year between PyCons just watching all the old ones. Yeah. So, yeah. So, uh, Nick, that's awesome. Speaking of conferences, I wanted to bring up an article that I, that Eric Holscher put out just recently. And apparently he brings it up at the beginning of his talks a lot. And it's, he calls it the Pac-Man rule at conferences. And it's just a short little article, but I really, it's, I like the visual of the Pac-Man, little Pac-Man with a little gap. So the idea, and I'm just going to quote exactly what he says,

is when you've got a bunch of people in a group, like when you're meeting new people at conferences or something, to make sure that there's a gap. So when standing in a group of people, always leave room for one person to join your group. Leaving room for new people when standing in a group is a physical way to show an inclusive and welcoming environment. And just the whole idea, I know that I started out totally as an

introvert because I got into programming, not because I really enjoy hanging out with people. So it is a stretch for a lot of people, including myself, to try to go up to new groups of people and join conversations. And I thought this was a great tip to when you're having a conversation in a group, to make sure that you're physically showing and visually showing that you're welcoming new members. Yeah, I agree. It's almost like pattern matching for developers. When there's room for one more person, you feel much more comfortable with just sort of approaching the group and asking people what they're talking about. So I think it's really good advice both on the side where you're in a group already, but also when you're not in a group that, hey, there's some people that may want to talk to you and they've left you a spot at the table or where they're standing. So Eric did a great job on this. Yeah, I think it's great.

That was just a short one. And you're going to talk about something that I really haven't had a chance to play with yet. And that's except for I've had a chance to mispronounce it on this podcast. And it's Bokeh. Yes. So if you take a look at the website, it actually can be pronounced two different ways, Bokeh and Boka. So chances are you pronounced it correctly. You just thought we were incorrect in your pronunciation. But Bokeh, I usually just

say Bokeh, is a Python data visualization library. And the output is designed for presentations in web browsers. So you don't have to write any JavaScript. So if you've ever used D3JS, which is a fantastic data visualization tool, it's got a really steep learning curve. So if you really have just spent a lot of time in Python land, you can use Bokeh to generate these amazing data visualizations that are rendered in the browser and you don't have to write any JavaScript yourself. So that's one thing that I love about this library. And so I highly recommend you check it out because it just had a new release, which was V0.12.6, just back in June.

And it had a whole bunch of improvements. And this development team is doing an amazing job. And they're gearing up for a 1.0 release, which I think is just going to make it. I think it's going to make this library very, very popular very soon. For visuals and creating visuals in Python, the one thing I have used is matplotlib. So is there kind of a rule of thumb or of when to use generating plots on the client side versus the server side or? Yeah, no, I think that's a good question. And I haven't used matplotlib as much as Bokeh. I've only used it a bit in Jupyter notebooks, my rough rule of thumb, but I could be totally wrong. So I would love to get emails if it's different. My general rule of thumb is

Bokeh is really fantastic for creating interactive visualizations in web applications. You can certainly use it in Jupyter notebooks as well, but I see matplotlib as being sort of the quick and dirty solution to visualizing data in Jupyter notebook scripts. So I would typically use matplotlib if I'm doing something that's like super early, I'm doing exploratory data analysis. Morse bouquet is sort of the building a beautiful dashboard and you want bar charts or you want some interactive visualization that you can then have end users be working with. Okay. I think that's a great explanation. So I'll have to check this out. Yeah. So, and that's, and that's bouquet. And I actually, what's, what's funny is we,

it always goes back to PyCon. I found out about this library at PyCon in 2015, Sarah Bird, who works on the core library, gave a fantastic talk where she essentially built an entire data visualization, a map, a geo mapping, a data visualization, like during her talk. And I was like, this is, this is incredible. So then I got a chance to use it a little bit. I wrote a flask tutorial on full stack Python that uses bouquet. And that's why I've been sort of, I don't want to say evangelizing, but I've been telling people how, how enjoyable it is to use this library. That's great. Cool. I'll have to check it out more. Definitely. Well, next I've got another,

another tool that I actually haven't used yet, but I just heard about it recently. And it's a tool called Mosh, which is a, it's a mobile shell and the, the idea around it, it's a tool called mosh which is a it's a mobile shell and the the idea around it it's kind of replacing ssh so if you have to have a connection to another instrument to run command line commands and you now we live in a time where we've often work on laptops and then you close your laptop and go home or go somewhere else and open it up again, that connection's gone and you've got to reestablish your SSH. And there's also, you know, there's other problems with SSH, with keystroke, when you're displaying the interactiveness.

And MOSH is an attempt to basically go down all the way to the protocol layer and redefine what gets transferred back and forth. There's a YouTube video that we're going to link to that it's actually, it's back from 2012. And it's very convincing as to why we would want to do mobile applications differently than we've done them in the past at just the byte level. I'm just kind of wondering if people use, are using it. And that's just why I brought it up is it looks cool. I want to try it. I wonder if anybody else has used it. I haven't used MOSH myself, but it seems like SSH is a protocol that was designed to

disconnect every single time I'm trying to write some code in front of an audience. So I will definitely have to check this one out, especially when I'm doing live code demos, because when your SSH connection drops in front of an audience and you've got to reconnect, it can be, it can be a real pain. So this is pretty awesome. And the video actually is of a, he's doing a, there's, I don't know who's in the presentation, but there's a person presenting and they they're connected to another system. And right in the middle of typing a command, he changes his Wi-Fi connection to a different connection and it just works. It like fixes itself. So it's great. This is great having

you on because you're talking about just about a bunch of things I've never used, but definitely heard about. And well, hopefully I get you excited enough to use them because there's some of my favorite tools. And the next up is a Pelican is full stack on use doing. Do you use Pelican for full stack? I do. Yeah. So a full stack Python, people luckily noticed that it's pretty snappy and that's because it's not, it has no database backend. It's all just a bunch of flat files that are served up by a content delivery network. And that's all generated. I don't handwrite HTML, at least not for fun.

I generate that with Pelican, which is a static website generator. So the way that I think about it is like static website generators basically have, I would say like three parts. You have your content, which might be written in restructured text or markdown, some sort of markup format. The second part would be a template engine. So most likely Jinja, a lot of people who use Django are used to the Django template engine, but Pelican's kind of built out of the box with Jinja. And then you have some Python code that puts the two together and then outputs typically HTML.

It can also be other formats like XML or JSON, really any sort of output that you want that is a file format, but I output HTML. And then you can take those HTML files and you can host them anywhere. So the power is you have these markup, you have all your content in the markup format. So it's not like you're again, modifying HTML directly. The static site generator does all the work for you with its, well, what are called generators. The Python code creates, takes in the input and then outputs those, those file formats. And then you can just, you can host them anywhere. So the way that I think about it is that it's a, it's kind of like a throwback to the early days of the web when everything was like really snappy.

It was because you weren't connecting to databases via web application. It was just because you were being served up a single file or multiple files that are basically just flat files. Yeah. And maybe some Perl on the backend, but one of the things that's great about Pelican is it's in under active development. And so the latest release is version 3.7.1. 3.7.0 was released at the end of 2016. And that was like a major bump with a lot of good Python 3 compatibility. In fact, I only use Python 3.6 with Pelican now.

It works fantastic. So it's ready to go Python 3 out of the box and it's had a bunch of major work done to it, a lot of bug fixes recently. So under active development, that's one of the things, there's so many static site generators that are out there. It's relatively easy to create one as sort of a side project, but this one has been around for a long time.

So I started using Pelican probably six, seven years ago now, and I still highly recommend it, which is if you're a developer and you've been using a tool for that long, I feel like that's a pretty good sign that it's a stable foundation. Yeah, definitely. I don't know if you remember what it I wanted to create a little site to, I don't know, document some process or something and wanted to spin up a Pelican site with a bunch of documents, I guess, in it. Is that something that's going to take a long time to learn how to use or is it pretty quick to pick up? No, it should be pretty quick. I mean, a lot of people think that static site generator is just kind of for blogs, which is sort of the original purpose of a static site generator. When they

first, when some of the first ones came out, they were mostly used with like a blog format, but you can create any type of website with a static site generator. And you can even, even create like single page applications if you combine it with some sort of JavaScript framework on the front end. So yeah, so there's, I would say it's actually relatively easy to get started. I wrote a tutorial on this, how to create your first static site with Pelican and Jinja. And, um, that would actually get you up and running probably within, I don't know, 20, 30 minutes, uh, do pip install Pelican. Wow. Okay. And then Pelican will actually generate the boilerplate that you need with the Pelican quick start program. And then

you, you have your first static site. Actually, you could probably have your first static site within five minutes, and then you can start customizing it and have something that you could deploy very quickly after that. Well, that's definitely fast enough. And is the tutorial have talk about, I guess it probably doesn't matter which Markdown you use. Have you used Markdown or Restructured? Yeah, I actually, I use Markdown on full stack Python, but on my personal site, mattmckay.com, I use Restructured Text. So I kind of use each one interchangeably.

In fact, you can use them interchangeably on the same, in the same site. So Pelican doesn't, yeah, Pelican doesn't really care. It'll just say, oh, you've got five Markdown files, five Restructured Text. I think the ASCII doc is another format. You can kind of just take anything as input and it'll use that. It doesn't have to be segmented by projects. Does it tell by the extent file extension or something or do you know? Yeah, you can. Well, in the configuration settings, you can tell, you can tell Pelican which file formats you want and also which extensions. So if you don't want to pick up your restructure text files, you can just have it pick up the markdown ones, but you can, you can configure

all that stuff in the, in the configuration files. It's pretty, pretty extensible. Nice. Okay. The last topic I want to talk about was something that just helped me just now. So in the last episode, I announced that I'm no longer writing the book, the book being Python testing with PyTest. It's what I've been working on for like a year, but I was wrong because right after we recorded that and I handed in all my documents to my editor, the PyTest team came out with another version, the PyTest 3.2.0., I had just recent, just like the week before retested all of my examples in 3.1.3. So what do I do? And what I'm doing is just making sure they all work.

So right now I'm, I'm going through all of the book again. And instead of having to do this every time I've decided I'm going to build a test framework to not a framework, but I'm going to build a test framework to, not a framework, but I'm going to build a set of tests that check all of the examples and make sure that the output is similar enough to the output I describe in the book so that it doesn't confuse somebody when they have a new version. And one of the things I'm using is a tool called PyTest Watch. It's a PyTest plugin. It's great because I've just got two windows open in two terminal windows while I'm editing these tests. One of the terminals is

running PyTest 3.1.3, and one of them is running PyTest 3.2 in two different virtual environments. And I've got PyTest Watch just looking at the directory. And every time I hit save on the tests, both of them go off and run. And eventually when I get all done with this, I'll probably convert it to talks or something so that I can run them all the time. But for now, interactively, PyTest watch is pretty cool. Wow. That's amazing. How much like code did you have to write in order to get that to be working with both versions? I'm actually using the, there's a part of PyTest that I do cover briefly in the book that's called the PyTester. And it's a, it's a plugin that is

used for the intended uses, uses for testing plugins, but it's also used by the test code for PyTest itself. And it allows you to run a PyTest session and capture the output and ask things about it, like was the string in there and how many passes, fails, skips, things like that are in there. And so I'm writing the test just as if I was writing like a plugin or something. And it's taking me, it's about, it's not quick, but the format of each is pretty similar. And it takes me about a minute or so per example to get a test in place. But there's like 170 examples. So, you know, 170 minutes.

Any way to speed that up where you're happy with it right now? There probably is. The slow part really is just the the me looking at it i could probably automate the whole thing and get it done faster but i also want to be reading the book and while i'm putting these together to make sure that because there's sometimes there they'll be you know something minor uh, I guess not really minor differences, but I don't really want to just say I want the exact same output because if they added, you know, a period here or there, that's not that big of a deal. Right. But I want the, the gist of it to be correct.

So, wow. Nicely done anyway. So that's that. And, uh, we're done. Thanks a lot. Yeah. I want to, usually at the end, we, uh, touch bases with each other to say what's going on. So I just learned today that, Matt, that you work at Twilio. Yeah, I do. So Twilio, for folks who don't know, it makes it easy for developers to add communications, like phone calling, messaging, and video to their applications. So if you've ever wondered, you've gotten, you know, you're working on a feature and you're in the middle of a sprint and your user story says, okay, send a text message to somebody like, well, how do I do that? How do I like interact with this

global telecom network? Well, you could do that really easy with Twilio's API. So yeah, so that's my day job. So in addition to working on full stack Python, I work at Twilio, which has been really great. I've been there for almost four years now. That's great. And you're also working they have on the Twilio blog. So if anyone's listening and you want to try PyTest Watch and you want to learn a new open source project or something like that, if you just write some code and then you want to write a blog post about it, you can do that through Twilio Voices and get paid $500. The way that I see it is like the $500 is a good way to get past the procrastination stage of writing a blog post. And then we promote that blog post to everyone in our different channels. So a lot of times these blog posts can be read by tens of thousands of people. For example, there was one called Wedding at Scale,

how I automated my, with Python and Twilio and Google. I mean, basically it was a developer who was talking about how he automated all the text messaging and communication for his wedding through a Python script that he wrote, which was a really cool story. So the whole idea behind Twilio Voices is people have all these awesome hacks and applications that they've built. Tell us a story about it and show us how, show readers how to build what you built. It doesn't have to use Twilio. It can be basically just any, any code that you've built, tell us a story about it and show us how show readers, how to build what you built. It doesn't have to use Twilio can be basically just any, any code that you've created, as long as it's a, if it's a cool story or a good tutorial. So it doesn't have to be pushing Twilio. It can be just about anything. Uh, no, cause we're a company for developers by developers

for developers. Um, and we've always been that way. So whether you're using Twilio or not, we want to see the code that people have written. And one thing that's really great about this is every post goes through a rigorous review process, like an outline review, voice review, tech review to make sure all the code works so that like people who write these blog posts make sure that their output is like the best that they've ever created, which has been really cool to see people say like, I never could have written a blog post that was like this polished. So we, we kind of put it through the, through the ringer to make sure that it's a, the highest quality post. That's pretty cool. I mean, you usually have to like pay money to interact with the editor.

So that's nice. Cool. Yeah. You should, you should write something on testing. Maybe I should write a blog post. yeah. We would love to have it. So what have you been up to, Brian? Well, I'm not actually writing the book anymore, which is good. Congratulations. Thanks. But I am working on book-related activities for this month because it still is going through, it has to go through copy editing and figuring out marketing plans and all that good stuff. So I've got a couple of podcasts for testing code.

One came out last week and I'll probably get, I'll do weekly ones, get them out. But it's still, that's still slow while I'm spending most of my free time on the book still. So other than that and my full-time job, yeah, that's what I'm up to. So hopefully you get some time to sleep then. Yeah. So I've been fascinated hearing about Matt and I've convinced him that I'm going to put him on the spot on the air

and tell him that he's got to get on the testing code and talk about full stack sometime. Sure. Happy to do it. 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 and links to things we talked about on the show at PythonBytes.fm. If you have a news story you'd like featured, just visit PythonBytes.fm and send it our way.

We're always on the lookout for sharing something cool. This is Brian Auchin. On behalf of myself, Michael Kennedy, and Matt McKay, thank you for listening and sharing this podcast with your friends and colleagues.