 So, a man that needs no introduction, David Heinmeyer Hanson. David, thank you again for taking time out of your day and answering questions for us. Okay, so. Sure. Where did Anthony go? I know. I can manage that. It's the only requirement that I stop browsing for 40 minutes and you have my underwrite in that queue. Right on. Alright. Anyone? Anyone? Okay. Well, I will ask a question then. I guess my first question would be, you know, we've read a lot of posts coming from both the Rails team and the Merb team. But ultimately, what was the, like the impetus? What was the impetus behind really bringing the two together? I think actually the run-up in, perhaps it's the right word, brought this on at some point. So, when the tension started really boiling back in December, it actually led us to start talking more to each other in some ways. Because we felt that the tension that was building just wasn't helpful at all. And in many ways, I thought that we were building false tension. We were fundamentally trying to do the same thing in the same way, which is evident from just how much of Merb and Rails is incredibly similar where you have almost exactly the same APIs. You have almost exactly the same goals being pursued. But that just, that led to a lot of duplication of work and led to a lot of tension in that it just felt like it was completely unnecessary. So, we started talking more to teams together and what we realized was that a lot of the tension was basically just built on the misconception that because Rails didn't necessarily do something about some of the things that the Merb guys cared about, it meant that we would never want that stuff in Rails. For example, the agnosticism that the Merb guys were really interested in pursuing was never something that was against the grain of Rails. We had one thing that we, and I had one thing that I truly cared about, which was sensible defaults and defaults for everything, that there should be one starting answer for everything in the framework. But that's not at all at odds with allowing people to take another answer if that's what they want. So, just because Rails ships would prototype, there should be absolutely no reason to discriminate against people who want to use jQuery. And I think just somehow, and that's certainly our fault and my fault and the fault of the Rails community in general, that that kind of mixed up, the fact that we have strong defaults that mixed up and conflated with the notion that prototype is the only way to do JavaScript or ActiveRecord is the only way to do ORM or whatever have you. And that's just not true at all. So, what we basically needed was just, we needed some champions. Somebody who really cared even about the agnosticism because, for example, they were using something else. They were using jQuery for JavaScript. They were using Datamab or SQL or whatever for the ORM. We just needed somebody who were willing to put into work. And there are guys that already demonstrated that they were willing to put into work. They've done a ton of this work already in the room. So, what we basically realized was since there's no real tension, there's no real conflict, we want the same things on, let's say, 95% of the base of what a framework should do. We want exactly the same thing. On the final rule, let's say 5-10%, we want different things, but the different things being different compatible things. So, why not share that base of 90-95% and then work together to ensure that the last 5-10% write as well? So, that's basically the long way around how that works. This is true. We want the same thing for the 90-95% case and we can agree on the last 5-10%. I mean, what are we wasting our time for? Let's just get this going. Let's just make this happen. And so we did. And this is where we are today. And I think so far it's been working out really well. Actually, it may be better than I had even hoped that it would. Because, I mean, there was so much tension built up that we could see, alright, we've poisoned it well, there's no way we can work together, or the communities won't gel, or quite actually. It's proven not to be true at all. We've been working with Yehuda and the rest of the team for, I think, that experience so far has been great. I mean, we find ourselves in agreement way, way more often than we find ourselves in disagreement. And when we are in disagreement, we just settle in the facts. Either you bring in a benchmark or you bring in a piece of code that demonstrates something being advantageous or not. So far so very good. My question is, is there anything coming in an upcoming version of Rails that you're really interested into the point where you're developing a lot of new code to contribute to Rails that's a brand new feature, something that you want to hint at or that's really interesting, or are you mainly working on 6s and the 3.0 integration of Merb? So, for starters, I've been mostly focused about 2-3 for now. We've just released that release candidate a few days ago, and that has been where my majority focus has been. And in that, I've worked on a fair number of those things, including the stuff that the engines set up working, because I had my own need for engines come up. I've been working on two engines, sort of apps for integration, so whatever you want to call it, two engines. One for a translation feature I was doing, some translation of base camp, and I wanted kind of an app to control those demo files. And secondly, I've been working on a Rails engine that I will have some potential for for making it into Rails 3. For Rails 3, I think one of the things that I've started to get a lot more interested in is rewit-bamping our roasts through Ajax, and not so much because it's unobtrusive as a pursuit of standards compliance or something like that. I don't think that's all that interesting. I know that there's plenty of people who care about it, and peace be with that. For me, it was more a realization of things. How could I make more stuff that I wanted to do with Japs with easy-to-do? I've just been, actually just for the past few days, working on a tiny mini app where I did that simple trick where you replace timestamps with relative systems and doing that to custom attributes. And I've been kind of interested in that whole custom attribute thing for a while, so that's one of the things that I'd like to be definitely involved in pursuing. Some of the two other things that I've been involved in has been more perhaps on the API design level. We've been talking for some time about how can we merge the router with the Rails router, and for me, I have not actually touched my implementation of what we wanted, both in verb and in Rails. It's really hard work, and as you guys know, we've been asking, so I've been taking a very keen interest in making the APIs for now pretty good, but it's definitely not perfect. There's a lot of good ideas from both the router, and from what Sinatra is doing, and from just our own approach at the suit of the best principles that can make the easier to deal with and easy to use and so on and so forth. So that will probably be a feature issue that I personally care about working on for Rails 3. Better set up for JavaScript and office system and untruesiveness and making the router. The interesting thing about work is continuing to polish. Every single time you fix something in Rails, you take away a problem, something else pops up, and they should be better. They should just be improved. It's a great pleasure being involved with something like Rails that continuously improves. You're never done. As soon as we get all the problems, we think right now are big problems for Rails, so there'll be a whole another class of problems popping up, because they're now visible, and that's just how it goes, and that's why it's so fun. I've been working on this stuff for six years, and it's time to make things nicer almost every single day that I actually sit down and work on Rails. If something about Rails is nice, this could be better, this could be changed, this could be improved. Yeah, I think that was an answer to that question. I'm actually not answering it with your next question. We decided it might be a little better if you'd actually look at the person asking the question instead of putting it to them. So we're working on that. So kind of as a follow-up, I guess there's a little bit of a build-up to it, but obviously you guys have just released 2.3 or at least released candidate 4, 2.3, and that carried middleware and a few extra things in it. And obviously to this point, we've been talking about the Merb push adding in the features for Merb toward Rails 3. So my question, and probably also later on, I think Yehuda's here, right? So I'll probably pose with him as well. Working on both frameworks, by the way, my name's Nathan Bibler. I didn't actually introduce myself to you. Working on both frameworks, they're somewhat dissimilar in the way they're set up. Obviously Merb is very formatted, structured, whereas Rails has a lot of termed magic to it. Things happen for you, which is kind of a different feeling. So going forward, migrating an application from 2.2 or 2.3 into 3, what do you see is the migration path? I know it's still early. Is it going to be more Rails oriented so that people from the Rails side are going to feel less of a change? Is it going to be a trade-off so that both sides are going to have to make adjustments? What do you feel is kind of the more heavily weighted side on that foundation, I guess? Well, it's definitely going to be a trade-off. There's definitely going to be things that you will need to change in a Rails 2.3 application to make it work with 3.0. There's no question about that. We're adopting a bunch of PADs from the Merb side of things, and some of those ideas will be backwards and compatible, which is why this is not an effort for Rails 2.1. It's an effort for Rails 3.0. With all that being said, we are basing this work on Rails components that are already there. We're evolving the Rails components to merge in the good ideas that Merb guys brought to the table. So, I mean, it's probably going to feel a little bit more like Rails stuff, but I don't really think that matters that much in these days. Merb and Rails was a lot more similar than it was this similar. So all of that stuff will continue to be. But I do think that there are some things that will remain a difference. So Rails definitely has more defaults set up already. I think that the Merb guys were already moving in that direction. There was now a stack in that kind of pulled everything together and kind of set up or put up some of these, some defaults already. So I think we're kind of in some aspects anyway. And in the aspects where they weren't, I mean in the aspects of allowing you to go into a framework without having it be painful in any way and so forth. That's the kind of stuff we're going to take into Rails. So, in some ways, I think it's going to be going to work right out for both camps, for both migration paths, because the Rails guys are going to say, alright, I'm just going to form some Rails guys of making brah and sweeping generalizations here. People coming from the Rails camp will instantly feel that setting up a new application, every single default is there. We're not going to be yanking people out. We're not going to, when you set up a new application, force you to make a lot of decisions about things. So if you just want that on the track, conventions, I'm just going to take what Rails gives me, you're right, it's going to be the same, if not even smoother. I mean, more with a, hey, I'd like to use different frameworks here for things that Rails already have people's for, kind of like more of a Merb construction in approach. We're going to fire that really easy thing earlier, where I don't think there's that much conflict to make both of these things work. The fact that there is default does not necessarily make it harder. I mean, what's important to me is that the choice is not forced upon you. The choice is optional. You make a choice when you have a specific opinion about something that you hear deeply about. And then who am I to say that your choice is good or bad? I'm totally fine with that. What I care about is setting up a framework that's incredibly easy to use for people who don't know how to make those choices yet, or are happy to make the same choices as I'm making and as we've been making in the Rails community for a long time. So I think there's very well room to fit both those approaches on, say, my move. Matt Williams. Hey. So my question, this could be very short and sweet, is when the release of Ruby 191, how are you as one of the large influences of Rails and 37 Signals as a company plan on embracing these new releases that are finally becoming a little more stable, have the speed increases? Yep. The roadmap at 37 Signals for 19 is called Jeremy Kemper. He's been the guy at 37 Signals and the Rails team in general has been really good at keeping up with 19. He's been putting in a ton of work for a very long time to make sure that Rails itself was 19-compatible. So in many ways, I'm delegating his advice on this because I have not even installed 191 or any 19 release really on my own computer and pulled around with it. So it's pretty much when I'm going to install it is when Jeremy Kemper says it's read we're good to go and you should run it. So to me, I mean, I think it's great that there's still a lot of problem going on with Ruby and I think it's awesome that they're expanding it and one-night time, wonderful in many ways. It's not going to have that huge impact on what it is that I do every day. So I just tend to say, all right, I mean, there's people who are passionate about that and following that. I don't need to follow that in that one sheet. It's basically the answer for both Rails and for Jeremy Kemper when he says it's go. It's time for me to give it a try. But I do hope that he's not the only guy in the world giving it a try. It's kind of a lonely pursuit. So it'd be awesome if everybody, at least having one person within each company or group say, hey, I'm going to give one-night time and see where it breaks. Try to get these issues published and out there before we're slapped with a stable production policy on it. I think we have some problems in the past with Ruby, especially with Ruby 187 where it just did drop in one day and it was kind of bad way. It wasn't a great smooth release. I think some of that, how many people were trying out the latest version and compiling it and testing it with their apps, similar problems that we often have. People in general just aren't very interested in trying beta releases. And we've had this problem in the past, even released candidates in Rails, which just wouldn't have enough testers. And as soon as we declare a version to be final, all these bug reports will come up because people wouldn't try it until it was final. And I mean, it's kind of chicken and egg thing. I mean, it can't be final until we have people who actually test it. And I mean, it's just like I said, I have not been keeping up. My excuse is just helping people to definitely try out Ruby on a more regular basis. So as soon as we don't have those solutions for a new version where we drop, a new version of Rails drops, and all of a sudden people find the problem just as well can be final. Hello, David. I'm Brian Lyles. Hey, Brian. I want to ask you about with the emergence of the lightweight HTTP libraries like HTTP Barney and REST Client, what really happened with Active Resource? Is there... I'm looking for compelling reasons to use Active Resource in my applications now. Sure. Yeah, I'll give you the... We actually talked about this recently. We had a small sprint in Chicago where Yehuda, Rick, and Josh and myself was president. We talked about, so what is the role of Active Resource to speak? I am a little bit closer to the answer by saying Active Resource is a very narrowly constrained solution. Active Resource is a many-way as what Active Reckon is to a database driver. So, a database driver is very adhering. You can do a lot of things via any type of SQL. Active Reckon has a much narrow focus. It relies on a greater set of connections, and it then gives you an easy write-up that Active Resource is in many ways the same way. When you're using Active Resource against a Rails application that was built on top of all those conventions, it's going to be really nice and easy to do. Active Resource today is not a great tool for generic web applications, generic press applications, things that wasn't built with Active Resource in mind, things that wasn't built on top of those conventions. So, if you're trying to integrate with some API that's RESTful, but not in any way built on top of the Rails conventions, you're probably going to have a much better time using REST Client and ACP Party. On the other hand, if you are using REST against a Rails back-end, Active Resource will be a great ride. That's all I have written about Active Resource. We use Active Resource internally in particular to integrate our applications because all our applications are Rails. So, all those conventions are already set up for us. So, I think the simple answer is if you're going to do REST against a Rails application, use Active Resource. I doubt that ACP Party and REST Client is going to be significantly easier to use than Active Resource is in that case. But, if you're using it against something else, something that wasn't written with Rails and Active Resource is open to those conventions in mind, don't feel any shame at all. REST Client and ACP Party and more low-level solutions to that. Right? There's plenty of room for both ends of the spectrum, which is in some ways kind of the similar realization that we're making with Rails. So, the default ORM in Rails is going to be Active Resource. Or Active Reckon. In Active Reckon, it's great when you have more power. You have zero power in your schema, and a lot of people can try to bend Active Reckon to fit all sorts of weird, or I shouldn't even say weird, different schemas for our ancient schemas. Sometimes it just comes to the realization Active Reckon is not going to be a great solution for all of that. There's ThinkModel, there's Datamap, there's other types of tools that works better when you don't have the luxury of having the conventions available. All of the frameworks in Rails are built to work together in the sense that you get that luxury, you get that benefit of having all those conventions. That's why we can write so little code when we can rely on all these conventions working. And that's great when that's the case. When it's not the case, but you don't have the conventions, you can feel any shame using anything else. I would. One last question. David, do you test all the fucking time? If I test? No, do you test all the fucking time? I'm not even sure how to parse that question. If I unit test everything I do, send it again? Do I unit test? No, everything I do, but if you just test, I don't care, unit, section, loving, integration, acceptance, functional. No. Okay. I know. I just wrote an entire... Oh my God. I mean, how can you even imagine constantly improving application that's been living for six years to break something when you introduce the new feature? It would just be impossible. I just wrote this tiny application to more people if there's something that's down, just a small status application, as I said, 78 lines of code. Does it make sense to test that? No. It would change very unlikely. And if it is going to change, I can do that. So in that case, testing wasn't worth it for me. But obviously worth it when I work on it. It's 10,000 lines of code. And some applications are going to live for a very short time. We're not going to be changed at all. And maybe it's not worth it. I wonder what you say that Thine isn't rocket surgery. And what I want to know is, could it be? Could Ruby and Rails be used for really next-gen flight control or launch control services for NASA? And if so, what arguments would you make to the developers that, hey, take a look at Ruby and Rails? So, I should first preface this by saying I've never built anything with that type of criticality. I've never built anything where people die if I have a bug. But from what I've heard, I've been working on software for pace makers. So for example, for this page maker, I'd be saying a line that's going to go into the software. They had an incredibly rigorous review process where they had tons of things with different people and so on and so forth. So in that scenario, I mean, you're going to hopefully get the bugs out of that system just by reviewing everything that goes into the regular system, too. It's about... We have a good idea of what all this code is doing. If the code we have for review is 2,000 lines of code, review and make sure that it's proper and correct than it is to review 20,000 lines of all the Rails stuff that you would use, and so forth, to make sure it's right. But I don't... In some ways, I think this notion of criticality can drag into it because it kind of is in the system that there's something you cannot see even though you turn it around to get super high quality to me is a process than it is about anything else. It's about making sure you have incredible test coverage. It's about making sure you have multiple people reviewing the same kind of code. There's nothing magical that makes each form platform usable for pasting. I mean, people have certainly written bugs in C or C++ code, which is what these guys were using for the base maker project. I mean, they had buffer overflows. They had all sorts of bugs to prevent it. And how did they get written all this stuff is by rigorous review and process. I think that's absolutely possible in any platform or in any field. I mean, all that being said, this is lame or not to be responsible and blow stuff the next Apollo mission or something. That's that. Because without saying, I'm going to act as a proxy for a few questions that a few other people wanted to ask. So these are just really quick questions. Maria, necessarily wanted to know that if you could only have one of the following two for the rest of your life, which would you choose cake or pie? What? Cake or pie? So if for the rest of your life you could only have one of the following two items. Would you choose cake or pie? Would you choose cake or pie? I love the rest of my life. Good, good. Jay, 10-year-old wanted to know when you were going to change your hairstyle. We're talking about this is the most timeless hairstyle there is. It's going to the next 100 years be the top of the pop. That huge age that is how it goes. So that's a never? Yes. Okay, all right. It's been any? Never. Les Allen wanted to know why you aren't following at Les Allen on Twitter. Jason knows. And although this is, this question is now moved with the announcement of Rails 3.0, myself and a bunch of other people actually really wanted to know who you thought would win in a fight. You or Yehuda. Classes. So you better come on Thanks very much. That was interesting. Does anybody else have any questions? Oh, did you see at RubyConf, which was here in Orlando, Dave Thomas did a keynote. Did you, did you see his keynote? He basically, I haven't seen it now. It was the fourth keynote. I've heard that just, yeah, it's Colin Freaks guy, got it. But basically, he talked about how he wants to see different flavors of Ruby, like a parallel Ruby or a closure Ruby, different flavors of Ruby with Rails 3.0 becoming more modular. I'm wondering, I can see how it would become more easy for people to create maybe different flavors of Rails, right? Like take an individual library, minimize it, or design it for maybe a different type of web application. I'm just curious to, if you have any thoughts on that, maybe some, you know, different flavors of Rails that you might want to see. I think that's great. I think another feature we actually have already in 2.3 that sort of makes this possible is templates. So people already have kind of like their house blend ground, which would be, wow, just a compilation of all the things that they commonly use. I think templates is really a great way of making the first step towards having your own house blend. And there's some signals we definitely have on our house blend. We have a number of plugins that we always use and kind of a process that we always use for deployment and so on. So that's the first step of doing that. I think it's great. I think people should probably share it. I mean, there might very well be that our house blend is something that somebody else would like to. For the more fundamental stuff, I absolutely think this is true as well. We should be making it really easy for people to substitute many different things of Rails. One of the concrete aspects that we recently talked a fair bit about is the router. So, there you have it. The good number of router ideas up in the air. There will definitely be one main router, one deep hole router. And this goes for all of this stuff. This is kind of like next level stuff. The house blend, your own alternative, experimenting. It's all for people who kind of reach the natural borders where Rails doesn't fit with them anymore. Most people will be very happy introducing deep holes. Anyway, so for the router, we want to make it plugable. We want to make it such that I forget who it was who was working on a new router. Prouding was in over. Was somebody else working on making a tiny router that didn't have the same number of features. But it was only two more lines per hole. And those can experiment correctly. We actually want to encourage those kinds of experiments. And if we get in Rails and make it easy for people to try it out, the same goes for for all the work that's going into agnosticism in general, to make it really easy for Rails to use another job's recovery. It shouldn't just be that, all right, right now, prototype and cake worry or kind of the big libraries. And then we just hard-code it to that and nothing else will work. Agnosticism is not just about taking the number of choices from one to two or one to three. It's about allowing anybody to come up with a new, next great idea and plug it right in. So I think it's awesome. I think I'd love to see more experimentation. And this is a lot of time for me to say about let's try it out in the plug-in. I think that's often the kind of the answer to something that seems a little off for core pollution. But it might be a really easy idea. Templates is a great example. Templates started out as somewhat of a plug-in. A lot of the good ideas have gone into Rails over the past years or many years. It started out as a plug-in. It encouraged everybody to try out crazy ideas. And that's also on monkey-patching. Very double-edged sword. On the one hand, monkey-patching allows you to basically change anything you want in Ruby, in Rails. If you monkey-patch, agreement then is that you're experimenting with stuff that is something that's radically right these things and alias that chain that thing and so on. And just realize, alright, I'm doing a disturbance. Then you go back and say, alright, I'm just gonna blow up every five minutes that the Rails guys change something into a terms of rail. So, I definitely want to get that out, too, that if you're going to go on exploration with serious experimentation and alias method changes that the other thing and overrides and so on, it's going to be crack-on. Very, very crack-on. And that's just the trade-off. I love that trail, though. I gotta say, there's been time to try out something in Ruby, Ruby's standard library or something else that requires deep monkey to go in with Verizon. For example, we've had problems with the cookie library in the Ruby standard distribution had a bug at one point and we just weren't willing to wait around until the next stable version of Ruby was released. So, we monkey-passed it right into the Rails and it worked and we pulled it out when it wasn't necessary. Two thumbs up, too. I think be careful if you do monkey-patch and it turns out to be something you want to keep across versions. It's Nathan again. I think we're in the last few minutes here, so I'm actually going to kind of change the focus, I think, of this away from the framework and more, I think, toward the application development. I mean, at this point, you've kind of, you know, at the very least have a handful of what I think all of us would term as successful applications. You know, being base camp or campfire or high-rise or something like that. You know, I think this is an open-ended question, but what do you see as the major points for developing a successful application, via the business side or the technical side or whatever you feel jumps out to you? Yeah, that's a good question. I think one is, I think one, the major points I'm going to talk about a little bit in Dublin in about a month's time or so when the future of web apps is sticking to it far too many people have ADD when it comes to their projects and it comes to their work and they think that just because they didn't have a slam dunk success in three months that that means that they are sitting on a failure. Lots of things look like a failure for a very long period of time with all attempts and success. Base camp by many, many definitions was this huge failure for the first year. We couldn't even pay our bills for the first year and we were a tiny team. So base camp, base camp failed by many other companies standard definition of failure. But of course, we stopped doing it and now five, six years into it is doing millions of dollars of revenue every year. I think that's definitely a pretty important part of it. Secondly, important part of it I think is all the applications that I've worked on the framework I've worked on everything that I've worked on and purposes. So I think it's so much easier to make a application within the field where you care. It's really hard if you have to fake caring because you're working in some industry or in some domain that you're just not really passionate about. It's very hard to pull together that excellence that's needed to break through. So working on something that you personally care about, I find this just so much easier to the point where doing anything else seems almost impossibly hard. What else would I say? Oh yeah, side projects. I don't want to people oh, I have this great idea but I'm working a day job there's no time blah blah blah blah blah. There's always time. There's always time to test it. FaceCamp was built I keep going back to this and why I do it is because I think it's most people waste 10 hours in a few days watching TV. I think something like that it was TV every day. They could have built FaceCamp just to make something that is multiple with 10, 15 hours on this. Just sacrifice some of the things that are easy to sacrifice like watching Wast which is terrible now since the second season. It's totally soft. Robert again. I'm going to steal the last question kind of piggybacking off of what Nate was talking about. One of the themes that I'm Jason and I are trying to interweave in this year's AXIS conference is really how Rails can help us as developers maintain a competitive edge. And we know of course that we can develop apps a lot faster than a lot of other languages and frameworks that are out there and whatnot. And I was just interested to hear a couple of points from you of how you think that even going forward how Rails can help us maintain our competitive edge. I think one of the most important things about the Rails community is that we have a very strong sense of caring about our tools. There's lots of other communities where the majority of the developers in there do not truly care about their tools. I think it's the right tool for the job and so on. And to me, there's been this notion of learning new language every year. Really passionate that goes kind of back to the whole notion of the ADD when it comes to project. I think lots of developers sort of also have ADD when it comes to tools. We definitely still have tons of people in the Rails community who have been with Rails for a very long time who have been keeping up their contributions to the framework and always trying to improve on that college. And I think that is a really important part of who we are. We care about the specific tool that it is that we're working with and everybody at the same time pretty sure that Rails developers in general that there's a much higher percentage of Rails developers who contribute to the common good. There's so many plumpings out there. There are so many bug reports and tutorials and documents and so on. We have a much higher proportion of contributors than consumers. We have a lot of people who are mobile. It's a great way to stay ahead. Become not just a user of something, become not just a consumer of something, actively get engaged. How can I make this work? I move forward. Just by using it, I mean, yeah, I can certainly learn something from that. I mean, I can certainly learn something and your perspective is from it. But it's only if I really try to improve that language or try to improve that environment, I really get the deep learning that just move forward. Great. Well, hey, thank you very much again for all your time. On behalf of the honest, very thorough answers, I highly appreciate it. So thank you very much. I appreciate it. Thank you guys.