 How was lunch? Good. I want to start asking everyone a question. When was the last time you worked on a non-productive project just for the fun of it? I'll just think about it for a second. Today I'm going to tell you a story about the last time I did. Let's go back to February 14th of this year. It was a cold Friday night, and also Valentine's Day. If you have a partner, you're probably having a romantic dinner. Whereas if you were single, like I was back then, you were most likely doing less exciting stuff, like spending the night on the Internet. So there I was, on Reddit. After browsing for a while, I stumbled upon this thing called Twitch Place Pokemon. I saw this screen and it was very, very weird. It took me a while to figure out what was going on. Apparently, some dude hooked up a Gameboy emulator to a streaming website and allowed everybody to control it through the chat system. Hundreds of thousands of people were playing Pokemon Game at the same time, the same session. My first thought when I saw this was, oh, my God, this is awesome. My second thought was, I need to make my own. My name's Jose Tomás Salvornoz, and today I'm going to tell you a story of how I've built my own Twitch Place Pokemon. So Saturday morning, I woke up early and went to my bookshelf. I went to my cookbook. Not an ops cookbook, but more of a developer cookbook. And I headed today how to make a Twitch Place Pokemon recipe. The ingredients list reads, we need one Gameboy emulator, one screen streaming application, and one Internet control for the emulator. For the Gameboy emulator, I already knew which I would advance. So that was simple. It's just a simple regular C Gameboy emulator. For the screen streaming, I had no idea how to do it, but I didn't really care because it was probably trivial. So I just skipped it. The real challenge was figuring out how to control the emulator with Ruby. The first thing that popped into my mind is, how the heck do I control an emulator with Ruby? Can I even control my Mac with Ruby? After Googling for a while, I ended up in this Stack Overflow question, called, how do I send keystrokes from a Ruby application? The solution, rather than the lines of, you could use the FFI gem to load user32.dll. Let me read that back again. You could use the FFI gem to load user32.dll. That was clear. Oh, no. That does the job. Just what I needed for a Lucas deep-rim. That does the job, actually, but not for me. There's a couple problems with the Windows solution. Well, first of all, it's Windows. I'm actually locked to the operative system, and I don't like that. The second one is to have no Windows machine. Yeah, and I want to stay like that for the next 30 years. And the third one is that I want to run this on a headless server, on a server with no desktop environment. And yeah, with Windows, that's not possible. So Windows, this solution was definitely a no-go to me. I scrolled a bit more, and I found what this guy wrote. He said you could use JRuby to use the Java robot class to control the keyboard. I had some experience porting some code from Java to JRuby. So by the end of the day, I had a working emulator. I had a working Sinatra application that could send keystrokes, like if I was pressing keys on my computer. So yeah, here you can see it working. It's just some Java bindings, and then whenever I send a request to a specific URL, it will just press the key. You can see it here working. Oops, there's some audio. No, it's fine. You can lower it down. So yeah, so here we see the system working. On the left side, you can see me sending HTTP requests from my iPhone to the Sinatra application, and on the right side, you can see Sinatra actually controlling the Gameboy emulator. Yay! This is a... This is already, like, enough. This is the first prototype. I just built my minimal viable product, but before going to VCs, there's a couple problems that I need to solve. The first one is that simulating keystrokes is a rather weak way of controlling the emulator. If by some reason another window pops up, the focus shifts to that window, so then all the keystrokes that I sent will go to the other window and not to the emulator, which is not what we want. It still requires depth of environment, so we... Well, first of all, we need to position the emulator in a specific part of the screen. Then we need to record that part of the screen, which just makes it a pain in the ass. It's not viable. It's just too much effort. Lots of things can go wrong. And the third one, which is the most important one, there's a huge latency. If we're recording the screen, like recording video from the screen, besides recording a specific area, people usually have to load buffer the video for like, I don't know, 10 to 20 seconds, and that adds enough delay. So what you're seeing in the screen, so when you're playing the Twitch Play Pokémon thing, you see the emulator and you send commands on the chat for what you're seeing, but what you're seeing now happened 20 seconds ago, so that's not possible. Imagine playing Counter-Strike with a 20-second delay. It just wouldn't work. So, yeah, let's think a bit for a while. What would be the perfect emulator for us? The perfect emulator would be one that requires no desktop environment. Yeah, just hold that problem. It streams the video online and has an API that allows us to send button presses so we can run on a headless server. I couldn't find one that does that. So I went back to my cookbook and I saw this very small notice at the bottom that it said, for a headless recipe, flip the page. Did so. And there it was. This is the ingredients list for building our own Twitch Play Pokémon that requires a headless emulator, which is just having the headless emulator. If you write the emulator yourself, then you can control everything. Let me go back a couple of steps and let's explain a bit what's an emulator. Yeah. So, an emulator is a software that allows us to run Game Boy games in our computer. If in a Game Boy, we have a cartridge in the Game Boy emulator, we have a ROM file which has the exact same binary contents that are in the original Game Boy cartridge. The only way that I know to run the same binary in the computer is achieved by emulating the Game Boy hardware. So if in the Game Boy, we have the CPU, GPU and RAM, we need to do the same thing for a Game Boy emulator. When you... What happens in the real Pokémon, in the real emulator, I mean in the real Game Boy, when you put the game on, is that the console dumps the whole cartridge into the RAM. If we want to write our own emulator, we need to do the exact same thing, which is quite nice. We just dump the whole binary file into a big array. Okay, so... Yeah, so when you load the emulator or the Game Boy, the CPU of the Game Boy loads the first byte of the RAM and compares it in an instruction table. The instruction table is like a hard-coded list of instructions that the CPU has which are all the things that the CPU can do. These are just very small actions, like for example, in the byte 0xC0, the instruction according to that byte will just jump the execution to another sector of the game. In our Ruby version, we have to do the exact same thing. So the whole... This is what I call the loop, which is how emulators work, and also CPUs. The first thing that you do is that... Well, the CPU has this internal variable, which is called the program counter. Each time it executes an instruction, then it will increase the number so it knows what byte to read. When we run the emulator, we just load the first byte and then see what part of the RAM is the value for that byte. Then we read the byte and see to what corresponds to in our instructions table. Then we execute the CPU command and then we increase the program counter by one. I call this the loop because I have no computer science background, but this is what it means to me. And what's cool about this is that this is the basics of how computers work from the Turing machine to your Mac, to your Game Boy, and I have no idea about this. And I've been developing professionally for at least three years. How do we care about how emulators work? Because we have to build our own. Because we'll have to write our own. So what are the advantages of having our own emulator? First of all, we don't need to emulate key presses because as we control the emulator, we control the way the keys are emulated. So we just... Yeah, we just emulate them like that. We can build our own API. Second of all, we can run on a headless server because we don't need to output the actual screen of the Game Boy to the real screen. We can just pipe it to a web socket and render it with Canvas, for example. Third of all, we can stream closer to real time because we don't really have to record the screen who can just output the bytes in a compressed way, which is probably much more faster than streaming video. And the most cool part about this is that we control the memory. For example, as we have the whole RAM of the Game Boy, we can have some version control system. So something very common that people do when they play Game Boy is that they save, they do something, and then if something fails, they just go back. As we have the RAM, we can just take snapshots and then rewind whenever we want. We can do this online, which is quite cool. We can also... What's the next one? We can also fork and branch. So it's pretty much the same. You could do it with Git, all of this you can do more or less with the current Game Boy simulators, but they're not really meant for that. But all of this gets much, much more interesting when we introduce machine learning to the equation. This guy, which is called Tom Murphy, he wrote a PhD paper based on a program that he wrote that plays Mario itself. The way he did it is that he got hooked up into a NES emulator, and then he analyzed the way the RAM works. When you play Mario, you just want the score to go higher and higher and higher. So he looked up the section of the RAM that just goes higher whenever he advances in the game. He introduced a machine learning algorithm that just tries different things and learns based on how you play the game, so as to play the game itself. This is actually quite interesting. You can make the software that can finish up to two levels of Mario without human intervention, which is really, really nice. The URL is over there if you want to check it out. So, yeah, what are the advantages of having our own emulator? No need for a key process, we can run on a headless server, we can stream online, and yeah, we control the memory. Am I forgetting something? Oh, okay. All of this is awesome. We have the ingredients, and we know what to do. There's only one problem, though. I'm lazy as hell. Like every developer, I guess. Luckily, Barucho came to the rescue. The conference was announced, and I didn't have enough money to get my own ticket. After running on Twitter for a while, Chuz told me, well, man, the CSP is open. If you send a proposal and you make it, we'll get you in for free. Here. It reminds me a bit of what Matt said this morning. When he got the funding for M-Ruby, that was the exact same case. Well, he didn't do it for the money, but he had the goal, he had the deadline, which is, yeah. So, yeah, my tag got selected, and this is when the fun really began. I committed to give a talk in a conference for a project that I always spent working a weekend on it, and I had no real clue how long it would take me to write it. I made this a small comic based on Y's book that pretty much expresses how I felt. So, taking over Mimey. Let me introduce you to Hanno Gonzalez. Hanno Gonzalez is Chilean. He's a Chilean developer. He loves Game Boy, he loves Pokémon, and he loves Ruby. Hanno had been working for a couple months on this project called Mimey, which is a Game Boy emulator written in Ruby, which is exactly what we want. I'm going to go ahead and run up the emulator. It was still better than starting from scratch, so I just forked Mimey and continued working on my own. Hanno was following a tutorial called Game Boy Emulation in JavaScript. The tutorial was quite nice, or it seems so. The way the tutorial works is that it takes you through every component of the Game Boy hardware, teaches you how it works, and then how to write the beginning, you can write the component yourself. It didn't take me long... Well, it was reasonable to think that by following a JavaScript tutorial, I could write the same thing in Ruby. It didn't take me long to figure out that the JavaScript Game Boy emulator tutorial was more like along the lines of how to draw an old tutorial. First, you draw some circles, and then you just add the rest of the oil. The tutorial was pointless. So, today I'm going to tell you a couple stories that happened during the development of this emulator. The first one is about bits and bytes. I have no computer science degree. Oh, um... As soon as I got into the development of the emulator, I figured out that the words bits and bytes were everywhere. I have no computer science background, so actually, I had no idea what's a bit in a byte, which was probably fine, right? Like, I'm a web developer, I'm a Rails developer, I don't really deal with such things in my daily life. But that's the first thing that they teach you when you go into computer science. I live in Berlin, and I'm a Rails skills coach, so I happen to go to Travis every Monday. All right, so I had no real reason to know what that means. But I was forced to learn it this time. So, yeah, I seek for help. Let me introduce you to Sven Fuchs. He knows about computers, right? He actually knows more than about computers. He knows a lot about computers. So I went to him in Travis, and I asked him, Sven, what's the difference between a bit and a byte? What's the word? And he told me... I learned that 20 years ago. I asked him for an example of when did he actually use what's a bit and a byte, and he couldn't think of any. And I don't think he's wrong. If you don't have to use it, you can use it. Sadly, if you're writing an emulator, you actually have to deal with such things. Sven explained me the difference, and then I moved on with the development of the emulator. Let me talk about what's irresponsible Ruby. Last year, in Yerukko... Oh, this is his tip-clapnik. He also knows a lot about computers, and he gave a talk in Yerukko last year. He introduced us to the concept of irresponsible Ruby. He's inspired by Y. Irresponsible Ruby code in Steve is Ruby code that you wouldn't deploy at your day job because it's just too interesting or creative. I like the idea a lot. Irresponsible Ruby is Ruby code that uses neat hacks, weird metaprogramming, unusual techniques, and no unit testing. I like the concept a lot. Oh, one more quote. He actually also quote Y. If you're worried too much about being clean and tidy, you can't push the boundaries, which was exactly what I wanted to do with my project. Hannah was testing the Miami emulator using RSpec for every CPU instruction, which are like 200 or something. It was just ridiculous to do it that way, and it was stopping me from actually developing the emulator. So I like the concept of irresponsible Ruby a lot, so I wanted to apply it from this project. So the next story I'm going to tell you is about how to test irresponsibly. Each time, so I explained the loop, and the CPU follows all the steps. The CPU has usually six registers, which are like variables, which are just very, very tiny numbers, one byte, and after every instruction, they change a bit. So for example, between the first and the second instruction, no number changed, but between the second and the third one, the instruction was decrement the byte B, so you can see the number goes from 22 to 21. These are instructions. I thought that I could run the JavaScript version that was working, the end result of the tutorial, and just store those numbers and then do the same for my Ruby version and compare them and see what could go wrong, when it was going wrong. Yeah, I did that. Luckily, the specification of how the original Game Boy works was feature frozen before I was born, so it wasn't going to fail. Let me take you through my development process. I actually did TDD with this tool. The way I worked is that I run the test, I saw it failed, fix the CPU instruction, and then just repeat. This is the debugger I wrote for myself. It runs the node version, then it runs the Ruby version, and then it compares the result of each CPU instruction. In this case, the number should have been six, but it was one. I just fixed that, and then it was working again. So, let me tell you the story about rendering the first image. Some people say that men who grow a beard are full of patients, because of all the time it takes them to grow that beard. If you think that's patients, try spending weeks writing a Game Boy emulator, which is supposed to be fun, just seeing hexadecimal addresses, and you really know what patience means before rendering any image. Just addresses. That's patience to me. It usually takes about 50,000 CPU instructions, so you can start seeing the first frame of the emulator. And it was the moment. I knew that the code was ready to render the first image, so I ran the test with and it was supposed to be working. So I crossed my fingers, and I set it up in such a way that it just had to press enter, and then I would see the first image. Let's see what happened. It failed. It's a bit frustrating to spend like months working on something, and then when it's supposed to be working, you just see something blank. I didn't really know what was going on, because the code was exactly the same. The memory was exactly the same as it was in the JavaScript version. It was working, but it was still not working. What I didn't take it to consideration is that the JavaScript version is supposed to render in Canvas, which in practice means that one every four pixels has actual information, and the rest was just Neil, who had a screen. Dividing some number by four would actually do the job. I don't know why, but I would just get the fourth pixel and that was enough. So here we go again. Fix the test. Well, I supposedly fixed the emulator. Same process. I just had to press enter this time a couple more steps, and I should see an image. Coding DHH. If you stretch it a bit more, you could see what was going on. You could see some shape, but it was still a bit weird. If I stretch it even more, you would see this. I had no real output screen, so I just made up this simple system so it renders to my terminal. This was the first frame that the Gameboy emulator was showing, which was great. After doing this, I felt like the king of the world, right? I spent months working on this, and I had to write all of that. And I could see this image. This is like my little baby. I was still looking forward for the Baruka conference. I was very excited. This time, I was going to finish the emulator for reels in one week. At least that's the way I felt. Funny enough, before doing this project, I looked for a headless emulator written in Ruby, and I couldn't find any. I was going to be able to say that this was the first Gameboy emulator in Ruby. And not just written in Ruby, but also in the HH. It just uses Ruby everywhere. It would be full of Ruby. Which was awesome. Just to make sure, I decided to go to GitHub once more, and I typed Gameboy emulator. 237 results. No surprise, right? There's lots of emulators. It's a common thing. You can see all the languages that are available, and Ruby wasn't on the list. So I thought, okay, that's pretty safe. But then I thought, what if... So I chose JavaScript, and I changed the JavaScript part in the URL to Ruby. And then I hit Enter. And that's when I see it. Two results. Actually, the second one is nothing. It's like an empty project. But the first one, this Rampan monkey guy actually did it. Have you seen the Simpsons episode where you can see Ralph's heart being heartbroken? That's exactly how I felt. Yeah, it was horrible. I had no idea what to do. I was supposed to come here and tell you, I wrote this Gameboy emulator and Ruby, which I partly did, right? I was turned into my first image. But, yeah, I was very, very, very demotivated. What this Rampan monkey guy did was just perfect. He was actually following the very same tutorial, and he finished it. Even had that graphical interface, and you can even see the same thing over there. I learned my lesson. Do a more deep research before writing a whole emulator. Yeah. So, yeah, I felt horrible, right? It took me a couple of days to realize that actually what I did, it was still great. I learned a lot by doing this project, I learned tons of things that I never would have that I would have never learned by my own. I'm a very lazy person, I have no problem admitting that. If you give me a book with the exact same information that I learned, I would have just not done it. I need a practical project, and being pushed just like that to us, and having a deadline actually helped me, you know, actually do the thing. I had to be very consistent, sit down every day, and work on the emulator. I also got out of my comfort zone. This is my first conference talk, and, yeah, it's not something easy to do. You work for a long time on something, and, yeah, I really wanted to go to Barucho, so, yeah, I did it for Barucho, and, yeah, it was actually quite fun. It's really neat to see something going from, I don't know, seven CPU instructions. You can sort of measure your progress, right? At least I did in CPU instructions. At the beginning I did seven CPU instructions. Then the first 100, then the first 1,000, and then 50,000. That's great just to see your progress and, yeah, just doing a Game Boy emulator. It's also a really nice topic to talk with people with. Last night in the speakers' dinners we were all talking about, like, what's her talk about, and somebody asked me, so what's your talk about? And I said, oh, I just wrote a Game Boy emulator in Ruby. And that was it. They just got it immediately. I can also apply some of this to my work. It's like it's given that I'm not going to need a late 80s GPU for my startup. But, for example, it's quite nice to know how to use bitmasks and what an hexadecimal address really, really means. And, yeah, how it works in the computer. Which is quite neat. I also learned the concept of conference ribbon development. Quoted by Tim O'Reilly, I can really tell you, man, this thing works. Most of this talk was finished just a couple of years ago. And, yeah, I kept polishing even until five minutes. And, yeah, if you need to get something done, just tell somebody you're going to do it and make sure that there's no way for you to back off of that. And, yeah, I just feel that sometimes you just need the right push to do things. Which I mean, you know it, but you still don't know it, right? Ultimately, I realized that the journey is the destination. And, yeah, it's just a little process that I followed rather than the result. I'm still standing here and I still have all this knowledge that I got, which the outcome is almost the same. Just before closing, I want to tell, like, a short story of the process that I had when I was, like, yeah, I was 14 years old when I started working as a freelancer. Somebody would come to me asking for a website with specific features. I was just getting into BHP, so I had no idea how to do them. But I still promised to do them nonetheless. And, yeah, I was going to get the money and then do whatever. I also had a deadline and, yeah, I promised the person I would do the features and then I just learned how to do them and then got paid for it. I did that very, very, very often, lots of times, and ultimately I knew all I had to do. At some point, I stopped over-promising because I had so much experience in doing what I was promising, which I think it's great. This project reminded me of the exact same thing. When I committed to do a Game Boy emulator, I had no idea how difficult it would be. I mean, I knew it was difficult. I didn't know it was going to be that difficult. But, yeah, I learned. Now I know how computers work, which is very useful if you're a developer. And I think that's the core message that I want to give you today. Just do projects for fun. Who needs a Game Boy emulator nowadays? It doesn't give you money, but you still learn a lot out of it. I feel it helps to grow a lot. So, yeah, I want to invite all of you to wear the hacker hat. Write irresponsible Ruby and get back the passion that you started into programming. Thanks a lot. What is the get-up repository of the emulator, if it's public? I can't show it anymore, but my Twitter handle is eljojo. You can go to github slash eljojo slash Miami. It's a quite nice thing to just dig into the code, and, yeah, it's actually horribly written, but, yeah, you can render a first frame in Game Boy, which is good enough. Any more questions? I want to know, would you do a conference-driven development again? Would you do the same thing of signing up for talk eight months in advance and then have to kill yourself every day to get there, or is that a one-off? Can we expect this as a regular thing? You're just going to keep coming to conferences and just turning up with crazy deadlines for yourself? Yeah, it's great. The problem of living in Berlin is that there's so many things to do that you postpone everything, right? Because there's Ruby Meetups, events, whatever. I had to learn how to be consistent and spend the time. I'm a horrible procrastinator, and this helped me a lot. Big round of applause for Jose.