 as much. Thank you for coming to RumiConf 2003. It's nice to see a bigger crowd this year. In our first year in 2001, we had only 33 or so and last year maybe 50. Why are we here? We are here because Rumi is good enough for many of our tasks so we do not have to talk about that. So I'm going to talk about how Rumi sucks and how we can make it better. Rumi has these problems. For example, it's slow and inconsistent. How can we fix these? With a major version change from 1.0 to 2.0, this is the opportunity to take one big step and make changes that may not be backwards compatible. But we'll make Rumi better. To clarify, Rumi2 is the next version of the Rumi language and right is the virtual machine for Rumi2. The path we will take to Rumi2 depends on being free of 1.8 maintenance. Hopefully that will be soon. Then in 1.9, we will work on the syntax changes. I do not know what these changes will be yet, but there will be experiments. Once we know what the syntax will be, we can work on the implementation in right. Right will be vaporware for a long time, unfortunately. I am still waiting for Son Chi to finish right for me. So here's the long list of some things we might experiment with for Rumi2. For example, here's a way we could have keyword arguments. Here, a is positional, and the b argument is a keyword argument, and the word does not matter. You must use the keyword argument many, in this case b. If you specify it, but it will not, then if not, it will make some kind of error. But I have not decided what kind of error yet. This is the new hash-little syntax that we might have. That would be equivalent to the current syntax below. Maybe we can have method books that will let you add code to arbitrary methods to be run before or after. Death may return an object. I am not sure yet. If you try to add a pre-method to a method that does not exist, that will grow an error. Or maybe not. As you can see, I have undecided about many of these changes. I would like to help from you in the form of Ruby change requests for a time until about March 2004. These would be proposals asking if we could change Ruby in this way or that way. RCR should contain an abstract, motivation, proposal, and rationale. They can be big changes that would not be backwards compatible. I think I would reject most of them. But thinking about how to improve Ruby by many burdens is better than just one small burden. Thank you. Seeing that everything works. The only prerequisite to this is that you have Ruby on Rails and so you know. I can see that they know David Hennemier Hansen, that they want to be him. They want his fine of parenting out in the streets to get here, losing stuff. And there's a science behind this. It's incredibly thought out. I mean, wow. Foxes, you know, of all animals. Foxes that I use in the book I'm working on. And it's sort of reactionary work to try and do something that a technical book shouldn't do. The eyes of the foxes, round and blank. There's nothing there, right? What do you have to hold on to in a technical book, you know? What drives you to read it exactly? Is there personality there? Is there feeling? Is there humanism? Is there humanity in a technical manual? Not really. There shouldn't be. Their eyes should be blank. They shouldn't be staring. This is the one I like. You can't even see anything about him. He's always down there at the bottom. And that's supposed to be sort of frustrating. I know I don't have incredible things to teach in the book. I'm not an incredible programmer or anything like that. But I figure people will keep reading to see a little bit more of the short one. Let's change things around. So let's just talk about BVB or really, let's just talk about testing for us normal people. And the real thing I'm trying to get out to everyone here is that test calls like a tag. So the Bible says in the beginning and the beginning there was what? And after I got good at curl, I learned Java. Then I fell into testing and I thought I was doing real good here. There was a problem. I was running a bad brittle test. So then a couple of years ago, there was this little Danish guy, he looks like a cartoon character, came up with something called Ruby on Rails. And I can't use the logo because he says I can't. So with Ruby on Rails, we've got this whole little test directory. And I was still writing bad tests. But then my evolution began. And then around January of last year, some smart guys came up with ours about it. And I discovered it and was like, wow, this is hot. But I was still writing brutal tests with bumping syntax. And it wasn't helping anyone. So then I decided I wasn't ready to give up on our specs. And I studied and studied and studied. So coding this way isn't going to be, it's going to be uncomfortable. And there aren't instant benefits. But I don't care if you have a deadline. I don't care if it hurts. Write your tests first. TVB is a muscle. You have to exercise it. And really one rule you should get out of the top is, how soft what is that? As the stream moving on. Because every time I give a talk, I'm actually very nervous up here. And a friend of mine told me, when you're on stage, just think about what would frame or review. So I put this up here to mind myself things about that and called down. So today we're going to look at some tips for putting performance into Ruby code. So how did I get started with this? There's a feature I wanted to add to Rails for a very long time. And that is the paired statement caching. And we'll actually have that feature in Rails 3.1. In order to add this, a deeper understanding was required of ActiveRecord. So I started diving in and fixing bugs, going through the Lighthouse ticket tracker and fixing bugs in ActiveRecord. And I ran across one that said ActiveRecord is five times slower than in Rails 235. This is before Rails 3 was released, and you can go read up on the ticket here. And I thought to myself, five times slower? Really? Five times slower? How is that possible? I mean, it is possible. It really was five times slower. So I thought I was looking at this, and I thought, what could possibly go wrong? So motivation. Why do we care about speed? You all know that Ruby can't scale, and Rails can't scale, and yet we're all Ruby, that's right? As a tangent, I discovered the technique for scaling Ruby, and it goes like this. It's very simple, like this. Is that when you scale Java? It doesn't pixelate like this. You can buy bad code and exist and get rid of it. When should I make my code faster? You can answer this. When it isn't fast enough. Another question is, what is fast enough? Whenever I think about this, I think, well, do people notice it, and what are you comparing it to? In my mind, fast enough means that it finishes in a reasonable amount of time, and that is subjective. And really, I'm telling you all these things, but I don't want you to believe me. I want you to think critically, and go out and hope at the step, and analyze it for yourself. We need to reduce certain things. That they're called branching and looping, and we need to reduce objects. What I think is interesting is that the clean code, the things to reduce are exactly the same. So therefore, clean code equals performance code. The performance are making up much different, but you don't have yet to have the system knowledge to be able to make the difference. I learned, when should I rewrite? I see it like this. The earliest you should rewrite is when Ryan Davis says so, and the latest you should rewrite is when I say so. Arms are hard. Against the backdrop of 5,000 years of the creation of content and the control of information, it's time for your fortune. Brace yourself, because some of it is hard. Everything will change. Everything. As the generations in front of you disappear one by one, you will feel yourself taking the giant step forward in the mortality line. I know this to be your future, because it is my past. I got my first programming job in the spring of 1978. The first web browser, let's say, had appeared 15 years later, in the tune of 1993, and Ruby 0.9.5, released on December 21st, 1995. Now, a mere 20 years later, the internet is at the center of our lives. We live inside this bubble, so it's hard to remember that the job you have today appeared as suddenly as that of a limotype operator. When phototype setting arrived, these machines became worthless overnight. Newspapers got rid of them by throwing them out upper story windows into parking lots and having them hauled off or scrapped. So there you go. That's your future. It doesn't involve an unexpected inheritance or a tall dark stranger. Those, unfortunately, are edge cases. This is your real fortune, the one you share and comment with everyone in this room. You can think about it as being on the happy path of the app of your life. But here's the deal. In the arc of your life, these are the happy things. These are the things that you can depend on. This is the meta later that stands above everything else. If your life really were an app, you wouldn't ignore the inevitable. You'd be writing code for this right now. Accepting the truth of this fortune makes it clear what's important. The MPPs of the only app that mattered are health, happiness, and the world we leave our children. I want you to start working on this app right now. There's some low-hanging first. Happiness. Live as if you know you'll die. Do real things. Tell everyone you love them today. You might consider getting a little dog. Okay, you don't have to do anything dangerous. It's a rear-guard action. Believe me, I know, but go down fighting. Take breaks, get an ergonomic keyboard, stand up some while you work, get some exercise, get a bike, take walks, go to the gym. Believe me, you're going to want your body later. There are some parts of the apps you can work on by yourself, but some parts are better to work on together as a community. Our community is important and your place in it matters. You can contribute to open source, you can teach it that suits you. Showing up in small ways makes a big difference. We are uniquely qualified to do things for others. We're bigger than Rails and we're bigger than Ruby. We're members of the tribe of information and our lineage is that of scribes and type centers and line of type operators. From scrolls to codexes all the way to composing rooms, we carry the mantle of the open sources of information. My dad is now 80 and he happily works four days a week, two of them at the local food bank or he mows the lawn and does the books and stops the shelves and gets temporary loans from people whose electricity has been cut off. He tries to make sure people don't go hungry and despite his efforts they do. If you want to help, you can pitch in literally. I love Habitat for Humanity. They build houses. I am not a bit religious, but I love this mission. We all want to belong and we want to change the world and Habitat lets you do both those things. Why work with dangerous power tools? If you're not the nail-banging and sheet-rock hanging in time, I can tell you from personal experience that Habitat's volunteer management software sucks. As a matter of fact, I'm going to make a sweeping generalization, which I'm hoping you will not tweet. If they didn't make it, or if we didn't make it, it sucks. All these communities need help. I have always tempted to claim a fast, wind-assisted ride as my own accomplishment, as if I am that strong and I did it all myself. But I can't forget it, that if Doppelganger and me were out on the same day riding in the opposite direction, she would work just as hard but accomplish far less. We are here because we have done the work. I know that. We got into this trial by dent of our own efforts, but we also have been blown here by the twin-tail winds of chance and change. Having looked at the past, we can predict the future, change. And by an accident of timing, we stand at the vortex of that change, at the intersection of information and technology. Unlike many others, we are lucky enough to have choices. And the things we choose now will create the world everyone sees next. It challenge you. Choose something big. And I'm here to talk about friendly flying robots in Ruby. First, I want to talk a little bit about terminology. People often talk about these things as drones. I actually dislike that terminology because it breathes these things to mind. So I try not to use that word. So we're going to talk instead about flying robots. But when you program a drone in Ruby, they become friendly flying robots. When Skyman comes, wouldn't you rather it be programmed in Ruby? So I've written this library called Argus. And we're going to use it like creating a drone object here. Tell the drone to start up the background processes. Tell it to take off and hover about one meter, spin right, spin left, hover and land. Just a very simple, simple program. We're controlling the drone and totally not Carol's arm. I'm going to have a take off using a loop two times and make it swing back and forth. Take off, swing back and forth, and land. How about that? Two successful hardware demos. Oh my god, we should submit something. Well, it's even wearing my earrings. And I'm up here with two of my favorite people who are still hiding down here who are also holding puppets of themselves. This is an amazing moment. And we are so, so grateful to everyone that's made it possible, especially you, Brenna. I made this happen. For every hour of work I put in, she put in three. So please, everyone, just some thunders of applause for doing this. Some like this one are amazing. And most others are ordinary, measured by volume. But even those ordinary ones are pretty good. This is, as Sandy said, doing real things. It will keep us coming back to the keyboard and the frustration, the endless planning meetings and the ever-changing tech landscape. No, it's going to kill me. Jim, why are we going to pass away early this year as everybody knows and through putting on Steel City Ruby with Carol and a bunch of other people in Pittsburgh, I got to spend some time with Jim that I wouldn't have otherwise. We shared a meal or two. We shared some jokes. And one time we shared a song. Jim loved to play the ukuleles. That was a pretty cool moment in the hallway outside our first Steel City Ruby three years ago. There's a lot we didn't share though. We never shared code. We never shared ideas about code or the projects we were working on. We never shared a long cab ride to an airport or our favorite places to get brunch. I never got to share with them all the weird shit I made with rake. I guess what we're trying to say up here is that we want to share these moments with you. We don't want to miss another opportunity to let someone know the impact they've had on our lives. Maybe making a puppet that looks kind of like Aaron Patterson is kind of a weird way to do it. But we're standing on the shoulders of giants and many of them are pretty weird. So thank you again for giving us a place to hang our hats. Thank you for keeping it weird. Thank you for optimizing for developer happiness and for being nice because wants is nice. Thank you for all the pictures of your cats. Thank you for all the terrible puns. And thank you again for never forgetting to test all the fucking time.