 I am Rich Kilmer. I'm going to give a talk about the fact that all this obsolete technology actually isn't obsolete that we talked about earlier. I've been, yeah, all right. First slide. Before most of you were born, sorry for the color here, but this is RubyConf 2002. Couldn't actually find any pictures of RubyConf 2001, but it was about the same size as this. It's about 30 or 40 people. That was the entire conference right there. The important thing about this slide is, let's see if we can see it, it's right here. Right over here is Avi. So Avi was there, I think that's him. Could be Paul Brannon, but I think it was Avi. Anyway, you know, I have to have two slides go back and forth and say, this is Paul Brannon, this is Avi Brannon. Anyway, so 2001 and 2002, the first and second Ruby conference. Do you know what Ruby, at the first Ruby conference it was interesting. So we're there, this is a hobbyist language, everyone there were hobbyists. I was actually out of work, so everything was a hobby to me at the time, because I was part of the .com crash thing and no one would hire me because they thought I wanted their job and it was really bad. So I couldn't get a job as a programmer. And so I picked up Ruby and I started using it. I went to this conference, my wife thought I was insane for going to a developer conference. I didn't have work for eight months. She's like, what are you doing? And I said, but I gotta go to this thing, it's gonna be great, it's in Florida. So I went down there to this conference and everyone at the conference thought at the time that what Ruby was gonna be best at was, anyone have a guess? Almost, but not quite. No, testing. So everyone thought what Ruby would be really great at is testing, testing what? Well, not Ruby applications, testing other people's applications, testing Java applications, testing all these other things. But it was really in the area of testing that everyone thought that this would really be an awesome thing because Dave Thomas and Andy Hunt, when they first started looking at Ruby, looked at it to encode what? Specifications, executable specifications. So the earlier talk about what these types of tests that we're doing for acceptance tests are executable specifications, we were talking about that in 2001. It's very cool, right? But people are actually doing it, but now we're doing it on Ruby applications, Rails applications and the like, and it's very, very neat to see it. So the early years were kind of lean. We didn't have much, no sponsors, but Ruby started making an impact. So this is actually the 2005 RubyConf. Now Rails had been released now, and it's a really dark, but Rails had been released now. We had about 300 people at this conference. We realized we went from like 30, 40, 40, 50 to like 300. It was crazy. We realized that we had to split this conference into a RubyConf and a RailsConf. What's really great is if you look back here, like right here, that's like a Mac from back then, you know? That's like pretty old school stuff. There were a few people using Macs, but DHH hadn't made the impact on our community that he has today, and saying that if you don't use a Mac, you suck. But anyway, this conference was interesting because it really was an inflection point between the early hobbyists and then people starting to make a living out of Ruby. Now, in 2001 RubyConf, that was the first RubyConf. I actually submitted a bid to work as a subcontractor. I wanted to form a company. It was a subcontractor under BBN technologies. BBN actually created the internet. So contrary to Al Gore's thoughts, no, I know he didn't really say that, but anyway, BBN actually ran and built the first switches. So they had a DARPA contract to do a distributed multi-agent systems application, actually build a survivable multi-agent system that would survive in wartime situations. And actually, an interesting guy was on our project. His name is Ray Tomlinson. Does anyone know what Ray Tomlinson did? Anyone? It's the bubble, see? No, he wrote SMTP. He actually wrote the spec. So to get emails from the guy who wrote email is kind of weird, but anyway, he was on that project. There's a lot of really smart people on that project. They were trying to build this. They built it all in Java. They had about 800,000 lines of Java code across about 100 different contributors. And we joined, and at RubyConf, I actually, that first one, I got the call that said, we've accepted your bid. We're gonna hire you guys as a subcontractor. So my bid was, okay, we're gonna build a testing harness for this distributed multi-agent system. And we're gonna, well, we are actually hired to do systems administration, but we're gonna automate it. And we're all senior developers, so that's what you do when you're a sysadmin and you're a senior developer. We actually spent from early 2002 all the way to 2005 using Ruby to build a test harness for this distributed multi-agent system that was in Java. We had Ruby scripts that would be generated during the run of any multi-agent systems that were one million lines long. We would generate a one million line Ruby script. Why did we do that? Well, because if you generated an XML file that was a million lines long, then you parsed it in Ruby, it wasn't gonna happen, right? Even with XPAT and things like that. So, but if we actually generated a one million line Ruby script, we could load that up. You know how long it took to load up that script in Ruby? Took about a gig of RAM, but it took about three and a half minutes to just run it, to just load it up. But it ran. And it ran really, really fast when it was running. This one Ruby process would control 300 machine cluster. So by the end of the project, the first year of the project, they had no automation. I think they did like two or three good runs of the entire multi-agent system. By the end of the project, every night, we were doing about 15 runs of the multi-agent system. Ruby was doing everything. Ruby was coordinating all two, three thousand processes and everything else like that. So for people that say that Ruby doesn't scale and it doesn't work, it's ridiculous. We were doing that on one six, seven of Ruby. One eight's a lot better. One nine's even better. JRuby's really good too, right? Mac Ruby's really good at what it does. So, you know, that's just people just saying that. Right, they're haters, so. But Rails begins to make this impact and people start getting paid to do this. I was doing it early on, but people started getting paid to do this. Then here's the first Rails conference. Like 600 people-ish, right? That's a big conference. We were like, whoa, you know? And we had somebody help us run this conference. But this was a big conference. And this little chart over here, this represents the number of people just by show of hands, just rough estimate. Number of people that were in startups is the big purple thing. In consultancies, this is the little teally thing here, and then the whitish thing were the number of people that were actually building apps internally for internal systems in Rails. This was in 2006. Well, at that conference, was anyone at that first RailsConf? So a few of you, right? And Dave Thomas gave the keynote at the end. Do you remember Dave Thomas' keynote at the end? So Dave Thomas, this is steely eyed Dave Thomas saying, I know, but isn't that awesome? I mean, that's like, he said, all developers deserve to be happy. And what he was talking about is, if we are gonna win, we need to support the enterprise. And the response collectively was this, right? I try and run away from the enterprise. Why should I support the enterprise? We don't need to support the enterprise. The enterprise, right? And if you say it with a nice European accent, you can write a Rails framework and everything else. Anyway, you know, but there, what's that? You can. And other consultancies have said the exact same thing. Anyway, that's what was said. Out of all of that, we don't care about the enterprise. Literally, I think David Hansen's quote back was, unless the enterprise bends to us, forget it. Right? I don't care about that. Okay, that's cool. So Ruby then grew. So this is RubyConf in Florida. And we had about 500 people at the Orlando RubyConf. How many people were there? So look, actually the same people. But, so this is at RubyConf in Florida. This was a really nice hotel, by the way. And it was actually pretty cool. How many people are gonna go to RubyConf this year? So it's better. There's still tickets available. You should go. It's gonna be in New Orleans, it's gonna be a blast. And we're looking at capping at around 800 this year. For RubyConf, that's a very big thing. But there's still tickets available, so try and get them. But the Rails comps grew really big. So this is Rails comp, I think 2008. We had 1,800 attendees. What was really interesting was this number. Which represented, again, the number of people that are developing applications as startups versus consultants that were there, versus people developing applications for inside their company. Basically a split by a third. And what I did in preparation for this talk is I actually went and asked, so we have a consultancy info ether. And I asked three other consultancies to give me the number of projects that they've done since 2007. So granted, some people were doing things in 2006 or before, but 2007, eight, nine, and 10. And this is what the numbers look like. So over here in 2007, the blue thing at the bottom actually represents startups. So these are startup projects. You go in there three months, you knock something out for a startup, you flip them, they hire their own developers or you train them up and do that sort of thing. We've done that a lot. Other consultancies have done the same thing. Then you have the little SMB in the middle and then enterprise customers up here. So look at the trend here. Yes, we're doing more projects every year. But look at the trend to enterprise customers and SMBs versus startups. These are number of projects. These are not how many people are on the projects nor how much money is being made on those projects. But I will say that there's a lot more money that's made up here than money that's made down here. A lot more. And but what are people doing up here? I mean, by and large, what are they doing up here? This is the thing that I talked to Avi about. Again, hard to see this stuff. But this is something from a Gartner study that actually talked about a dramatic increase in the number of applications that need to be built. The number of applications that needs to be built is increasing really, really, really dramatically. Ballmer said there's gonna be more applications written in the next five years than any five-year period of time that's ever been. There's a dramatic acceleration in the number of applications that need to be built. There's a backlog in IT in enterprises and small to medium-sized businesses that is just, it's huge. Why? Because those enterprises adopted Java and that technology for back in the day was actually really good. When in the early days of the web, Java was great. I mean, Java had built-in networking. How many people have programmed Java or for a living kind of thing? Not as many of you that should have, but Java was, I mean, back in 2000, actually in 95 is when I started with it, but like 96, 97, I mean, you could do networking out of the box, right? You had memory management. We had all these things we kind of take for granted now, but Java was an amazing difference from doing things in C++ or C and a lot of enterprises adopted it. But in my view, Java is a systems language, right? It's good for building systems in, but once the web happened, people were starting building web applications in Java. Java is a very verbose language. These web applications were taking longer and longer to build. So as IT departments were building these things inside of them, the backlog of applications that needed to be created, by the way, the first applications that were being built were building system stuff, like the core accounting system in an organization was eventually moved off of like cobalt to Java. That was a big deal and they might have 300 engineers working on that at a major enterprise. I know that sounds ridiculous, but that's what they were doing. But then what are the applications that need to be built today? The applications that need to be built today and we've encountered many customers that are like this are departmental applications. They are not enterprise robust systems. Now I'm not saying you can't do that in Ruby and do that sort of thing. I'm just saying that's not the target. That is not what we are seeing. What we are seeing is people have built these applications in things like cold fusion and things like Lotus Notes. Lotus Notes is a huge, huge infrastructure for a lot of people. There's a certain intelligence agency in Northern Virginia that is actually porting most of their Lotus Notes applications to Rails. Right? Well, 40,000 of them ish, right? There's a bank in New Zealand that has Lotus Notes applications and they're porting them to Rails. All 6,000 of them. One bank. How do you come up with 6,000 applications, right? Well, because you have an application. No, you have an application that's for these four people over here because they generate that bank $20 million a year. Are you gonna automate their job? Hell yeah, right? I mean, they're generating $20 million a year and they're not getting paid nearly that, right? So you're gonna automate the crap out of that and they use Lotus Notes for this kind of stuff. Why? Because Lotus Notes was a full stack system. You had a really kind of robust way of representing things and then models and then you could build the view stuff out but they all use the Lotus Notes client. Yeah, Notes had Domino and the web stuff and that was painful but people use it. But people are trying to move away from proprietary stuff. They're trying to move away from paying license fees for every desktop, which is what Lotus Notes does, and move towards open stack. Rails fits that. Rails is winning there. I mean, totally dominating. They actually did training for the US Department of Agriculture for developers in the US Department of Agriculture because they built a Rails application. They actually use a framework called Hobo on top of Rails. You know, Hobo? It's actually a higher level of abstraction on top of Rails. But they built the whole thing. Now, all these developers were the people who actually built this app and they were coming to learn Ruby and Rails. So, by the way, the USDA funded them to write a book on Hobo development. So they actually published a 300 page book on Hobo development. It's really good. But like, you know, the first 50 pages are how to set up your environment on Windows with Oracle to build Hobo applications. It's really good. If you need to get Oracle running with Rails, go look for that online book. It's free. The USDA did it because the CIO of the USDA is a really big believer in Ruby and Rails. The CIO of the US Department of Agriculture. I mean, I live in DC, so I see this. Okay, so we've got these enterprises that are starting to develop Rails applications. And we see it over and over again that they're building these things internally. Well, the big thing is, why do we care if they're doing it, right? Why do we care that enterprise people are out there? Should we care? Should we even think about that? Well, I would say that populations with the most diverse gene pools survive. He helped us with our diverse gene pool, by the way. He actually added a whole level of diversity and still does in my book. So anyway, populations with the most diverse gene pools survive. If you're in a very restricted bubble, as I said earlier, I love Avi, but if you're in that and you say, I don't care about anyone out there, I don't care what they do, or anything like that, you can do that, but you probably won't survive. You just won't. I mean, this is evolution, right? You won't survive. So why should we care about enterprise developers using Rails? The first thing is this. And I'm serious, right? And I've used this analogy before, but, okay. If you're, how many people here are starving right now? I know we have lunch coming, but I mean, like, you're not starving, right? But there are people in the world that are. Absolutely, and I mean this seriously, right? Why do we help them? Why do we donate things to them? Why do we, as human beings, try to do that? Because we have compassion for them, right? Why should we care about, and this is an analogy, and I know it's not as dramatic as, like, life or death with food, but why do we, as developers, care at all about enterprise developers? Compassion. Their job is hard. It sucks, okay? But guess what they do? They listen to people who have to build something, or you know, that needs something, some business person, and they build that thing. Their goal is to get it built. Their goal is to deliver something that embodies the domain thing that they are trying to do, and they get a good feeling when they deliver that. I don't care if that system's in Java or whatever else. Rails lets you do that more efficiently. We know this, right? We need them to be able to feel the same good stuff that we feel when we build our applications. So we should have a compassion for how they feel and what they need to do. We need to spread the love, right? Around. But the question becomes, what do they need? What do enterprise developers need? Well, believe it or not, I'm gonna list some things here. I even have Oracle up there, because there's Oracle Signs everywhere over there by Moscone Center, but what do they need? The developers themselves don't need much right now. If you look at organizations that have developers building applications inside of them right now, the enterprise, they do not need, and I'll say this later, but they do not need changes in Rails at all. This is the kind of crap they need, right? They need IT to control deployments, not the developers. We think CapDeploy is awesome. Your IT department thinks it's crap, right? Now, even if IT is the one that types CapDeploy, why the heck are we going to a command line to do this stuff? I gotta install putty on my Windows machine so that I can actually type CapDeploy. This makes no sense, right? They're not used to having to do that. They don't want to do that. They need repeatability. This is within the organization. By the way, these things are all, well, the first three are really focused on IT. The biggest pushback we see inside of enterprises is not the developers. The developers have to deploy. When we were at RailsConf, we had a booth, and we had these guys come up from MITRE. Does anyone know who's at MITRE? MITRE's kind of a think tank. They said, yeah, we have 50 developers at MITRE developing applications in Rails. 50, that's a lot of people. I'm like, we have teams of like three or four people developing really complex, I'm like, really? And they're like, yeah, we develop all kinds of stuff. The problem is, it takes us about four weeks to deploy an application. I was actually one of those 50, doing one of those deployments, and the hardest, the absolute hardest part was I could get an app deployment. Come on, interactive. Participation, right? I could get an app deployed to my environment, to my machine, and anybody from within my community. I could get an app deployed to a test server that had a great server farm like EC2 internal. I could get it deployed in 20 minutes. The problem was, at some point, IT wants to own that, because if anybody else is gonna rely on it, they don't trust my department's gonna keep punting it. It wasn't a problem ever of technology. We had all the technology involved. It was always a problem of the process. Right, right. So that process, but it comes down into accountability. This is what they want. They wanna know who pushed what. They want a record of all of that. The Reset-O-Stone. You know Reset-O-Stone, right? So they use Rails for Reset-O-Stone. They have since the early days, the first time on the web stuff is all Rails. Because of Starbucks, they record every SSH session that the developers do when they go in, while the IT department goes in to actually deploy things. They record everything. They have to. They have to record everything they do. They need this kind of accountability and auditing. This is all IT on the top. They need this. They need control of it. They need to be able to repeat that. They need to be able to have accountability and auditing of what's going on in the system. Of course, they need monitoring things like that as well. This is kind of IT needs. It's not developer needs. But I will say this. Developers do need something here. The, you know, we're kind of spoiled in our bubble. And that most of the developers that we surround ourselves with are probably pretty good developers. How many people here have worked with bad developers before? Now I have heard this number and I kind of believe it. The difference between a good developer and even an average developer is probably 10X. We had discussions of why that is or whatever else. The reality is there's about a 10X disparity between that. Now things like Java actually obfuscate that. Now it's not that somebody who's 10 times better at Java can't outperform somebody who's not. But because of the sheer size of teams, the person who's excelling is kind of like washed in the middle of that. But when you have three devs that are actually working on something, that 10X person looks completely different than those other folks when you have smaller teams. And most Rails teams, even the larger organizations are small, they're not really large. So, you know, the development tools to me help the average developer become better or the average to bad developer. Yeah, we'd like to get rid of the bad developer. They're there, right? They've got, you know, they're there. Anyway, for whatever reason. But development tools help them. They help them get better. I think this is a big thing. This is what developers do need inside of larger organizations. And I'm saying average developers inside of there. Who are they? This is an awesome picture I found of Microsoft Windows developer award winners. These are enterprise developers. They're in the financial services sector, the like TransUnion Bank of America. These are enterprise developers. And by the way, they're female enterprise developers. You know that there's actually, statistically 17% of the programmers are female. Now, there's not 17% of this audience that are female right now. That's close to a fifth, right? Are female. I have two friends of mine that are twins. And I've known them for like, I think 12 to 15 years. And then one day in a conversation, I'm like, you know, what do you guys do? But you know, guys don't ever talk to girls about what they do. They said, oh, we work for AT&T. I said, what do you do at AT&T? Oh, we program their phone switches. You do? And what, C++? Both of you? We both got jobs at AT&T out of college. And we developed twin switches in C++. Like, that's hardcore, you know? And you know, but they never talk about it. They never ever talk about it. But I mean, they're good at what they do. It's just a job. And they go home at night. They don't think about it, right? And there's a lot of people that do that. So what I wanna kind of finish this with is there's these people. What if we could give those average developers, the developers that aren't the exceptional developers that can actually pick up this stuff and just do it? So those people are doing it now, by the way, in larger organizations. What if we could create for them, and I just threw up some things with Balsamic, which is a prototyping tool, just an interface for an idea. What if we could give them a Rails IDE that had models, controllers, and views? And I clicked on a particular model, and the model came up with my attributes, with scopes, with callbacks, with methods and associations, and I could click on a particular method, and I had my specifications for my method, which was green because it ran, and I had my implementation of my method, which I could type in there. And by the way, every time I typed into that code, it would run the spec against that, right? By the way, you're not seeing the file system here because it's irrelevant. It's confusing. I think, by the way, this is just in my mind, one of the things that differentiates that developer that's 10 times more productive than the others is their ability to actually conceptually visualize things that have no physicality, right? So things that are just models and everything like that, they can envision in their mind, they can picture it, they can build up a picture, they can visualize it, and so dealing with models and bouncing around between things is no problem for them, right? But if they could actually see the stuff, I know this kind of looks like VB and it's scary, but that's what I'm talking about. VB did more to actually bring developers, to increase the number of developers in the world, actually, than any other thing has ever done. That's scary, but attributes are tight. By the way, I don't need to generate migrations. I click a little plus, I add an attribute. It generates a migration for me. So all I'm talking about is something that's sitting on top of the Rails directory structure that's doing this. I click on a controller, are my controllers here, and I see my controller, it's got my actions, my filters, and maybe some methods, it shouldn't be there, but anyway, so I click on a particular action and the specification's read because there is none, because no one's actually written a functional test for this. And this is just ideas, right? But what if you built a Rails IDE? I develop, and this could be, by the way, in the web, I don't care if this is a web-based system, this is a desktop-based system built on Eclipse or whatever else, but what if we built a Rails IDE that allowed Rails to be this accessible to the average developer to build up what they need? They now can visualize things that they can't maintain in their minds because they can't necessarily build up the abstractions that we might be able to do, that we kind of assume people do, but they don't necessarily do. If we gave them this, and by the way, I was thinking, you know, when I click on a view and I'm in a view, I could actually bring up a window that had the model in it, and I could be looking at the model while I'm looking at the view and the model tells me the attributes, and so I'm typing them in, and Intellisense is nice, but being able to actually see that model and see the associations between things and clicking on the associations and bringing up the other models, this is what I'm talking about. This is not a small talk IDE necessarily. This is very focused about Rails, about building database-driven web applications with the Rails framework. I think this would be awesome. I think this would be awesome, not for me. I would not be a user of this. I really wouldn't. But I think it would be an awesome thing to actually enable that kind of average developer to be able to use to build Rails applications, and then hook this in with, I wanna deploy this thing, right? Hook it into Heroku and various other things, which by the way, IDE vendors are doing, you know, Apptana and all these other people are kinda doing, but they're doing a traditional IDE. It's file-based and I'm editing files, and some of them are surfacing up the models, but I mean, really, this is like spoon feeding people, one thing at a time. I just think that this would be a really cool thing, so we kinda leave with that. The most important thing I wanna leave with this is what is the opportunity, and by the way, there is money here. Now, there's a lot of money here. There's not money in DevTools. Yes, there's not, right? Because everybody's like, there's no business there. But there's money around it. If you built an environment like that and plugged it into your enterprise cloud deployment system, there'd be money in that enterprise cloud deployment system, trust me, a lot of it. But Devs need that kind of environment, I think, to actually be able to increase the pool of people who are developing. We do not need to change Rails to support them. This was David Hansen's big thing when Dave Thomas in 2006, four years ago, said we should support them. DHH said, now, we're not gonna change for them. You don't need to change Rails. They like Rails. What we need to do is embrace the fact of what they need to do in the environments they are and build to support around them. Education is one thing, conferences like this are awesome. Books, we have a lot of books in our ecosystem, bigger than almost anything else out there if you actually look. The Rails shelf at My Barnes and Noble is almost as big as the Java shelf now. Or the Ruby shelf, I should say. That's awesome. And we need to support them to me with the creation of tools around Rails. I think that's a huge opportunity. And you can make a lot of money doing this. Larger organizations will pay very high rates. Very, very, very high rates. And you don't have to deal with VCs. Anyway. But really the key is I think there's an opportunity to help them feel the joy that we feel when we're actually developing these applications. There's opportunities to help them move along to what Avi was talking about and build in a new type of application, a new type of client server desktop, not desktop, but client server-based web application rather than just a server-centric, if you will, web application. You can do all of this. And it is actually really fun, believe it or not, to work with enterprise customers. We have several of them right now. I enjoy it. Sounds crazy. But it's actually fun. And even their processes are there for a reason. A lot of it's CYA, but a lot of it's there for a reason. And it's neat to actually go and find out what those reasons are and then to encode them and to build that up. And so I would just say from a call to everyone out there, we should not ignore them. And the whole point of this talk is we don't hear on Twitter what's happening inside these organizations. They don't tweet about it. They go home at night. They don't even think about what they're doing during the day. But we are not hearing about this, but it is happening in a very big way. We're seeing nothing but increase in work. And you saw that chart, so were the other three consultancies that we talked to. Everyone is seeing an increase in work. But what we do a lot is train people up to be able to do this stuff internally. So all these organizations are growing and they're using Rails and we should kind of embrace that. Thank you, Rich.