 had the pleasure since the year 2001 of not only organizing these conferences with my colleagues here, but of also working with our next speaker. I think that I can actually attribute a lot of what I've done in the last 10 years to the relationship that I have with Dave Thomas, specifically because I think it was RubyConf itself that got all of it started for me. And I think it was August of 2001. We had the conference in October of 2001. Someone had been organizing it, a guy named Guy Hearst, and life got in the way. And RubyConf, the first one, was in jeopardy of not actually happening. So we were on IRC. There were 12 of us on IRC and Ruby laying at the time. And Dave Thomas, private message me and David Black, and invited us to join a channel called RubyConf. So there are now three people in the RubyConf channel. And he said, this is really important. We can't let this die. We have to make this happen. And so we did. And it was because Dave kind of made us do it. He supported and encouraged us. And so the first RubyConf conference was actually co-organized by me, David Black, and Dave Thomas. The opening remarks at the first Ruby conference were given by Dave Thomas. And so we decided that for this conference, as a special 10th commemorative edition, it would make sense for Dave to do the opening remarks again. So please welcome Dave Thomas. This is typical, right? Software conference, supposed to start speaking at 9.15 and it's now 9.30. So we're going to start late and probably finish late. 10 years. 10 years is absolutely amazing. Sometimes it feels like, you know, a couple of months. Sometimes it feels like 100 years. But through that time, I've never stopped having fun. And that's absolutely amazing. And one of the reasons for that is the people that we've been involved with. And people it's going to sound like terrible, like log rolling, but people like Chad and Rich and Mike, Nicole and James, everybody else, absolutely amazing. And I really appreciate it. But it also happens that today is, well, back in 1918, on November the 11th, the 11th day of the 11th month, at 11 o'clock, they signed the Armistice, which was a temporary ceasefire between Germany and basically England and the rest in Europe, which ended the First World War. And since then, we've actually celebrated First Armistice Day and now Veterans Day on November the 11th. I'm talking about giving thanks to people. And as we're all gathered in one place for the only time today, I would very much like to do that. Could I ask people here who are active or ex active or reserve in any of the armed forces, please to stand up? Come on. I just want to... So those of you who stood, if you can, on your badges today, right in what branch of the service you served or serve in, everyone else look for those badges and walk up and shake hands and say thank you. Good idea. Thanks. So Chad said come along and talk to the conference and I said okay, but what do you want to talk about? And, you know, it's the 10th conference you would think that we need to talk about the history and everything else. And Chad said, no, just basically talk about what's in your head. And it turns out I can actually do that. This was actually taken almost exactly 13 years ago to the day. I had a sinus infection. And it wouldn't go away, so they did a CAT scan and that revealed something. So I went in for an MRI, which is kind of cool. So this is an MRI of the front of my head. The big white things obviously are my eyeballs. You got my nose in the middle. You can just about see my jaw at the bottom there. It's kind of fun because they do like slices this way and that way and all kinds of ways. So you can go back through my head. So here we go back just a little bit more just the back of my eyes, everything else. I kind of got like this sort of Darth Vader thing going on, which is fun. Go back just a little bit more. Now I turn from Darth Vader into that kind of alien thing in Predator, right? The guy with the, which is also kind of fun. You keep going back a little bit more. This is kind of like round about here. Just about our interest. Any doctors in the house? Okay. Because there's something a bit weird on this. If you go back a little bit further, it gets more obvious. Because remember my eyeballs were white. My eyeballs were white because they're filled with fluid and that's the way the MRI resolves fluid. You may notice there's a kind of asymmetry here. There's that thing in the middle of my brain. It turns out that I have something called an arachnoid cyst, which is the membrane around my brain kind of went the wrong way. And it kind of bulged into where my brain could be and my brain didn't grow there. So I am actually missing the majority of my left temporal lobe, which is kind of freaky when you first discover it. Part of my brain is missing. I asked the doctors, they wouldn't do it. If they'd be really cool if they'd put a door or something in there because I could store my keys and things, but no, they wouldn't. So they were kind of surprised to discover that I had this big hole in my head. Because they basically, so I said to them, was this like something that's growing? And they said, no, because you've had this all your life. It's perfectly normal, not normal, but it's perfectly stable. And I said, well, how do you know that? And they said, because if it developed after you were an infant, you wouldn't be functioning. But as your brain is elastic, when you're young, you're basically compensated for the fact that you're missing this big chunk, which is kind of fun. But they then said, but you know, we want to do some tests. Because why not? So they sent me down for a bunch of functional tests. So they tested things like, you know, my spatial coordination and blah, blah, blah. It's kind of like a three day IQ test. And it turns out that most of my brain is almost my functioning is absolutely fine. So like all the spatial stuff, all the word recognition also sounds absolutely fine. And in fact, they gave this little histogram of all my scores across all the different ranges, and it goes down, down, down, down, until it gets to one. My memory, or more accurately, my free recall memory doesn't exist. On their tests, I was like, you know, 90s, 90s, 90s, 90s, 93. For memory. And that explains a lot because I've always had this really, really weird memory. You know, people would say, you know, what were you doing last week, I could not remember. But if someone said to me, like, you were, you know, do you remember when you were doing this, then I could normally fill in the blanks. So memory was in there, I just couldn't get to it. And it turns out that's because I'm missing this little hole in my head. It also explains why I've got this really you may have noticed that if you're talking to me in a crowd, I quite often just sit there and nod. It's because I can't hear you. I don't have this thing called cocktail party effect. Because that's audio separation is done in there as well. And I don't have that. So I actually cannot hear distinguished voices if there's more than one voice going on at the same time, which is kind of fun. Good excuse just to sit there and zone out. So because of this, I am exactly the wrong person to give any kind of opening historical remarks. Fortunately, though, I work in an industry with revision control. So I can give some historical stuff. And that's what I'm going to do. I'm gonna go through just real quickly kind of very personal, what I've been doing for the last 10 years because what I've been doing for the last 10 years apart from the book stuff and the consulting stuff is pretty much predicated on my Ruby life. And so I'll just go through that real quickly, show you some stuff. And then second part of the talk, I need to do my normal harangue the audience act. So in the last 10 years, I first came to Ruby in 1999, it might have been the end of 98. But I think it was 99, who can tell. And I came to Ruby because I was one of these people that loved programming languages. And I used to download all these programming languages and try them out. And normally they wouldn't last more than an hour or two. Ruby lasted a day, I phoned Andy and said, this is really, really cool. You need to play with it. And we got play with it. I haven't stopped playing ever since. Back then, if you typed Ruby minus V, it would say Ruby 1.4. How many people here have used Ruby 1.4? Matt has Chad has Ruby 1.4 was sweet. Right. It was minute. You can actually get your brain around it. It was like, you know, the download was like, I don't know, 107 bytes or something. It was a really, really small bit of source. But of course, that didn't last. But it doesn't matter because we loved Ruby. Now, at this point, we just finished writing Pragmatic Programmer and we were about to write a book on executable specification, the idea of writing something that specified the problem you're trying to solve and actually then run it to verify that it did what you thought it would do. Kind of like what aspect Cucumber have become, but with a different emphasis. And Ruby was the language. You're going to do it then. And we were going to write a book about it. And we started writing this book and we discovered that we had to keep explaining what we were doing in Ruby. So we started producing this little website of what is Ruby to kind of as collateral for the book. And it turns out that that got bigger than the book and was more interesting in the book. So we started putting that together in the book. Of course, just to make things interesting for us, Matt goes and releases Ruby 1.6 in 2000. But that was okay. It was still fairly small. And out of that came the first edition of programming Ruby. The first edition of programming Ruby, if you haven't seen it, is about half the thickness of the current one. Part of that's because the libraries are smaller, part of it's because it doesn't cover as much stuff. It doesn't have like meta programming and stuff in there. It doesn't have testing. But it was still out there. This book absolutely totally flopped. At the time there were probably, this room would probably represent the people doing Ruby in the US at that point. It really wasn't a big, big deal. But it still was a very satisfying book to get out. Just some numbers. At that point, the core of Ruby, if you downloaded Ruby, you got roughly 960 methods in 69 built-in classes. So it wasn't small, but it wasn't big. So one of the things we really wanted to do was to get Ruby out there, get it more popular. We convinced Addison Wesley to let us release the book in HTML form. So I spent a couple of months converting it from LaTeX, which is what it's written in, into HTML. And we put it out there, and you can go find that on like Ruby Doc and everywhere else now, which is kind of fun. The other thing, though, was in order to write the method reference, I actually had to go through the source code line by line and work out what every single method did. So probably for a time there, I was probably second to maths in terms of my understanding of what actually happened inside the interpreter, because I had to read the whole damn thing to understand it. And I thought, I don't want to do that again. So I tried an experiment in social engineering. What I did was I went through the interpreter source, and I took all of the documentation that I'd written for the book and put it into the interpreter source in a different format. The format I called RDoc for my Java doc, it was Ruby doc, called it RDoc. And the intent was that if I put the comments in there, and if those comments were useful and up to date, then when people made changes to the interpreter, they'd also update the comments. And that way, I wouldn't have to do it again in future. It took about two, three months to go through and type all this lot in, but when I finished, I think I had every single method documented inside the interpreter, both in the C code and also in the Ruby libraries. So this is from fine, for example. I also had to write the tools to extract this, and this is where I'm going to sort of like reveal all. RDoc was a, as I said, it was a social experiment. And as such, I think it's worked. I think now it's unusual to find people writing Ruby code that they don't document with comments. You expect to be able to find the API online somewhere in whatever format it is. That's actually great. I really appreciate it. Plus, the core team, the Ruby core team, are now documenting all of their methods using RDoc. And it's great, right? It's in there, and it means that whenever you get a new release of Ruby, you're getting up to date documentation with it. Here's the secret. The actual RDoc program and the RI program that go with it are total and absolute crap. I wrote those as quickly as I could. I just basically messed around with the Ruby parser that was built into IRB and sort of hacked that so I could do the source code. It was an abomination. It was really, really bad. The only reason I did it was because I really needed something to get these comments and to explain to show people how it was useful, right? It would be actually usable in the field. And I've been waiting for years for someone to actually work out that that particular emperor had no clothes and to rewrite RDoc and IRB. And I know Eric has a talk coming up immediately after this one on his work on that. He's actually taken on that challenge. What he's doing is incrementally improving what's there, which I think is a very brave thing to do. But I really appreciate that because it desperately needs doing. But I'm still very pleased to the fact that RDoc actually has survived and is actually doing what it's supposed to do. So after writing the book and doing the RDoc and HTML, we've been writing books then for about three years. We were broke. So I went and got some work. And the next thing I worked on was a web app. This is in 2003. It's a web app called Dion. It's for a schools program called Destination Imagination. And I went back and looked at this. I checked it out of version control. I haven't seen it for like five years. So I went through and had a look at it. And I was kind of surprised, I have to say. Any directory tree that's dumped out of TextMate looks like any other directory tree. But it's still interesting that I have like an app directory, a DB directory. BO is Business Objects, which is kind of like my model directory. There's quite a lot of sort of common things in there. It's a fairly big project. 36,000 lines of code, 44 models, 100 something controllers. But the fun thing is, if you look inside it, you see some wild stuff. So here, for example, is a database table definition. Does that look familiar? It's, I mean, there's only so many ways of doing this. So it's really not surprising that it does look familiar. But there's some interesting stuff in there. For example, I chose to encode the lengths of fields as a parameter to the type. So I'd say varchar 100 as opposed to string lidesk comma length as 100. It doesn't matter. I mean, it's the same concept. That's kind of fun. I even had things called migrations. I had controllers that subclassed application. Again, not really, you know, rocket science. Something that was interesting, I still don't know if this is a good idea. I came across this, like I said, I'd forgotten I'd done this. And it's kind of like, oh, not too sure. If you defined an inner class inside your controller called app data, then the system would automatically persist that between requests so that you would actually have effectively accession related data per controller that was stored. And that makes your controllers look a little bit different to a Rails controller. I don't know if I like that or not in retrospect. It was kind of a fun idea. My actions in my controllers are a little bit different to Rails ones, but it was kind of like the same kind of idea. So this is like in Rails you'd have edit and update as the two actions. Here I have edit product in the product controller. So I go and fetch my product out of the data. I add some, I create a hash of options. I add that into the display hash for that product. And then rather than calling render, I call standard page. And then the equivalent of the update method is called handle edit product. And if you ignore some of the housekeeping, it looks pretty much the same as it would look nowadays in a Rails application. Which is kind of cool. I'm not saying this is actually clearly a lot, lot worse than anything that you do now. But it's just kind of interesting the way that the function that you need and the constraints that you're working under on a web application kind of drive the design. And it's interesting how you can have parallel paths arriving at kind of the same point. So skipping forward a little bit more. My life had become too easy and too sweet. So Max decides to mess it up by releasing Ruby 1.8. Ruby 1.8 was a big, big change. A whole bunch of new stuff came along. If you look in terms of method accounts, we went from around about the 900 mark, 800 and something in Ruby 1.4. Now we're up to 1140. Some new built-in classes. It got a lot bigger. What was worse from my point of view is we also now knew how to use Ruby a lot better. And so the book had a whole bunch more crap in it based on how we now use Ruby. So the page count went from being a fairly manageable 860 up to something like 960. Which is kind of scary. But that's okay. We got the book out in 2004, 2005, around about that time. And everything was absolutely wonderful. Until this happened. Some little upstart from Denmark put this video online on how to build a blog in 10 minutes. And the world changed. Ruby went from being a nice little niche language to being a language you wrote Rails apps in. And suddenly a whole bunch of new people came along. And I was really excited because Rails was a really great way of solving a problem that we all had. So I thought that was really cool. Looking back this almost looks quaint. Notice they hasn't got migrations or anything. And he's using scaffolding, which, you know, dynamic scaffolding. So there we go. The entire thing in 40 seconds. Why is that video only 40 seconds long and the original is nine minutes and 47 seconds? Well, what I had to do is I had to take out all the little subliminal messages, the intermediate frames, where he says things like Rails is cool. Use Rails. Yeah. Like my haircut. All of that kind of stuff. All of that stuff came out, you know, left with this. So that's it. So obviously Rails changed Ruby, or it changed the Ruby community. It brought a whole lot of people into it. If you actually have a look at the graph of even just book sales, it goes from this and then accelerates off like a jet taking off. I loved Rails. I think it's a very, very, I still think it's a very cool way of doing web apps. So of course we have to write a book on it. And of course the original book was that thing, really easy to write. Also around about this time, Mike Clarke, Nicole Clarke, started Pragmatic Studio. So Chad and I and Mike coming out there, helping people pick up Ruby, pick up Rails. To date, we've done about sixteen hundred students have been through the studios and hundreds more have attended conferences. So that's been fun. And of course David, not to be outdone by Matt's, starts revving Rails. And I'm sitting there busy trying to do catch-up. The only reason I'm really showing this cover is that, do you find this cover offensive? I got the weirdest email set from about this cover. We released it as a beta book and I get this email from someone saying, is it possible to order one without the terrible new cover? I'm not too sure who's that supposed to attract twelve-year-old girls that are into boys and professional web development. If I need to, I suppose I can Photoshop the cover of the first book on and glue it on so I won't be quite so embarrassed. Then I sort of come back with some kind of like don't worry about it. He comes back with another email. Personally, I think the cover with some pink unicorns and hearts would be perfect to attract twelve year-old girls. Then it gets creepy. Others get a distinctly, yeah, others get a distinctly Nambo, Dambla vibe from it. Well, you know, I'm so damn naive I have to go knock up Nambla. For the rest of you naive people, it stands for the North American Man Boy Love Association. This was the subject of much discussion over dinner that night with my wife. Then it gets creepier. We get another email about two days later from some totally different person. I wanted to thank you for the great cover on agile web development with Rails. I don't even program, but when I saw those legs I just had to have it. Well, long story short, a few of my friends got together to make a tribute. Could you please pass this on to legs for me? And there was a link. And the link was to a page that contained copies of the covers of the book with softcore gay porn on it. So my wife gets a little bit, you know, incensed and does the old Google bit. Turns out the two people that sent me the emails actually both lived in the same place on the east coast and now both live in the same place on the west coast and they're friends of each other on LinkedIn and everything else. So this is kind of like a little bit creepy. But just to let you know, this is the kind of stuff that can happen. One of the best pieces of advice that Alison Wesley gave us when we first wrote the book is never use your real address. And now I see why. What else happened around that time? Well, we actually developed our online store. This is a Rails application. Obviously it's about 60,000 lines of code. It was initially developed with Mike Clark and myself. And since then we've had Michael Kosciowski working on it and more recently James Edward Gray's second is working on it. This is really cool. It runs our entire business. I mean basically everything. You see the store side of this. Behind the covers it's doing the catalogue stuff, the sales stuff. It's interfacing out to the back end systems like Amazon and stuff. It does stock control, international rights. It's a cool system and it's changing all the time. So we would not have been able to do that without Ruby and Rails. I hate to think how big this would have been as a Java app or something like that. Moving forward, 2007, Ruby 1.9 comes out. I was really excited because Ruby 1.9 had a whole bunch of really cool new features in it. The sad thing is it kind of fizzled. And I think it fizzled because although the language is ready, the language is absolutely rock solid, the libraries weren't. The chances of you being able to take your existing application and just install the gems that you needed that would work on the Ruby 1.9 was pretty much zero. And because you didn't have the libraries and the gems that you needed, you wouldn't be able to use this. So it was a bit of a toy. And that's been really upsetting because it's such a great, great Ruby. However, that situation has changed. This, again, more stats because guess what? We have yet more growth. We're now to about 1,370 methods and 10 new classes. A lot of that has to do with the new encoding support, the multinationalization support that's built into it. Anyway, over the last two, three years, people have been working like crazy to get Ruby 1.9 usable in terms of libraries and everything else. And this August matched released Ruby 1.9.2. And at the risk of sounding like Steve Jobs, it's the best Ruby ever. I am absolutely serious. I mean, I know Chad's been using this this year. I've been using this as my exclusive Ruby all year. I've not had any problems. It is gorgeous. Absolutely. How many people here are using 1.9.2 as their main Ruby? Okay, about maybe a quarter, a third. If you're not using it, please, please switch across. It really is pretty painless. You'll find it's such a gorgeous experience. It's faster. It's way more capable. The regular expression support is great. The new enumeration stuff is unbelievably useful. They'll change the way you program. So please switch across to do it. So to kind of support that, we've got a new version of the Ruby book out. Hey, that is now supporting Ruby 1.9.2. Some stats, yet more methods, yet more classes, actually no more pages in the book, which is nice. But here's the wild thing. While I was typing this graph in, I actually did a quick regression on the number of methods and found something really wild. This is the number of methods in the Ruby interpreter. It actually fits a polynomial growth, not just like it fits it. It fits it almost perfectly. Like it fits it so perfectly. This is a science experiment. You get arrested for faking your results. The R squared is .99987 or something stupid like that. It's almost impossibly accurate. Maths could not have done more accurately if you'd tried. Add one more method and it would be worse. But the nice thing about this is we can now predict ahead and we'll know that the next version of Ruby has almost exactly 2000 methods in it and the one after that will have close to 2500. God help us. Anyway, just like a little bit of, I really, really want people to use Ruby 1.9. So like I said, today we're actually releasing the 1.9.2 version of programming Ruby. It's available in paper and PDF form. But I've been beaten up over the last year because all of our other books are in EPUB and mobile format so you can read it on your Kindle or your iPad. So I spent the last three months retyping the book from LaTeX into our production system so now the book's available in Moby and EPUB format. And if you read it on iBooks, you'll find there's an Easter egg in the reference section. It's kind of cool. If you already have the electronic version of the book then this is just a free upgrade because it's counted as a new printing not a new addition. So at some point this morning we're going to switch this on and you'll just be able to download it. Do not do it over the conference network please. But like I say I really really want people to use Ruby 1.9. I really want to give some kind of incentive for people to do that. So what we decided to do is we're now going to sell the paper book and the PDF for ten bucks. So I may well be taking a collection outside on the last day. That's going to be while the first printing lasts. But we'll see how it goes. Like I say, if you don't, I really wish that I put a submission for a talk into here on why I love Ruby 1.9. Because there are so many good things about it. You really should look at it. It's so cool. All right. So that's where we are now. What's going to happen in the future? I have no idea. I have no idea. If I can't remember the past I most definitely can't remember the future. But I'd like to spend some time just setting out a few challenges. Three challenges in particular that I'd like to give to you all. The first one, I call inspire somebody. It's not going to look like I'm talking about inspiring someone for the first few slides. Bear with me. I am. Because it starts out with this slide. I hope you can actually see that. The Bureau of Labor Statistics goes out in polls to find out what's happening in the real world. And it turns out that in 2009, out of the working population, roughly 47% of the working population of this country are women. They then break it down per industry. And the industry that we're in is computing and mathematics. In computing and mathematics, only 25% or roughly half the population norm are women. This is not great. But weight, as they say, there's more. Kelly was kind enough to do some analysis of this conference. If you look at this conference, 5.6% of the attendees are women. So out of a population of 25%, then roughly a fifth of those would be here. If we were a population norm, there would be five times as many women in this conference. And that's sad. It's shocking. But it's not as shocking as the next number. Because if you look at open source in general, Floss is the European free slash Libre open source. This data comes from a report that European Union commissioned on open source software. It's called Floss Pulse, which is a ridiculous name, free Libre open source software policy survey. And they came up with the fact that in open source, there is only a 1.5% participation rate by women. So if you look across the board, you have 47% in the working population. You have 25% in software and mathematics. Down to 5%, 5.6% here, down to 1.5% across the board. So I want to address that. To address that, you've got to find out why it happens. And clearly there's two things that are happening here. First of all, there's this population change from 47% to 25% taking place and people actually entering the industry. And then you have this problem that of that 25%, only 1 in 5 cares to come to a conference like this. Why is it? Well, the Floss Pulse survey has a whole bunch of reasoning behind it. They talk about implicit pressure during your teenage years. The old girls don't do this pressure from teachers and this kind of thing. There's this perception, which is probably not necessarily an untrue one, that software is lonely. The cube farms with people just sitting there with their headphones on, coding away. And there's also this fact that now that we're here, it's actually kind of like a de facto male dominated. It's not necessarily an attractive industry to enter. Interestingly, it wasn't always that way. Sarah Allen pointed out to me that the original ENIAC programmers were mostly women. Grace Hopper wrote the first compiler. It's just over the years, it's changed a way. The survey has some interesting, if hard to read conclusions. Women are actively, if unconsciously, excluded rather than passionately disinterested. The effect lies within the Floss cultural and social arrangements. My bold, the exclusion happens among people who do not mean to appear and who do not interpret their own actions as hostile to women. They also talk about this hacker ethic. The idea that we're cool, we can control the universe. We're hackers. But to us, it's almost like us versus the mainstream. We're different. And to us, women are part of the mainstream. And so quite often when women are introduced, if you like, to projects, it's almost as they said here, they become the carriers of sociality. They bring the outside in. They're not part of the community. And as a result, we tend to kind of let ourselves go a bit. There's a whole bunch of inflammatory talk, inflammatory presentations. There's, I actually had some websites on here that I took down because I didn't want my picture appearing with the website thing. There's websites like Testically, right, which is a PHP website. Grabbing PHP by the balls is the actual thing on it, which is like, you know, maybe you feel a bit uncomfortable, maybe you don't. But maybe if you're a woman, you do. Right. How would you feel working on a project called vagina? So there's stuff we can do. Is it a problem? Well, regarding the open source community as a whole, have you ever observed discriminative behavior? The audience, the 21% of the audience said yes, 75% said no. Looks pretty good until you realize that's what happens if you ask the men. If you ask the women, it's almost exactly the opposite. So my takeaway from this is, first of all, the Ruby community is not in a bad position. I think we actually do better than most when we have our mistakes. But I think we do better than most. But the problem is, even if we're well intentioned about it, we don't always know that we're doing it. So one of the things I would like to do is to try and change that to try and put a little bit more self awareness into all the little things that we do so that we don't drive women away. Possibly a test is when you're thinking about what someone's doing or what you're doing, rather than casting it as male female, cast it as black white, because we've all been kind of like trained as the wrong word. We have better empathy, better sympathy for that particular situation. So someone puts up a slide deck to talk about, I don't know, background worker processes and shows pictures of slavery. Maybe you'd go, not quite right. Yeah, if I talk about priority cues and show segregated bathrooms, you know, blacks, whites, you'd probably go, that's not quite right. It's exactly the same thing applies. And what I'd like you to do is to start thinking that way. And then if you do find something offensive, if something starts triggering that little spidey sense, do something about it. If you're in a talk and it's offensive, stand up and get out or blog about it and say, that was ridiculous. I'm not going to go to that. Tweet the guy into the oblivion. Please react, not just sit there and passively accept. Because by reacting, you're saying, yeah, it happened, but you know what? We're not going to let it happen again. So that maybe will take the 5% and move it closer towards the 25%. But what are we going to do about the 25%, about the long term, the picture that we're not getting women into software. And that's ridiculous waste in so many levels. Well, here I'd like to make a suggestion. I think what we need to be doing in general, in the software industry in general, is be talking more to kids. Fewer and fewer people are entering software as a profession. And fewer and fewer of those people are women. So I think mentoring is a really important part of what we do. There's a really great example from a guy called Scott Thompson who actually lives down my way in Dallas. He got involved in something called the Girls Engineering Club. It was a club that was started at his girl's school. I believe they're at about 10 years old, something like that. And he was drafted in to teach these girls programming as part of their engineering. And so they all turned up at someone's house and they carried in a whole bunch of, you know, old equipment and set up in a kitchen table. And he wrote a blog post about it, which I strongly recommend you go read at some point. In the middle of that blog post, he said, using shared screens and my iPad as a presentation controller, I walked the girls through the keynote presentation about some of the basic concepts of software engineering. Then we fired up Ruby in IRB and I showed the girls how to work with numbers, variables, and simple control structures in Ruby. They had to sit three to a computer, but that also let them help each other out. They learned to use loops to print out silly things about me. For example, I had the computer print out Mr. Thompson rocks and the girls felt they absolutely must get their computer to print Mr. Thompson, certainly not rock a thousand times. There was an awful lot of giggling, but as a teacher, I was proud to see them pick up the basic concepts and apply them to their own goals. My favorite exclamation was, wow, I could use this to help me do my homework. At the end of the article, he says this, with the girls engineering club, I got to experience a little of that joy of discovery once again. The price was a little elbow grease, some careful thought, and a bit of my time. It was absolutely a bargain. I agree there is nothing cooler than teaching kids. And so one of the challenges I'd like to set for all of us is to go out and inspire people, inspire a new generation of people who will come along to software. And why am I saying this at a Ruby conference? Well, the answer lies in cosmology. This is a really accurate and really horrible picture. I prefer the one from the Planck project that says, during the beginning of the universe, 10 to the minus 33-ish seconds or so, it underwent something called inflation, which is actually a phase change. In the same way that, for example, water turns into steam. It's a change of state. The same thing happened to the universe. And in the same way that steam is something like 1,000 times less dense than water, it expands as you heat it up. The universe expanded, expanded unbelievably in less time than exists. I mean, from a phenomenally short length of time, the universe expanded. And what happened is during that expansion, the universe was basically homogenous, but there were quantum fluctuations in that goo, in that foam. During the expansion, those fluctuations effectively got frozen. They got far enough apart that they couldn't kind of blend back together again. And it was those quantum fluctuations in the initial foam of the universe that they now believe led to galaxies. Just little deviations from regular uniformity eventually created the galaxies that we live in. The same thing applies now, I think. Ruby is now no longer a little niche thing. Ruby is now an industry. It's a standard. We are growing. We are growing phenomenally. When we do the studios, it used to be that people who came along were hobbyists. Now the people who come along are being sent by their companies. Ruby is growing and growing and growing. So in the same way that small changes at the beginning of the universe lead to galaxies later on, I think that the changes that we make today, the small changes that we make today, can lead to major changes in the industry for everybody down the road. And so I really would like to encourage you to go find someone to inspire. And here's Sarah. It's talked again to Sarah Allen about this. And she tacked on, I love this. Find someone to inspire who's not like you. Go for it. Second challenge, diversify. Now here I'm not talking about the composition of our audience. I'm talking about yourself. The cheetah. There are about 10,000 cheetahs left in the world, which is kind of sad. One of the reasons that there's not that many, apart from mankind, is that sometime, a few thousand years ago, one particular mating pair of cheetahs became effectively the Adam and Eve for all current cheetahs. And what that means is that all current cheetahs are effectively clones. They actually share almost identical genes. So when cheetahs breed, basically the only surprise they're going to get is boy cheetah or girl cheetah. He looks just like his father. It's guaranteed because there are no other genes. You're not suddenly going to get a white cheetah or a redheaded cheetah out of that genetics. Technically it's called homozygous. The two genes that go to a loci are always going to be the same. And that leaves cheetahs susceptible to disease. It means, but significantly, they cannot evolve based on reproduction. The only evolution you're going to see is based on mutation. So it's a very, very fragile existence. Now, in the software world, we have exactly the same thing. We call them Java programmers. Or we call them C-sharp programmers. Actually, no. Let me be accurate. They call themselves Java programmers. They call themselves C-sharp programmers. And here's the bad secret. They call themselves Ruby programmers. Whenever somebody identifies themselves as I'm an XXX programmer, well, what they're saying is, I'm monolingual. I have one tool and I will use it, whatever. So if you look up monolingual in my dictionary, you get a couple of different things. Firstly, there's an unbelievable arrogance to saying, I know the right language. I know the right tool. Because you don't. But there's also a remarkable ignorance about it as well. Because with all due respect to Ruby, it's just a programming language. And if all you know is Ruby, then you don't know, for example, what it's like to do functional programming. You don't know what it's like to do logic-based horn clause programming. And if you don't know that, then you are not going to be writing programs well. Because you haven't got the experience to do so. There is another word for people who are monolingual. It appears a bit further down the road. But we call them maintenance programmers. Because eventually that's what you'll be. Because eventually everything moves on. The same applies, not just the language, but to everything. Anybody who just says, I know the way and this is the way I'm going to do it. I've just spent four years learning how to do this object stuff. I'm not going to change. Why should I throw that investment away? Those people are dying. Please don't become one of them. So my second challenge is to push yourself to learn. Learn a new language next year. Go for something which is different from your experience. If you've never done functional programming before, maybe do a Haskell or a Scala. If you haven't done a Lisp-like language, look at Clojure or Common Lisp. Just choose something different and learn it. But don't just sit there and read a book about it. Actually code in it. And code something significant. I put 3,000 lines. I have no idea what the number's supposed to be. But something which is actually big enough that you've got some experience at the end of it. And then ideally, ship it to someone. Because that way you get to see whether or not you've been an idiot. What's the risk of doing this? Well, people will argue the risk is, oh, I haven't got time to do that. Well, if you haven't got time to train yourself, then find a different industry. No, the real risk, I think, is that people say, I might like it. I might like it better than what I'm doing now. And I don't want to do that, because really I like Ruby, or I like Java, or I like C Shop. It's kind of scary to think that there may be something better out there. But you know what, if there is, take it. I do this, I keep coming back to Ruby. But I program Ruby differently because I do this. If you don't want to do that, we live in an industry which never looks back. I would strongly recommend that you should. Look at some of the original languages that got us to where we are right now. Simulow, the first object-oriented language, is a very, very cool language with a very weird syntax. But it's well worth learning, just to see how things could be. And Simulow has concepts that we don't have in modern programming languages. It's very cool. All but a bunch of languages there are just the suggestions. You can find them yourself as well. Find languages that maybe you haven't even heard of. And just look at them. Don't just do this with languages. Do it with everything. Try new things. Experiment. Because that way, you're introducing diversity into the gene pool. And that way, you can do this fitness function thing to say, does this work well for me? And that way, you can evolve. And that's what we're trying to do. So related to that is my last point. And that is, get out of the rut. I have used this slide, Chad tells me, on every single one of my RubyConf talks. I believe I used it on the very first talk. Back in 2000, the idea was that we were all pioneers. We were setting off into the unknown. We had no idea quite where we were going or what we were gonna do when we got there. We just knew that we had to do something. And so we were out there exploring. And after a while, everybody found somewhere that they liked being, or maybe the horse died or whatever it was, and they started forming little communities, little towns. So we'd have the web development town and the testing town, whatever it might be. And that was kinda cool. You had other people, and it was like you didn't have to get on the horse every day and ride. It was cool. And after a while, those towns started getting a bit fancier. More people came. There was a bit of specialization going on. We could have nicer things. And after a while, the popular towns started growing and growing and growing. And then, after a while, not everywhere, but some places, this started happening. Sorry the video's not so great. But we started seeing suburbs forming. Kinda taking over the land. They look almost like Petri dish things, right? They take over the lands around towns. And suburbs are kinda like the opposite of getting into your wagon and exploring. A dear, dear, kind, sweet, gentle man once wrote a wonderful blog post. I think he even mentioned me in it. It was wonderful. Well, if I was so inclined, I might write this. Or that's not fair. But I would definitely write that. I think Ruby is in danger of becoming suburban. What do I mean by that? Well, kinda cookie cutter. Everything tends to look like the next thing. And because of that, it's homogeneous. Not too many surprises are happening anymore. We used to have all these cool things that would pop out. And people go, that won't work. And then it becomes like the next big thing. That doesn't happen as much. And one of the reasons it doesn't happen is that once you get comfortable, you start getting judgmental. You start saying, well, that's not how we do things around here, son. And that stamps on innovation. If I stood up in front of you and said, don't bother with the testing anymore, I've decided it's crap, right? You go, oh, that day, if they can't do that, we always do testing. That's all we've always done stuff. That's the way the Ruby community does it, yeah? Because we don't even think anymore. We just have this cookie cutter thing going on. And then what happens is, once you get sitting in this rut, we have to do something to make it interesting so we invent all these complicated structures around it. And things become high ceremony. Nowadays, it's not uncommon when you start a new project to download 40, 50 gems just to get the thing off the ground. Everything has become a little bit more, I don't know, fancy than maybe it should be. To me, that means that things are becoming boring. One of the problems is that we have a whole bunch of incredibly smart people in this community. A lot of them are in this room, but across the entire Ruby community, so many brains. And so many of them are just spending their time fine-tuning other people's ideas. Why? Because they're smart enough to say, I could do that better. And you know what, they can. Absolutely, of course they can. It's always easier to refine something, it's always easier to do something better, but so what? So instead of saying, I could do X better, my third challenge is to start doing something new. And to make it an absolute challenge, do it worse, because that is where pioneering happens. Pioneering happens where people don't know that what they're doing is stupid, or what they're doing is dangerous. Pioneering happens where you don't have to be perfect, you just have to survive. Do it worse and do it new. And along the way, please remember that the whole reason we're doing it is to make it fun. And that's it. Thank you all, I had an amazing 10 years.