 Video equipment rental costs paid for by peep-code screencasts. So my name is Evan Phoenix, and I work for Engine Yard. I'm the Rubinius lead developer. And Jim asked me to come here and give a little keynote. Woo! Jim! So I thought about it for a while. A big talk procrastinator. So, you know, I was, you know, doing the last bit of the slides all today, all the slides. And this being a fairly short one, I kind of decided I'm not going to talk about Rubinius. So if anyone wants to talk about Rubinius, I'm happy to do it. We can talk about it till the cows come home. This is Texas after all. So I guess it would be steers, though. So we'll do that another time. Today, in the next half an hour, what I want to talk about is something a little more fun. This is actually, this will work really well if everybody had a beer in their hand, but that's okay. So what I want to talk about is actually fun moments in Ruby community history. And a lot of that is tied up in the fact that the Ruby community is, I think, not unique, but really interesting in that the Ruby community loves memes. And you'll see someone mention something, and then there's this almost avalanche effect of people doing the same thing and trying it out. And it becomes this really widespread adoption really fast. People start to really have fun with it. So what is a meme after all? So an element of a cultural system, a behavior that may be considered to be passed on from one individual to another by non-genetic memes. Again, this is not that kind of conference. So we're talking about you tell your friend and he tells his, or you show him some technique and he shows his friend, right? That kind of, well, okay, touche, it is not that kind of conference. So not that kind of showing. But nonetheless, it's this idea that your, this information spreads really quickly and the Ruby community is really, really fun for looking at that kind of thing about how those things get discussed. And so this is going to also talk a little bit about history. So there's some of these topics that I thought would just be fun to kind of give a little background. So let's do a little test here. Who has been programming Ruby for at least a year? Raise your hand. We're going to go, okay, sweet. Okay, two years, three years, four years, five years. Six years. And Dave. Okay. And Jim, too. I'm sorry, Jim. So that's about right. Okay. So it's 2008. So most people, hmm? Well, you know, that really doesn't count, but nonetheless. So that's actually pretty good because so we're talking about people. A lot of people started in about 2004, 2005. So that's going to, that's going to work well for this. So about that time when a lot of you were first coming into Ruby, one of the, one interesting thing that happened was that we were having a big onslaught of Java programmers come into the community. I say that like sort of like a barbarian horde because that was kind of how they were perceived by the rest of the community at the time, right? And one thing that they brought with them at the time was this idea of dependency injection. And we went through a period, I'm now putting on my Ruby anthropology hat here. We went through a period I like to call the dependency injection rash. And if you look back on the mailing list, you'll see that starting in about 2004, as I said, we had this influx of Java developers. And they had become very accustomed to this idea of dependency injection using things like spring and such. And the concept seems sound, right? You want to decouple your relationships. You wanted to, really you wanted to make your code as modular as possible because a lot of times you want to write tests or you weren't really sure what was going to happen in the future. You wanted to have it be flexible enough to be able to deal with any future concerns you had. And with that, especially as it comes with all Java programmers, comes the F word, framework. And we saw this idea of, you know what Ruby really needs is it needs a dependency injection framework. And so for about, it lasted a couple of years, but it was a really on everybody's mind for about six months. Everybody was like, oh, someone needs to, who's going to write a dependency injection framework? We had James Buck who wrote two dependency injection frameworks in this time period. That's how enthusiastic about it he was at the time. In fact, he got so into it, he, Capistrano used it, NetSsh, well, I think maybe just NetSsh used it. And it became this big idea of let's use, they seem really awesome, let's use dependency injection frameworks. And the kind of the history goes that people are like, yeah, that seems awesome. They seem great for Java. Let's just translate that into what we need for us. Fortunately, well, actually I consider it fortunately. Fortunately, this is kind of what happened. The more people thought about it, the less useful they realized it was for Ruby. And really because what it was is this idea of dependency injection, if you really boil it down to its simplest most pieces. And really what it does is it adds dynamic resolution so that you can delay figuring out what something should be or how something should function until really as far down the road as you can. And wow, what does that sound like? Maybe Ruby, my friends? So what we found was, you know what? People have been doing dependency injection in Ruby since it's, since, you know, Matt's probably did it the first time he tried. Just because it becomes a natural part of having dynamic late bound resolution. So let's look at a real quick example. We've got this class that does a bunch of work. It's got some little part. So we want to call some get, some get method on the class itself. And that's going to return some object that does some work. Well, that's really easy, you know? We can, we've delayed figuring out what this object is just by the fact that we're using Ruby. So if we ever want to change it, we can just go and do something like that. And we're done. We don't need a framework. That's the, we just did dependency injection. It felt awesome, didn't it? You know? And people thought, well, that's kind of brittle. So we've got all kinds of ways. We can use classes, just assign them to classes and use class variables. So here it starts off with a default. And if sometime later you want to change that part class, that's great. And then whenever it needs one, it just calls new on it. So you find that this, the power of this late bound dynamic resolution gives you all these doors that you've never had before. At first, it seems natural to think, oh, I'm going to need this. I'm not sure how this is going to work. And the more you deal with Ruby, the more you kind of feel its flavor. You find that it's so dynamic that you don't really need that kind of thing. So we went through a little bit of catharsis. And to this day, we don't, no one uses a dependent, almost no one. Has anyone in here used a dependency injection of framework in Ruby? Yes. I was afraid that was going to fail. So, but it's really great to look at that as a time period in the Ruby community. Because what it said was that these people brought these outside ideas into the community and they really, they vetted them. They tried them out. They did different things. And what they found was that the tools were already there. They didn't need to add tools to the environment, to the language, to get what they needed. But as time goes on, it's important that we remember these things. Because programmers have a really bad reputation for not looking at what has been done before them and just kind of going off and doing the other thing. So I encourage you all to remember that we tried the dependency injection thing once. And it didn't really work out very well. So let's move on. So this one is a little more fun. It's again, it's a little voting one. Look at that code. Everybody kind of familiar with what that's going to do? Like see most heads? What is C? You get three choices and then we're going to have a shout out round. Who thinks you call that thing metaclass? Raise your hand. Smattering. Who thinks you call that a singleton class? Same smattering. Who thinks you call that an eigenclass? Well, we've got some eigenclass people in the house. All right, anybody want to add something to this list? Anybody want to add a definition here? The ghost class? Shadow class I used for a while? This is kind of one of those really interesting debates. See, we've got a debate going on right now. This is one of those great debates that's always occurred within the Ruby community is what do you call that thing? And it's fun just to actually to see people try and answer that question because what you find is that they realize all these awesome things about Ruby in trying to define that thing. And they go, oh, that thing's there. Oh, it looks, it's over here, too. And if I add stuff to it, it can do that over here. And so I almost like that we haven't figured out a name for it, that we debate what its name should be. If only because then people get drawn into this debate and they go, what are you talking about? And then you can explain it to them. And then they can go off and they can try and figure that out for themselves. Kind of a fun little thing. So next. So we're doing pretty good here. So I called Metaclass in Rubinius, actually. That thing, if I were to call C.class there, it would actually return a class that calls itself Metaclass. So the reason it has this unknown name is because for the most part you're not really supposed to know that it's there. You're not supposed to so much see its name. And so in Rubinius we can't really, we have to call something something. We can't call it nothing. We don't have a hidden layer. So we call it Metaclass. So that's what I call it. But don't do it because I do it. Okay. So the next thing is a meme. And it's a bit of a rant. So you'll excuse me for a moment as I rant on a meme. But I think it's certainly interesting to look at because it became and has become a little pervasive. We're going to talk about this. What I mean by this, I mean this thing right here. Now let's talk about, we're going to go, I'm going to take you back in time a little bit. We're going to look at the definition of class. Okay. A set or category of things that have some properties that are attributed in common that differentiate themselves from others kinds or types or quality. I'm going to give you a little, a new class of heart drug, whatever. A good example of a class hierarchy might be this. You've got a class that's an organism. It's a mammal's or organism's and a feline is a mammal and a house cat is a feline. That seems pretty clear. We all, those have common groupings. They've got common relationships within the groups. You could easily say that there's a bunch of different nice hierarchies out there. Obviously I use animals because that's our generic sort of class hierarchy thing. Ruby also adds another level of class hierarchy by giving us mixins so you can have stuff, oh, it's land-based or it's water-based. It flies. It swims. Remember we're looking all here at the way things are named, the way, because what something's named is again what you call it or how you think about it. Like we were looking at the thing, the slide right before, the metaclass. And so when you look at these names, you can go like, okay, well, land-based, that'd be kind of weird for it to be a class. It makes sense that it's a mix-in. They have lots of things that are land-based. They're going to span lots of categories. Same with water, same with water-based, same with flies and swims. So what the fuck does base mean? Okay, is it this? Is this what we're trying to say here? Are we trying to subclass a military base? Is it going to be in sand this time? Are we putting it on a different continent? I plead with you, my friends. To remember this, that every time you name a class base, moving on, the singleton pattern is a great one. And we see a lot of, this is again, comes from the Java, the Java barbarian ports bringing this into our camp. The commonplace of, well, I need to, you know, I know, I'm sure there's no way I'm wrong. I'm going to need one of these. There can only be one. It's got a little bit of highlander syndrome when it comes to classes. But do you really, really need there to only be one? I mean, if you think about what you're modeling in these cases, I think almost all, every single time you're going to decide, no, there's probably, it's probably okay if there's more than one. And what you're really trying to encapsulate is this idea of, I want to be able to reuse an object over time, right? It's that maybe this object has a high cost of creation. Perhaps a good example from RubyGems is there's a remote-fetcher object. And you only want to create this one thing one time, or it's useful. You're going to need to go out of the network a lot of times. And so it does a lot of DNS resolution the first time. It does a whole lot of work up. It really, it kind of be sad if you just threw these things away every time you need to do, go get one little packet, right? I've skipped ahead. That's okay. Let's not forget that the single-tempatter destroys testing. There's no doubt that the use of the single-tempatter makes your tests ten times harder because you have to defeat the singleton pattern every single time. Again, this is like Highlander. You have to go in, you have to cut its head off every time you run a test because you need to clear out what happened because you don't want those tests to be coupled. And so the Ruby community went through this idea. There's a singleton.rb of how do I use it? I should be using it. I know that there's only going to be one thing out. I know that I only need this thing. And what happened is that over time we all grew and we all realized that what we really wanted was, like I said, not that there's only one thing. We just wanted to be able to reuse that one object. And so we invented this as a nice little paradigm meme, little contract between us. Everybody kind of familiar with this stuff? I'll go through it real quick. Well, obviously we're making a class, making a method called instance that we can totally call thing.instance. And then we just use the pipe equal operator to create a new instance if it's not there and return the one if it already is. And so now we're done. Now all we have to do is call thing.instance. And so we have singleton pattern done in Ruby right there. No need to ever require singleton again, all right? We're good? Okay. This was a hot topic. It still is a hot topic in sort of class programming language circles. You'll see it come up. I think functional programming has probably kind of overtaken it in the general chatter that seems to occur amongst nerds. But it's still pretty high on that list of aspect-oriented programming because it seems like such a cool, cool thing. And over time we've seen a lot of people who showed up willing to do aspect-oriented programming in Ruby. We've had libraries that do aspect-oriented programming. We've had all kinds of different things that try to encapsulate it. And what's funny is it seems to have, typically the idea is it's got this kind of all or nothing. I've got aspect-oriented programming or I don't. And I'm here to tell you people that you have aspect-oriented programming and it's called Atheist Method Chain. And as much as we may not like it, that's what Atheist Method Chain does. It's a simple aspect-oriented programming pattern. But it's kind of interesting how much this pops up. I dare you to go home and search the mailing list for Ruby AOP and just glance at the number of conversations that have occurred over the years. It's kind of interesting to look at it. I think part of the reason that it's never taken hold is because you've got such powerful metaprogramming in Ruby already. You don't really need the aspect-oriented pieces per se that give you the syntax for it. We've pretty much worked around it. So we have history, we have meat. These have been, for the most part, technical memes about what goes on, sort of technical history. We've got people. People as memes, too. We have why. Why exists in the Ruby community as a meme, largely because he appears, he does something and then he disappears and you never see him. And the rumors about why permeate every Ruby conference. Every Ruby conference I hear a new theory about who he is. Here he is for those of you who haven't seen this picture. This is his self-portrait up in the upper right here. And that picture was taken at 2006, I believe, at Fosconn. And if you were the cagey, unknown, this is actually, his Wikipedia page is awesome. It lists his name as unknown. It lists it just like this. If you were this kind of cagey figure who we didn't really know, who kind of appeared at conferences and sang us fun songs about Ruby programs and disappeared, I think we'd also talk about him, but what is truly amazing is the amount that the guy outputs. You know, he's been a huge contributor to the community and yet we know so little about him. Other than, I think probably we know vastly more about his code than we do about him and the person, which is pretty interesting if you think about, I think about that. So I wanted to bring him up just because it's, he's such an interesting figure that we're always talking about. And he has memes of his own, of course. We can't forget Chunky Bacon, right? I pulled these three strips from the poignant guide, just to kind of get it. If anyone wants to come on stage, we could do a dramatic reading. Okay, all right, well, maybe next time. And the Chunky Bacon meme is just hilarious. I think it says a lot, actually, about the community that we have this, we have a guy who we don't know his name, we don't know where he lives. He writes these amazingly bizarre comics and just basically leaves software on our front door for us to read. And it says a lot about that we kind of embrace him and we use his little handmade memes in everything. You know, people use Chunky Bacon as default variables in fixtures and, you know, they name their dog with Chunky Bacon. Just, you know, why not, right? So, and then on the other end of the spectrum, we have a guy who requires you to know his name. And I'm not, this is a nice guy. I'm not going to say too much about him. I don't think his ego is big enough. I think we can leave it at that. So moving back to technical memes, we've got Git. Git's been kind of a fun meme if only because I feel like I was part of the initial kind of push. You know, the, we switched over, I was kind of experimenting with it on, just on my own using Git SVN for a long time. And then we kind of, we took the plunge, well, I took the plunge and I towed everybody along. But it's been kind of interesting, you know, to see how it's risen in the community. And again, I want to point out how fun it is to see what has happened because, you know, even today we had people saying like, oh, subversion, blah, you know, like in presentations, it's, you know, that was a year ago people would have been like, ah, CVS blah, subversion, yeah! And, you know, it's fun, actually, if for no other reason than we're not, we tend to not be mired down in the, I mean, it doesn't even have to, technical merits aside, just it's fun that we're not mired down in the old ideas that we're constantly churning things up and looking for new things. You know, the idea that Rails was like, you know what, we're going with Git. You know, everybody in here, you know, you want to get the latest thing, you got to put it all in Git. You know, that's a big thing, you know. And then we see that, you know, the Ruby community pushes back again on those tools. You know, we see things like GitHub, that if there was a Git survey that went out recently that people are asked to participate in to say, how are you using the tool, how do you think it could be improved, that kind of thing. And GitHub has a huge number of people using it, and this is supposed to be a survey that's done by all kinds of people. It's not closed yet, but it's really interesting that we're, now the community is pushing back. They're trying to strive. It's getting legs in other communities and that kind of thing. Too slow is another really interesting meme that the Ruby community continues to deal with. And this is again, this is a bit like high school rumor, right? You ask someone when they say it's too slow and you say, oh really? How do you know? My programmer buddy tells me. Or I tried this one little program and it was super, it was just crazy, out of this world, slow. And I think the important thing to remember here is that you can write shitty software in any language. Let's not forget that, people. So I think the answer is always like, okay, for home is it slow and for what? Speed is such an interesting thing. It's such a subjective matter, especially when we get into the idea of how fast is your website. The number of elements between you, the consumer of the website and the CPUs on the other side that are churning out that website are so many that it's really interesting to see how people address that. Now it could be faster. There's certainly aspects of it that could be improved as a tool, but I always find it funny when people are like, oh, it's so slow, I can't deal with it. I just have to chuck it out the window. And they go, you know, if they were to go and look, they'd find that, oh, well, I'm adding up, you know, an array 10 billion times and I probably shouldn't do that, you know. Anyway. So, Macintoshes. I'm part of this meme. But it's funny to look. This is certainly not a meme that is concentrated to the Ruby community. But it's fun that the Ruby community has acknowledged it so well. You know, like, okay, so raise your hand if you have a not Mac at your table. Oh, okay, one person per table. Otherwise, I... I thought you guys were smart. Okay, so, you know, we've got a pretty good... You know, we have a smattering. I think, actually, this is probably the most I've seen. Maybe it's because we're close to Dell. Is that maybe the deal? Anyway. So... Yeah, yeah, so effort. So, in fact, it's gotten... People say bad. I think it's gotten so pervasive now that at to the... 2006? Yeah, I guess it would be... Yeah, the 2006 RailsConf. Special non-conformist papers were passed out to anyone who did not have a Macintosh. This is, again, why showing off his non-conformist certificate. If you go back and look, I think there's pictures of everybody who got one and there was something like... There's only, like, 30. There was some, you know, hundreds and hundreds of people who were there. I don't know. I bring this up, not this way because it's super funny, just because it's really interesting to look at the adoption rates and how people kind of... Oh, yeah, everybody's doing... You know, they're using that, and it seems like it's really working for them. Text me this kind of to pull up in that, right? You know, your friends are using it and they're doing really well, and they've got the snippet thing that shows their email with porn on the side. I got to have that. I can't judge. Rails can't scale. You know, this is one that we'll hear... We'll probably hear forever because this is nothing new. People have been saying, this ex can't fall. I mean, those statements are always thrown out only because they're three words, right? People love three-word statements. So... And again, don't forget that you can write crappy code in any language. So I'm not going to address this too much, mainly because I don't write Rails, but, you know, what can you do? The next one is really important, and that is pickaxebook. Everybody knows it. It exists in a thing of myth, and I think we should all give Dave a hand because I'm going to go out on a limb. I'm not afraid to be wrong, but I'm going to go out on a limb here. I'm going to say that this URL is responsible for the takeoff of Ruby in the United States, for the most part. If only because... I mean, this is certainly... This is the original pickaxebook online, and I don't know a single person... I started using Ruby in about 2002. I don't know a single person that didn't learn Ruby or learn that they wanted to continue to do it if it wasn't from this URL at the time, so I wanted to... I want to give my shout-out to that, so... Some of us... Yes, if you had the hard copy, then you... You know, I didn't have the hard copy. This idea of a Ruby C-Pan is another really interesting meme that has been propagated and continued throughout the years. Earlier on... And earlier on, I mean, like, more than a few years ago... You know, we didn't really have a central way. We were originally Ruby hat RAA.rubylang.org, which was a way... It's a place of registering your projects and putting your tar balls up there. And people had always talked about, finding things and installing them and that kind of thing. And about 2000... I should have put this date in here. 2004, I think we had the Ruby gems versus RPA Civil War, which was pretty interesting. I got to say, I was actually on the RPA side for a while. I was actually one of the original RPA mirrors for a while. Yeah. Like I said, I'm not afraid to be wrong, so it's cool. It's been interesting that, you know, we had people come up and say, like, I'm going to solve this problem and here's going to be my solution. And, you know, we, for the most part, we've added some really good ideas. And to this day, I think we have a really great solution. You know, it's got problems, but what one doesn't, you know? I think if nothing else, the community has been able to show is this ability to take the good with the bad and to figure out how to move forward with what we have. In fact, Jim was telling me earlier that now we're even hearing this out of the Pearl community. We really got to have something like that, Ruby gems. That thing is the bomb, right? Which I think, I love this. You know, CPAN has existed for 20, you know, however many, 20 years, 15, 20 years, and now they're like, oh, that Ruby gems thing is pretty sweet. So I love this. This one, this one. I don't know what, I don't have to say anything more, I guess, right? The ultimate bike shed of programming. I'm going to go on a limb, this argument parsing. This is just a real quicky little list. Yeah, the case statement, this is just case statement at the bottom. Oh, what's Jim's? Okay. And this is why we have 28 option parsers, right? I think it's funny. And I don't think anyone cares, because option parsing is one of those things that you start to do because you have some little tool and you're like, I got to parse some options. I'll just do it right here. Option parsing, how hard can it be? 28 implementations later. DSL. Now, Ruby's always been this idea of having it be a DSL, but there's sort of a peak in the time that it started to really take off. And in 2003, we initially had, we had water come out, and this is the first year that Jim had worked on rake. And so we started to see this, really this idea of how do I take what we have and how do I really make it whatever. So, fine. So, you know, and it started to take off, you know, this idea of, okay, well, you know, we can model our problem space in sort of this custom language, you know, and really the list people were going, duh, the whole time, you know. That being the only way to actually solve a problem in Lisp is to write your own DSL. So, in 2004, we saw Builder and Market become about, and it's kind of fun because we continue to see people push the boundaries. In 2005, we had Switchtower or Capistrano. And I don't have, you know, a big revelation about DSLs. I think they're just really interesting to look at how we've evolved them, you know. People take it, there's always an equilibrium with how these things work in the community, you know. People, you'll see libraries released that are a DSL for performing toast options on ground bread, you know. And you're like, okay, well, do we need a DSL for that? That sounds like a toaster, you know. But, you know, and it kind of swings back. And I think what's great is that we keep having all these people using these ideas and putting them out there. And, you know, they go too far and then they come back in and eventually we strike this really nice balance. In the same way of BDD and the resulting frameworks, they're unto. Now, BDD was really what happened when you took a DSL and you unioned it with testing, right? We already had a test unit. We'd had it for a long time. We had our unit before that. So we were pretty familiar with the whole test idea. And this idea of not only testing just the unit test but testing the behavior of the thing was part of it. But I think it was my personal take that that idea got mired down in the syntax, kind of the DSL-ish of it. You know, we had that initially with RSpec. You know, RSpec is essentially a DSL for writing your tests. And the idea is you can read them more like you could read English. And then, like any good idea in Ruby, we had 18 zillion more ways to do it. And, again, what's interesting here is that these all become nice competitors to each other. And they start to push back on RSpec. You know, if you talk to, I talk to Slumsky a lot because, oh, I forgot to add this on here. Brian's going to kill me. Rubinius has its own, right, that Brian Ford wrote because we couldn't load in RSpec because he used all these really big features that we couldn't implement originally. And so what's fun is that, you know, Dave is aware of all these in ASLAC. In fact, Cucumber is ASLAC's rewriting of RSpec, the story runner we just found out. As this is, you know, like he did this earlier this month or earlier in August. So it's fun because people take these ideas and they push back. They're kind of, they're not really willing to take the status quo. And Ruby gives them such expressiveness. They feel like they can actually do something like that. You don't really see like a big competitor to spring jump out there. That was a nice plan where I guess no one got that. But that's okay. But I think it's fun because we're also, feel like we're so expressive about how we're doing things and we all feel so empowered to write these that we see this kind of ballooning of ideas when someone has something nice, oh, we can do that too. You know, we see that with Rails and Merb and all the smaller frameworks. You know, Merb came, you know, Nitro was before Merb. You know, this nice kind of cascading of ideas that we see in projects, you know. And of course with every good thing, you know, we see an aspect backlash that evidently is going on now. And that's just, that's natural. That's part of this process of how we figure out what works for most of us. There's always going to be those outliers who want to continue to kind of scurry amongst and try new things, but that's fine. Those are the people that cause a churn of innovation inside the community. So there's this one. That metaprogramming is cool. It will get you chicks. I shit you not. I swear I've heard that before. And it is, it's very cool. You can take it too far. Don't forget that. You can definitely take metaprogramming too far. If you need to add five methods that return numbers, it's better to write five methods that iterate over an array and call define method that returns a number. Trust me. Don't forget that you can't comment metaprogramming methods very well. It's very difficult to get our doc to run on them. But what happens invariably is that, you know, this old quote, when all you have is a hammer, everything looks like a nail. So every time you come up across things, some people are like, I got a metaprogramming this right here. I'm going to need to do 18 zillion things in the future. Right now I need to do one though. I know I will need to do 18 zillion later. I better write an entire metaprogramming framework to fit this returning my age. But... So I was told I need to have a moral of the story. I spelled that right. Is that spelled right? Okay. I think the moral of the story is that this community loves to have a lot of fun. And we like to poke each other and to egg each other on. Ow, I could do that better than you could. No, you can't. And then the ensuing kind of, you know, dust, a dust-up about what can be done. You know, and people say very friendly though, you know, amongst the dust-up about, oh, that's stupid, you should do it this way. People stay pretty friendly, which I love. The other big thing that, you know, I tried to make a theme of this is this idea of agile. It's overused. I meant it, you know, it's an overused word at this point. Hell, this could be a meme unto itself, obviously. But the Ruby community ends up being very light on its feet in the original agile sense, is that we're never really bogged down if someone comes up, someone in this room comes up with a good idea to get a good blog post. Someone influential in the community starts to do it too. I bet you could easily see a wildfire spread and everybody knows about it and everybody's adding that to their project just in the blink of an eye. I absolutely love that. Who doesn't like that? And that would be the enterprise. They call our adoption of new technologies and new ways of thinking, they call that dangerous because it's really, it's unable to scale. If everybody is changing their mind every other week, how are we going to hire new people to do what they're going to do? You know what I call it? Fucking awesome. And that's it. And that's all I have. So I hope you felt enlightened by my little trip down memory lane. And, I mean, this is, if you have, I don't know how you have questions. I mean, I actually can take, if you've got questions. You've got comments at this point, right? Got a comment? Go for it. Okay, okay. Hit me. RPA, yeah. So the... Yeah, you want me to rehash the whole... I'd have to go back and look for the threads. Yeah, exactly, yeah. I mean, by and large, they've boiled down to very similar ideas. They really, they didn't diverge too much in the actual how they were supposed to be implemented. I have to go look. But I think RPA was built... I'm going to forget here. But they had such subtle differences that people didn't really... they didn't really see a difference between them. And kind of what happened was RubyGemt had a more influential base, shall I say, behind them. They had Chad, they had a lot of people saying, let's do RubyGems. We saw the upstart of Rubyforge, which was really the catalyst with which RubyGems became big. Because for the first time, with Rubyforge coming online, there was a place to put your gems. That was always the big question, right? The big thing about CPAN was always that, oh, well, there's a bajillion CPAN mirrors and you can download a package from any continent in any city if you really feel like it. Whether or not people use that, it's all in the air, right? And so Rubyforge kind of culminated and people started using gems and I think it kind of just worked itself out. I mean, I think... Yeah, the differences are pretty minor. So, anyone else? Okay. Well, thank you.