 Okay, and now we're going to hear from James Edward Gray. You really shouldn't be doing that. I got a confession to make. I don't have a logarithmic graph in this presentation, so. I know. I'm sorry. I don't know who decided to put me after Dave Thomas and Glenn Vanderberg, but that was not a good idea. Jim, see me after. Okay, so I am going to talk about some things. Before I do, I'm James. This is some of the things I've done. I won't read them to you. It's all your intelligence. On my blog there, though, I do have a series about M17N and Ruby19. So for all of you that weren't at my training yesterday, you're obligated to go read my series on M17N. So you have to go check that out. That's me on Twitter. Okay, so what I'm going to talk about today. Like Glenn, I've spoken every Lone Star so far, and I did Heroes the first year on Battlestar Galactica the second year, but it hurt my feelings when I did Battlestar Galactica and over half the room had no idea what I was talking about. It's like, what kind of geeks are you people? So it really upset me. And this year I decided I'm not doing a TV show. I'm going to tell you about RubyKaigi, which is where I went this summer in Japan. And so I'm going to try to talk you into going to Japan to go see RubyKaigi. There's lots of great reasons you should go to see how the Japanese do conferences. That's a big plus. Also, if you give a speech there, they translate as people ask you questions. You get extra time to think about what you're going to say. You know, sound near as stupid. It's really great. You need to meet nice Rubyists from all over the place. I met some from Japan, some from other places, of course. And you get to see Japan, right? That's the reason to go to RubyKaigi. So these are some of the people I met. That's Florian from Germany. That's Kazuki from Kyoto. And Sogo, he translated my slides into Japanese. So he was a big help. And you get to see Japan, like all these great temples, right? This is Nanzenji, I think. It was one of the temples. And these amazing views of Kyoto. Or you can go see Sumo like I did, right? That's the guy in red, Yamamoto Yama. He's over 500 pounds. And this picture is literally snapped while he's picking that guy up that he flung out of the ring. So that's just awesome. You can't get anything like that here. That's just great. And that's fine. I do 45 minutes of this. I got a lot of pictures. I took 800 while I was there. So this is the streets of Tokyo shopping. Tokyo. This is the view out of my window in Tokyo at night. So the nightlife in Tokyo. And this is a tea house in a garden that I saw. Okay, we better talk about some Ruby. They're really not going to let me talk next year. So here's some Ruby. This is something I suspect everybody in the room knows. This is just a simple mix-in module, right? So you define a module. You put a method in it. You include that in a class. And then instances of your class have access to that method, right? Those prices there. Everybody knows how this works, right? And you can call that method on that class. Those price. Okay, we talked about Ruby. Let's go back to Japan. All right. So this is a sand garden in Japan. You see these all over the place. It's like meditation gardens, and they design the sand in certain ways that you look at the sand and you contemplate your... I'm not even sure what you contemplate, your relationship to the things in the sand garden and stuff like that. Some of them are kind of strange, like this cone one here. So these are these meditation gardens you see in all the temples in Japan. So here's a piece of Ruby code I think is worth meditating over. It's actually a pretty interesting piece of code. I'll walk you through it. So it's just a normal class that has a method called call, and when you call it, it prints out the class name. In the middle part, I apologize for the use of eval, but slide doesn't have very much room for code. So it just defines three identical modules, or BCND. They have a call method. They print their name, and then they call the next module up the chain. So that's all they do. Print their name, call up, right? Then we build a child class, that original class, and we dump all three of those modules in there, and the child class also has a call method that just prints its name and calls the parent class, right? So it's just calling up the stack, and then I make an entrance to that class and call it. Okay, so everybody got what that does? Everybody kind of figure that out? Okay, so raise your hand if you think you know what this prints. How many people? Ooh, not very many people. We don't know what this prints. It's only five things. No? We don't know? Okay. See, this is why you meditate on this code. It's very important. This is what it prints right here, and it shouldn't be too surprising. The bottom class prints first, because we called that method on the bottom class. Then the three modules print, but note that they print in reverse order, right, of the order I included them. So I included it BCD, but they print DCB. And then the parent class, the very top prints last, right? This slide, this one piece of Ruby code, explains about, I don't know, probably 80% of Ruby's method call mechanism. And if you can get the hang of this, you can do great things. Okay, so I'm going to show it a different way. This is the inheritance of that slide that you just saw. So all I did was I asked that object for its ancestors, that class for its ancestors. And this is what it said. This is under Ruby 1.9. If you run it under 1.8, it would look exactly the same, except without the basic object at the beginning. But you can see there's that class E, and it says it inherits from those modules. We included DCB. Then there's A, that was my parent class. Then you've got object, and object inherits from kernel, which by the way is a mixed in module, just like what I showed. And then inherits from basic object, Ruby 1.9. Okay, so that's boring, right? Let's go back to Japan. So you can see all this great water in these gardens in Japan. It's the clearest stuff. You can see right through it and check out the fish that are swimming around, or put your hand in, and you can just see it because it's just so ridiculously clear. There's this water in all of the gardens in Japan and stuff. So you can kind of look beneath the surface and see what's beneath the surface. So let's see if we can go beneath the surface of that example. I showed just one more level. This is pretty much the same thing. The top two chunks are the exact same thing. Only the bottom is different. I could totally get rid of the child class, and instead I make an instance of the parent class, and then I extend that instance with those modules, and then I do the call, okay? So we had about, I don't know, 10 people last time they thought knew what the last one print. There's only four letters this time. Raise your hand if you think you know what this prints. Yeah, that'd be three. No four. I think I saw four. Okay, so this is what it prints. Were you right? Was anybody right? Yeah, Jeremy was right. Okay, so this is what it prints, and you can see the modules come first. So D, C, B, again in reverse order of what they're included, and then you get the parent class, right? If you get this one, now you've got like 100% of Ruby's call mechanism. So you can understand how Ruby handles methods. And this one, if you look at the ancestors, it's even trickier, because look at that. It says that when you call ancestors, it says it inherits from the modules first. And that doesn't kind of make sense. Wouldn't a class have to come first? Actually, it does. There's an invisible class right here in front of them that the Ruby source tends to refer to as the Singleton class, and it's invisible, and it's in the front, and then those modules are stacked up behind it just like they were behind the child class, and then you have the parent class, right? So it actually works the exact same way. The only difference is that there's an invisible class involved this time. And we can actually make that show up. If I do the exact same example, but this time I took a method into that invisible Singleton class, then when I print it out, look, it shows up. There's the invisible class, there's the modules right behind it, and then the parent module. You can call all the way up the call stack and you get back to that parent class, right? So that's the way modules work, and as you realize that, you can do amazing things because now you realize you have ways to put methods behind your class and you have ways to put methods in front of your class, right? If you want to change behavior, modify behavior. And it also told us what extend was. Extend is actually just a shortcut. It means this. Open the invisible class and include that module, right? It's just a shortcut. So that tells you what extend is. Okay, something else. We use modules for different things. I'll do less scary stuff now. This is different things. This is using modules as namespaces. That's the other use we tend to put modules through. So for example, this is a logger in Ruby's standard library. I imagine it's a class most of us have seen at least a little bit. And it has this severity module inside that has all these different debug levels. And so it tucks these constants away inside the module. And then interestingly, it includes that module inside the logger to get access to those constants. So you can move those constants around with that typical include mechanism. And if you were building some kind of programmatic JSON representation, then you might need to make classes like array an object, which obviously you can't do because Ruby has an array class and an object class. So you could tuck these away inside a module and they would be in a different namespace, right? So we can mix things in. Okay, so back to Japan because this is a lot of code stuff. It's very boring. This is food in Japan, which is awesome. That's like one of the reasons to go. Although don't ask Dana because she doesn't eat fish and that's not a good thing to be in Japan. Can you see this? This is a block of ice and then there's food sitting on top of it. If you lift that metal thing off, there's a bowl hollowed out in the ball of ice. You can kind of see it in there. And there's a noodle broth soup thing in there inside the ice bowl, which is pretty cool. And that flour on top has a duck egg inside of it and all kinds of crazy stuff. I didn't know what half of the things I was eating were. It was great. I ate them anyway. I would guess I was usually wrong. Orange things can be pickles or eggplant, which are not the same. Very important. They're desserts, right? These are their desserts. They look great, don't they? Interestingly, if you saw this dessert here, you would probably think really, really sweet and you'd take a bite and it would be really, really sweet. If you see a dessert like this in Japan, outside it's not very sweet. They don't like things as sweet as we do. And they tend to be more bland than what we eat here. This is Sashimi from Skiji Fish Market, the world's largest open-air fish market. So fresh fish that day, plus fish eggs and stuff. That's great. Anyways, Japanese food is all about presentation. They have this great presentation. When they put it in front of you, you're just like, wow, that's awesome. And sometimes we have code that's about presentation. So there's a math module that comes with Ruby. And I don't know if you know this, but you can use it two different ways. So if I'm writing a distance function, I can just call into it like this. Here's my distance thing. Or I can choose to write it like this. I can extend my class with the math module and then I can refer to that method without calling into math. Which means that that module has to be both a class method on math and an instance method on math. It has this kind of dual interface. So you can do that too. There's different ways to do it. The math module actually does it with Ruby's module function, which is a helper to do the same thing. I think this is even easier because it follows the same rules that we understand for modules. But you can just put your own module inside your ancestor tree, right? Just extend self, and you'll put your own module behind your ancestor tree. So then you can use these methods with a dual interface. So in this example here, I've just called the mode log method I wrote directly on the mini-logger object. Or over here, I've actually included the mini-logger module, and then I can override logger and call log as an instance method. So it gives me the dual interface, the same thing that you see in the math class. So one of the awesome parts about running around Japan is they have these shrines everywhere because Shinto is so big. And this shrine here, literally there's a gigantic store on the right of it and a gigantic store on the left of it. So you probably wouldn't imagine that from the picture here. But they're just hidden away all over Japan. And part of the fun is running around Japan and looking for these little shrines. This one is on the side of an access road. So you got trucks coming around behind something and a little Shinto shrine sitting on the side of an access road. This one is actually at a temple, but it's this stairway up to the side and you kind of take this around and then you just dead end at this shrine. So they're just tucked away everywhere. It's like these little bits of magic all over the place. And you can run around finding them. You can use modules for the same thing to take away little bits of magic and keep them from running into the other parts of your program. So this is a trick I use sometimes. Some people don't like it by the way, but I think it's kind of fun where you can auto generate error classes as you need them. So you just build some base error class, define const missing, and whenever you try to access some constant, like save error, it inherits a class from that and sets it to that constant for you. So you can just generate error classes as you need them. And this is a bit of magic because I had that override const missing and if I did that at like the top level then that would be a really danger attack because you could just invent classes all the time. But because I'd tuck it away inside a module, it's not a really big deal. That's the point of this module is to contain that magic. So you can do that. So I'm going to give you some examples of just different ways to use modules and just see if I can get you thinking along lines you maybe haven't traditionally thought about. So this is just unusual ways to use them. I actually had this code in a project recently and the point was I wanted a configuration object and I wanted it pretty much just to be an open struct, but I also wanted it to have a couple of behaviors like being able to load itself from a config file or something like that. I wanted to be able to put a few methods in it. So I did this clever thing which Ruby totally let me do which is awesome. And then eventually this was part of our public API for this project. So my boss is like, you get a document all this. I was like, you get a document this? Ruby doesn't read it. Our doc doesn't read it. Ruby will read it, but the our doc sucks and it won't read it. Right? The cool thing is the our doc parser sucking might be a feature. Right? If our doc won't read it, it's probably a bit too clever. Right? I mean, in a way. So, yeah, and this is just like how it's used with the method calls and setting values just like open struct. So, okay, we can rewrite the same thing using a module. So we just build some module with the extra methods I want to include. And notice I can document this just fine. Now our doc doesn't care. It can read modules. And then when I create the open struct object just extend it with that module. Boom. All that behavior gets put into that one instance. And now there's still just that one instance that has that modified behavior. So it's the exact same thing only our doc and I can both read it now. Right? And this example right here, I think we should be doing more of this which is kind of what I think Dave Thomas was talking about when he said he was doing less building with classes and more building with modules. You know, you can make these individual objects and then you can just mix some behavior right into them. Okay. One of the cool things about Japan is everything's just so classy. Like this is a, I don't know is that a cat? It's a cat statue. I'm pretty sure it's a cat. But what's awesome is they have this legend about this statue. There's this and another one right next to it. And they're at a shrine in Ueno Park. And they have a legend. There's a big pond in that park. And they believe that these statues are so lifelike that at midnight they sneak off and get drinks from the pond. So they just run around. They have all these cool legends. This is the grave of the 47 Ronins. Anybody know the story of the 47 Ronins? Hand if you know that story. Okay, yeah. So people know. One of the, their master drew his sword on imperial ground. So he had to be put to death. And so his 47 Samurai became 47 Ronin. And they snuck off and hid in the population and planned and plotted their revenge until everything was perfect. And then they stormed the enemy lord's castle that had provoked him and killed him. And the Van Emperor was impressed by their devotion. So he allowed them to all commit ritual suicide instead of being put to death. Because ritual suicide is honorable and being put to death is not honorable. So they have this and this is their grave. And people come and they put incense on their graves and the individual resting places of the different Ronin. This is a torii date. You'll see these all over Japan spirit gates where you go through and it's believed that you're purified as you go through them and enter these holy places. So everything's just real classy. In modules we like to have our class methods too. But really doesn't give you that option by default. But that's okay. We figured out a way around it. This is a popular pattern. It was around before rails, but rails is probably what made it popular. Where when you want to mix in a module, you can basically break it out into two sub modules, class methods and instance methods. And then you can extend your class with the class methods and then include the instance methods in your class. So you get the class level stuff and you get the instance level stuff. So basically you get a dual level mix in. That's cool. The other thing you see in Japan is strange stuff. Right? I'm not sure if this ad makes me want to go eat bananas. Which may be the goal. I'm not sure. They also build gigantic anime statues that tower over their city. Which was totally awesome by the way. That's just great. I have a picture of me at the foot if you want to see that come see me later. So yeah, big giant anime statues. That's awesome. Or at Rubikage, you can see Aaron Patterson and his Laugh Ninja. That literally stood behind him as he gave his talk and held up signs so the Japanese audience would know when to laugh at his American jokes. Yes. Very clever. I'll have a Laugh Ninja Lone Star next year. That's awesome. So you can see strange things. You can also do strange things with modules. So here's some strange things maybe I haven't thought of. DRB unbumped. Does anybody know this module? You can include it in a class. You're going to send over DRB. And it tells DRB to send a proxy instead of actually sending the object. So your object really stays on your side and it doesn't go. This module you actually see a method here but this method is never used. It's just added as kind of a protection to make sure that it is never used. You can see that it raises an error so if it gets called something went horribly wrong. So this is actually an empty module. It has no purpose. The purpose is to tag something to name it or label it. So you include this module in your object and it's now your module's this new kind of thing. In addition to being whatever it is it's also a DRB unbumped and that has meaning to the DRB and it can identify it. So even empty modules can be useful. Also you can do some object editing. You can't do this in normal Ruby because some of these string methods are designed to return nil if they didn't make any changes in the bang versions of the methods. So you can't chain together the bang methods because you get a nil and then you try to call another method on it and it blows up. You can actually use a module not to include methods but to edit the object. So this is a module and I tie into the extended hook. This is a hook that Ruby's going to call whenever you extend an object with your module and it's going to pass in the singleton class of that object that you're extending. So you can take this as an opportunity for free editing. So when a string is extended with this module I run through the method list real quick and redefine all the bang methods so that they return self. Right? And because I define them in the singleton class we learned before with the method lookup those come before Ruby's traditional methods. So I actually override all of Ruby's traditional methods and now you can safely just chain bang methods together. Is this a good idea? Probably not. You know, it's kind of interesting that you can do it with modules for editing. So, okay, so here's kind of a summary of just some of the things I've been noticing about my usage of modules and some things I think we should be thinking about. First I think you should spend a little time playing with Ruby's method lookup and figure out how it works. How that when you include modules they end up in a linear stack between you and your parent class. You can use that to your advantage once you know that because super works, right? It goes to the parent class and it's worth knowing that. Or if you extend an object with your module then you're putting those modules in front of it between its singleton class and its real class. So you can use that for overwriting things like if you want to edit bang methods or whatever. They're also terrific at limiting scopes of magic. If you do really scary things then, you know, tuck it away to modules so that, you know, at least you're really scary things you're doing are only limited to that one space and you can control it. Remember that modules can modify individual objects. This one's really important I think. We don't see nearly enough of that. That, you know, like pagination is a great example. We always have WillPaginate and then they build this collection class always. And it's basically array plus current page, next page I don't know maybe another method. That's like a per page, right? Yeah. Three methods on array. They could just return an array extended with a pagination module that had those three methods in it, right? It's still an array. So I think we should do more of trying to replace inheritance with extend and trying to use modules more in the typical inheritance chain less. So that's it. That's some ideas. Questions? Yes, Jeremy. What happens when you extend the same module twice in the same class? Yikes. No, I don't want to talk about that. Thanks for asking. Okay, so why would you do that? No. Nothing happens the second time. Is that totally true? Because I know a module include time it's actually based on the ancestry of the module at that time which I didn't want to show because that gets a little scary. Because if you later include a module in your module but it was after the module was already included somewhere else, you don't have the previous inclusion and so I was wondering when you include it the second time, do you get the new ancestors? Does anybody know? I have to check. It gets completely skipped and doesn't do anything. So that doesn't modify your inheritance hierarchy at all then. So it's actually safe. So that's awesome because then you can keep stacking them in there, right? And it doesn't matter if it's happened or not. Yeah. Right, so the gotcha there is if you have like A and then your module B and your module again but you call super from your module you're going all the way up to A. You're not going to stop at B. So there are some gotchas there. And this gets into a scary module and probably a little bit but yeah. Good point. The included hook gets run twice so if you have something in the included hook it gets run again and you need to be careful that that code doesn't edit your object again. That's it. Anyone else? Other questions? Okay, that's it. Thanks.