 Thank you for coming to RooneyConf 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 Rooney 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 Rooney sucks and how we can make it better. Rooney 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 Rooney better. To clarify, Rooney 2 is the next version of the Rooney language, and Wright is the virtual machine for Rooney 2. The path we will take for Rooney 2 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 Wright. Wright will be vaporware for a long time, unfortunately. I am still waiting for Esonchi to finish Wright for me. So here's a long list of some things we might experiment with for Rooney 2. For example, here is 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, then, if not, it will make some kind of error, but I've not decided what kind of error yet. This is the new hash-voodle 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 we run before or after. Death may return an object. I'm 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 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 will reject most of them. But thinking about how to improve Ruby by many variants is better than just one small Ruby. Thank you. See, so in Ruby server. So, seeing that everything works, the only prerequisite to this is that you have Ruby on Rails install. I can see that they know data kind of by our hands that they want to be him. They want his fine apparel and his wades, you know. Got the streets to get here. There's a science behind this. It's incredibly thought out. I mean, wow, the 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 their 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 and see a little bit more of the short one. I like to 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 you test all the fucking time. So the Bible says in the beginning, and in the beginning there was what, a curl. Curl is what I knew. 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. He walked me 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 Archibald and I discovered it and was like, wow, this is hot. But I'm still writing brittle tests with bumping syntax and it wasn't helping anyone. So I give up on ArchBag and I study and study and study. So coding this way isn't 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 you're hurt. Write your tests first. TVD is a muscle and you have to exercise it. And really one rule that you should get out of the top is, how soft like is that? Stream RubyConf. I'm actually very nervous up here. And in front of mine told me, when you're on stage, just think about what would frame work for you. So I put this up here to remind myself things about that and call down. We're improving performance in Ruby code. By looking at things I used to improve the performance of A-Roll. So how did I get started with this? There's a feature I've 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'd look into 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. Very simple. Like this. Oh. Is that when you scale Java, it doesn't pixelate like this. When it's like this slow, you can find bad code in this 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 quickly and go out and look at the stuff and analyze it for yourself. For performance, 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 a much different, but you don't yet have the system knowledge to be able to make the difference. I've 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. 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 was said to appear 15 years later in the tune of 1993, and Ruby 0.9.5 was 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 the phototype setting arrived, these machines became worthless overnight. Newspapers got rid of them by throwing them out upper-story windows in their parking lots and having them hauled off the scrap. So there you go, that's your future. It doesn't involve an unexpected inheritance or a tall, dark strength. Those, unfortunately, are edge cases. This is your real fortune, the one you share in common with everyone in this room. You can think about it as being on a 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 now, 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 though you'll die. Do real things. Tell everyone you love them today. You might consider getting a little dog. No. 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 somewhere you can work, get some exercise, get a bike, take walks, go to the gym. Believe me, you're gonna want your body later. There's 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 Rouse 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 stocks the shelves and gets temporary loans from people whose electricity's 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 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 tended 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 Doppelkinger, we were out on the same day riding in the opposite direction, she would work just as hard but accomplish far less just as technical difficulties. 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're lucky enough to have choices. And the things we choose now will create the world everyone sees next. It challenge you. Choose something big. I'm Tim Wyrick, 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 frees 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 controlling the drone and totally not Carol's arm. I'm going to have a take off using the loop two times and it can swing back and forth. Take off, swing back and forth, and land. How about that? Two successful hardware demos. That, it sounds fun. Oh my God, we should do something. Well, what do we like? 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. You made this happen. For every hour of work I put in, she put in three. So please, everyone, just some thunderous applause. The difference with people is why we do this. Some like this one are amazing most others are ordinary, measured by line. But even those ordinary ones are pretty good. This is, as Sandy said, doing real things. It'll keep us coming back to the keyboard and the frustration, the endless planning meetings and the ever-changing tech landscape. No, it's gonna kill me. Jim, I already passed away early this year as everybody knows and through putting on Steel City Movie with Carol and a bunch of other people in Pittsburgh I got to spend some time with Jim but 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 on the hallway outside our first Steel City Movie 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 were 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 lots 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.