 So, um, yeah, like Coby said earlier, uh, Tamron and Randall were meant to be here giving a presentation, um, building modern service-oriented architectures. I can't even get through that without trying to falsely. So yeah, so they asked me to give it on their behalf. So my name's Tamron. I'm Randall Thomas. And so we were too busy enjoying our whiskey last night to really put this presentation together for you. But, you know, as I was enjoying whiskey last night, I, uh, you know, I came up with this alternative idea of, hey, what a Thunderbolt Lab-sponsored open whiskey bar. So that just sounded great to me. So yeah, woo-hoo. You can all thank me, Randall, later. Except for the fact that exactly none of that's happening. So, um, Rain, where are you? Steven Baker, where are you? Get up here. And Eric. So, if you've been to RubyConf and you've seen our, uh, so you think you can code panel, where we basically just get up here and argue with each other, that's pretty much what we're gonna do. So, hope you enjoy it. Oh, we're gonna take a, we're, we'd like to take questions. So, if there's anything that you would like to know how not to do, feel free to just toss a hand up and we'll tell you how not to do it, because that's what we're really, really good at. How do you not write Ben String? I'm actually gonna give this one to Rain. I can't think of a case where we'd ever not want to write Ben String. So I can't answer that. Literally, you literally always want Ben String. All the time. And I want whiskey, all right. So, have you guys, uh, have you guys seen the recent blog post about Unclerc and if Rails is possibly failing? No. Anyone, have anyone seen that? No. Don't be silly. How do we feel about Rails being a failure now, which is a fact, because it's on the internet? It was never successful in others' place. Yeah. It never scaled. Right, exactly, it never scaled. It wasn't web-scaled. It was just, it was just a thing that tied us over between Koval and Nub. No. Right, yeah. It was on Rails. Like what? We're about to intercal. Intercal, right? Intercal on stilts. What was that? What did that mean? Intercal on stilts. Yes. So this is only going to work if you guys ask questions. So, start doing that. We're happy. We're going to do a drink. This is, uh, this is something, I don't actually know exactly what it is, but it's made by experiments. Hogshead. You mean, it's Hogshead? Yeah. Yeah, you can get it in back. We have a question here. Yeah. This is semi-serious, so you can put it up. We have another question in the back. Do it. Go ahead. Okay. Let me, let me just bring my mic around. I can yell. Okay. Make Kolton do it. Yeah, where's Kolton? Do all of them get to work here? Yeah, where's Kolton? Kolton. Where are you at? Kolton to charge. I didn't even have a question. But I have a mic. I haven't asked yet. Yeah. Okay, so I wanted to know, uh, Twitter switched off of, uh, Rails mostly. Go ahead. Um, go ahead. I want to know, is it, is it possible to make a scale at that level? Yeah. Or do we have to go on to something else? Serious questions or no, or serious answers or no? Oh, I've got a, we've got a work, it's an autograph at work that does 3 billion requests a week. All. All of it. That's it. I mean, I don't know how many Twitter does a week, so. Audience participation. I process at least 15% of Twitter every day. Every day. All day long. 24 hours a day. Good job. How much staff? In Ruby. What? Staff? Yeah. Uh, we're up to, well we weren't two for a while. We're up to seven. Oh my God. Yeah, that's amazing. How many in your team? How many in your process? When are you moving to Skalton? Oh, actually our intern took over for two Rails developers that left. So. Require. Require. Yeah, Colton's here. So if anybody needs a drink. Require relative versus require with load path, mainly. If you make a load path, then you're doing a good job. Great job. Do it. Every gem. Make sure, make sure there's like other gems too. Yeah, other gems too. Our spec did that once, it was great. Yeah, and personally, I would really, I would like to request that everyone use Unship to do that. Oh yeah, I forgot about that. Here are you guys? Find other things that you don't want there and then remove them. Don't ever forget that you have access to Rails. You can change the state of anything. Hold on, hold on, hold on, hold on. Here are you guys? I just said that, I'm sorry. That's fine, we're just some people, it's not a big deal. Just some people. And if you want to go for bonus points, delete stuff out of loaded features. So what questions should we answer? Sorry, seriously though. I'm Ben, I've been doing Ruby for a few years. Ben is blithing not blaving. Oh, he gets so pissed off when he's been blithing. My name is Ben Blithing. What blithing? Say it slow. Blivee. All right, the other thing that Ben does in the community, Ben and a guy named Shane Becker actually created the first conference to run in Seattle. Actually, second because RubyConf was held there in 2002. So anyway, so Ben and Shane Becker put together a Cascadia Ruby conference and they announced it recently. It's going to be coming up the first weekend in August in Seattle. So Ben has been an active part of the community. Thank you for visiting my conference, Kevin. You're welcome. I wasn't going to do it myself. I'm trying to decide if I want to do the rest of these. Everyone does the person just next to him. Okay. This is Stephen Becker. He's Canadian. Ask him to say out. That was good. Stephen, let's see. Most recently, Stephen was working. I don't actually have any idea. I think he was a G5, whatever. It doesn't really matter. I was a G5 and it's so bad. So conference sponsors G5, apparently. Awesome, awesome. Thanks. Do I get to talk about Eric? No. I'm going to take organizer prerogative here. The other thing that Becker has done in spite of generally not wanting to claim it, he wrote the first version of R-Spec before turning it over to Dave Estells. Estells had fuck all to do with R-Spec. I'm sorry. Let me set the room and say it here. Shalinsky. Sorry, not Estells. So now I'm going to give the mic back to Becker and let him tell you about Eric. Okay. Eric's from Seattle and he wrote everything you use or something that is required by everything you use. Yes. Yes. How many people love Ho? Everybody. Yes, you do. If you don't love Ho. Get out. Is there anyone who likes Ho that's not from Seattle besides Mike? No. It's not from Seattle. It's from Seattle. Seattle would just tend to say cooler than me in Canada. This is... No. Oh, Kobe. More organizer prerogative. So, yeah, Eric, if you didn't catch the references, he goes by Dr. Brandon on Twitter. I'm right. All right. Well, I don't know what I think. And he also, he maintains Ruby Jams. He's a Ruby core committer. And I hired him once. Once. He's thinking about hiring me again. So... Well, he's... Maybe. So this is Rain and Rain is getting married next week. Let's see. Rain, let's see. Rain spoke last year and then got harassed by a man where he killed two as, say, rather inappropriate things. Unfortunately, he's not here again. And Rain is much happier. I don't know what else to say about Rain. Oh, no. Kobe, let's go first. The purple pimp hat does really well with the orange hair, though. Yes, it would. Let's see. Rain. It took me about a year before I pronounced his name, right? I kept wanting to call him Rain. Rain is currently at, is currently at Living Social. He's done lots of interesting things with Cloud at PHP Fog, where they did a lot of Ruby, at least on the underside of things. Ironically, no. Ironically, no. He's also presented and been active in the community for, I don't know how many years, longer than I have been. And I started in those six. Apparently, apparently someone would know that it's seven years. And he generally hosts the, the last two years as hosted the Think You Can Code presentations at Ruby Company. If you haven't seen those, now I'm going to fit my own company. You can go to confricks.com and look at the talks that were there from previous years. They generally go better than this one is right now. I guarantee they're a lot funnier than this one. This one is not going up there. No. Thank God. There's not even, this isn't even being recorded. Thank God. I'm also not a Ruby core committer. And I don't maintain Ruby chips. And this is Renee, who I've never met before in my life. You met her last night. Before the conference. So I can't really say anything, but if someone else would like to say something, that would be really awesome. Renee lives in Seattle, and she was formerly a Blue Box group. And now she works for herself, which she says is much, much better. The best thing about Renee is if you can get her to start laughing even a little, she's not going to stop until tomorrow. Talking borough. The other thing that Renee has done a tremendous amount of working in the community is an organization called Railsbridge. So she was actually down here the last two days in a brand new workshop yesterday. And for those of you who don't know, Railsbridge is an effort, a group that's designed to help get more women involved with software development, specifically the Ruby and Rails community. So the workshop had one requirement. You either had to be female, or you had to accompany one to the workshop that we have. But have great attendance with that yesterday. So that gives you a brief overview of who they all are. They're also helping the time slot right now that snow has caused to be an issue. To be completely clear, none of us knew about this before last night when we were already drunk. So I apologize on behalf of all of my family and six upper rain. This is completely horrible. You're the one that told me not to do my slides. Yeah, that's true. I have a question. Unless I wasn't paying attention. So the question was, where the hell are Tamara and Randall? And as far as I know, they're being slaggers billing in San Francisco right now. Oh, damn. Precisely the question I asked Tamara last night to be clear. Randall bought me a lot of booze over the years. A lot of booze. I have nothing bad to say about Randall. I have nothing sober around that guy very often. I have a question for you. Whiskey, rocks, or lead? Whatever you want. I like this. Neat personally, but it's up to you. I'm not a big fan of ice. It's straight out the bottle. And it depends on if it's Scotcher Irish Whiskey, really. What are you going to say about Irish Whiskey? This is one of the things America has done better than Canadians have done. Whatever. Are we asking the audience? No, but I think it just provided the segment as cheap. What do you guys think about the new Rails 4? As I like to call it, Rails forever. Anybody out there want to jump in on this? I hear it's coming up around the time the Techsmate 3 comes out. It's coming up around the time the Techsmate 3 comes out. Forever. So I've worked with Aaron Patterson for many years. For about the last two years, he's been working on Rails. And when he started, he had fewer gray hairs. But I think that is for your benefit, because Rails 4 will be amazing. He's also older now. I don't know about that, but if you get older, you get older. Can you stop living facts? Get in the way of the story. So working with Aaron and watching him do Rails, there's a lot of face poems. And then he looks at his sausage. And then he goes and plays with his cat. So that's what Aaron does, too. Does it do any order? Sometimes it goes Rails, sausage, cat, sausage. I don't know what he does. And then he goes and plays with his sausage. I haven't seen him actually play with the sausage yet. No, he's got that. Not in person. He's got a case. I'm talking about matching the sausage with the record. What's the case with sausage? That's a little off the panel. Can you guys open up with this? His voice is pretty whiskey. That's more questions than Aaron. I like the Florida recognize Brian Day. Fine, Brian. What do you guys want to see in Rails Fall? Isn't that the question I just fucking asked? No. What do you want to see in Rails Fall to come? I want to see people using it. No, that's kidding. The world right now is all between, like, let's upgrade this Rails 2 app to a Rails 3 app. And it's become, you know, a bit of a pain in the ass in some cases. And so for the future, and I'm being completely serious here, I want people to focus on good quality code, losing your coupling a little bit, so that when you have to change frameworks, it's not a big, a huge pain in the ass. And that's what I would like to see for Rails 4. I know that's a pipe dreamer. Sorry, I killed that. Okay, we'll answer the question. Yeah, you. Can you guys use Ruby for anything? Do you have another one? Eric, actually. Actually, I was about to say in the last question, I haven't ridden any Rails since, like, 2006. I've been just pure Ruby back in stuff for the most part since then. Occasionally, we'll maintain a Rails app wherever I'm working, but most of the time, yeah, I'm just writing Ruby. You're right. Right now, I work for Living Social. And, yeah, we're building, the funny thing to bring it back to Tamer shit is we're actually moving towards a service-oriented architecture using Ruby for the back-end services, some of them are HGDP, some of them aren't. The HGDP ones for the most part aren't Rails. So, anyway, serious answer. Sorry. I haven't done much Rails either in the last two years, but I'm mostly committing on RDoC, RubyGems, Rake, Ruby, whatever. All the important stuff. All the stuff, all the back-end ecosystem stuff that everything else depends on. But also, like, I use Ruby to do all the random, fun programming stuff I want to do as well. Like, I've got RubyScript to control my fireplace. That's pretty sweet. I use Ruby to work on a little project called Puppet, which is used by a lot of organizations that you've probably heard of, like New York Stock Exchange. And for the record, when their service went down, that was not Puppet's fault. So Puppet is a configuration management tool that's managing possibly on the order of 100,000 or more machines around the world in hundreds or thousands of organizations, a lot of universities. It's as old as Rails, it's as big as Rails, and it's used in far more real-world situations. It's all, it's about, I don't want to get into an argument about that. It's almost as old as Rails. It's also almost as good as the adventure. And it's almost as good as Chef. In the same way that it's almost as old as Rails. Well, so I was going to say, Chef Scripts have been using a lot to set up servers in contrast to Puppet, but like a little better. They are both Ruby, so it's all Ruby with not Rails. Also I was going to say, when we played at the Ed, we know chips that you can program on Ruby. And they're really cool. So, we're the one, they're awesome. There are a lot of things you can't do, Ruby. Yeah. Yeah, it's trying to complete it. Exactly. That's stupid, you should feel stupid. I wonder if the other one is trying to complete it. New question, right? So, what are the things you want to be, that you should know? The panel is talking about where I heard him. What are the things in Ruby that people should know that they don't know? Ben String. Obviously. Call CC. Oh, for Christ's sake. Go watch the second so you think you can code. Ben String is not, it's not worth spending any mental energy on. I mean, for you. I don't mind, but for you it's not worth it. Oh, sure. Okay, fine. Serious answers. I wish more people understood the difference and extend and include. Oh, I'm totally with you. I would like to see less abuse of inheritance. We've only got a few minutes. I would like for people to use better names for classes and modules. Base, instance methods, and class methods. Yes, it's a module. It contains methods, asshole. Name it something smart. So, I want people to use fewer complicated mocking frameworks and just use DEF. Zero is good. Yes. DEF. You just use DEF. Maybe class.new. We don't want to throw that in there, but DEF. Yeah. Shit, anonymous classes. I wish more people did that. I did that recently, so there you go. What are we on? What are we on this time? I'm going. I need to answer. Crap. What's your programming? Pretty cool. Yeah, more people did that. Tell your friends. Yeah, tell your friends. Yes, over here. The question is, if you could rename the splat operator, what would you rename it to? Astros. What's wrong with splat? Nothing. Blah. What would you call it? I would call it the thing that sometimes turns a raise into not a raise, and sometimes turns not a raise into a raise. Operator. Base argument. Don't let it decor. Back to ho is unsure we all have some time. Never mind. So, I wrote a blog post about this, so you can get a lengthy argument, but for everyone who has not read it, there was a lovely person who decided that Ruby should have man pages shipped with him. I think this is a fantastic idea. More documentation is great. However, the way that he did it to package it with your gem was you would require this file in the library in your gem spec, and then it would go in monkey patch, Ruby gems, and throw files in there, kind of like, well, no, the dependency being like, oh, rake can do for you, and then you just have a rake task, and you say, oh, well, this depends on the package task, depends on this, put the stuff in the right spot, done. And then you can use it with whatever you want. So, you know, negative points for simplifying things, we all use rails. Yeah, but you're going to protect people just from what you say they should. You heard it, come on down. Yeah, sorry, when we do so you think you can code at RubyConf, we make it really clear up front that you should not listen to anything we say. And I guess we failed to do that today, so sorry. You don't know, we have an empty chair if you want it. Yeah! Also, there's lots of shit in the gem spec that you shouldn't touch, and you don't know which one it is, and I can tell you, but you won't read it, because I've been doing this way too long, and I know people don't read it. So, don't do that. Don't read it? Don't read the documentation. Got you. You already won. Because more documentation is good, so don't read it. So, I have a question, it's a follow up to the, what do we wish people used more in Ruby, which is, what do we wish people used less in Ruby? Okay. Starting with you then. Did I give you some time? Yes. Nope. Ruby 1A, Ruby Enterprise Edition. Thank you, Kevin. Less? Less. Oh, meta programming. Yeah. Class arrow arrow cell. I hate that shit. That drives me crazy. Rescue from the inception. Yes. Rescue nail. Yeah, yeah. Trailing rescue nails. That's gross. So, like, you know, when you call something and you don't want it to blow up, so you put rescue nail at the end, so it just returns nail instead of blowing up. Instead of actually telling you that you really had an exceptional case. Yeah. There's this law called the meter. I would like people to do less of that. Less to meter? No, less of the... Less throwing away exceptions that are being called. The problem with that case is that often you may have another exception that gets thrown for some other reason that you are swallowing all exceptions. If you just rescued, like, IO error or whatever the error you are trying to rescue is, now you do not swallow exceptions. The big problem with that is that it breaks the chain of evidence. So if you're getting it back crazy and you're ready to figure out where something is wrong, rescue nail just stops that chain and then you're stuck in nowhere. And you have no way to figure out where to go next if you know what's wrong. And the only way to figure it out is to remove the rescue nail. But if you need to do that, why is it there in the first place? Maybe you should just not cause errors that you expect to happen. Absolutely. Just don't ever do it. Sorry. Sorry, we got into teaching there again. Anybody have a question that doesn't have a real answer? Yes. I think the documentation is doing it more as better. I have many, many invariant opinions on this. So I have a question just sort of to frame this a little bit. Why do you want know our doctor and know our eye? Why do you not want documentation? It's like three minutes to it. Okay. So should the documentation be generated ahead of time and shipped with the gem that way? No. Oh, that's awesome if you have an internet connection, which I almost never do. Well, how do you use all the gems without the gem? Level install local? I'm not kidding. The problem that I have know our doctor and know our eye is that people are installing stuff with them documentation. Okay. And I don't have a problem with this on a per project on a local basis. For this project, I don't want, I just said project, you are welcome. On this project, I don't want documentation because I have it elsewhere at the system level. And that's okay. There's nothing wrong with that. That should be explicit. When you're in the default in RubyGems should be always to install documentation because I want you to have the assembly who writes documentation from time to time. I want you to read it. Gem help and I think has how to go into it off by default. How many of you have ever actually use the documentation that is generated when you install a gem? So I have used it and it's still the wrong default. Right. If you need it, go generate. It's fine. The problem is, the problem is that we are basically making everyone pay a tax or something that I use 0.5% of the time. But everyone has to pay the tax all the time and nobody understands why. Most people have never used that documentation. The French case though. You're the one percent that uses that documentation that's installed. I'm the one percent that uses that documentation. I didn't count one percent at hand. If I'm the one percent that uses that documentation, I'm talking about the documentation in general. I'm talking about the documentation that's installed. But he just has to have the hands on it. So you can always generate that later. So the question is, when a new user does gem install rails, somebody who never used rails before and he types in pseudo gem install rails because that's what someone told him to do. Now they have to wait five minutes to get everything up and running. We should try to make that amount of time be left. If the solution to that is to make our doc factory, that's great. But the fact of the matter is that today, we are making people wait an extremely long amount of time to get up and running. We should not. Yeah, that's good. So comment says, successfully install n gems. You can use those gems. You need to control Z and Z down. Or if you don't want to, just turn it off. But I'm not going to change the default because I don't want to. Brian Davis, tell you not to change the default or is that your personal feelings? Okay, we can do that. Brian Davis has kittens. Eric doesn't have any kittens. I'm not real puppy. I'm not a puppy. That's a dog. You're not worthy of sympathy. It's a dog, dude. I think the bottom line is that documentation is an advanced feature. And advanced people know how to install it. And the people who aren't the advanced users aren't going to use it anyway. Let's talk about other things now. Not documentation but using the documentation that Ruby gem is installed in your system. Why don't we now talk about this anymore? We have a repeat of what we know about documentation. How do you guys... Alright, fine. Never mind. I'm patched in. Looking at it right now. The parser is amazing. We'll get it. Cool story, bro. How do you guys feel about turning the standard library into gems? And also, Steve, can you pronounce JavaScript? There you go. Java script. For you people because you put Ws in it. Java script. Where did all these extra Ws come from? Where did the story go, bro? So, okay, what was the question again? Sorry. No, we said Mapa. This one's going to blow your mind. I'm going to Vivachi in Seattle to hang out with these pundits. You know what? That's a good question, actually. I just want you to be consistent. I'm all about consistency. You can be wrong, bro. I learned that word by hearing it so that you are absolutely correct. When I go to Vivachi, I order a latte. And some pasta. No, I say a big one. I think the technical phrase is a big one, eh? Steve, what was your other question? Standard library is a gem. Great, great. Yes, and I need to go if I'm not here about that. So, the thing that's hard about that is that the standard library right now is actually pretty hard to pin the specific versions of Ruby. So, we could fix that but today the way that the standard library happens to be developed is that every time a feature changes in Ruby that necessitates changes in the standard library, they just go change it. And then that thing that has been changed no longer works on older versions, and it works. So, what you would have to do is you would have to have... People would have to treat the standard library like they treat any other gem which is... No. Backwards. Sometimes you get backward things. Okay, there we go. Things like encodings probably shouldn't be backwarded. When it's dead, it's fine. We've got another couple of months on the clock, but... Whatever feature is going to add in 2.0 may not be backwardable. The point is that up until now the latest standard library has been developed is very locked to specific versions and that would have to change. Question. I got one. It's for Mr. Baker. Who do you prefer, Terrence or Phillip? I'm not going to talk about shit. Am I correct? No, they are not from Canada. Yeah, they are from Canada. I never giggle like that. Yes. When you open photos, do you probably clap your head? I don't think so. Are you sad at the news? I do my best. She's really not going to stop. Alright, I've got a... I was just looking at the schedule. And we've gotten Yehuda scheduled at 3.30 for the closing keynote for today. We've actually scheduled a fairly long break after this talk. Would that be a Yehuda and Steve game match? Well, I wanted to take this back for contrary to Ben, who is all about not educating. I've got a couple of questions that I want to ask. All I've got these guys up here. For the people in the audience, how many of you have actually contributed to an open source project? How many of you maintain an open source project? Because one of the dynamics that I've seen and had some interaction with between Yehuda and Eric and Ryan and watching things come together between Rails and Merb and some of the things that happened there. There's a lot of passion that's required to generate software and a lot of effort and hours and people's lives that go into creating the open source work that we all participate in and benefit from. There are consistently, and you get this with any time you take a fairly smart set of people and say work together under your own cooperative format. So you get lots of clashing. But the point that Eric was making earlier about Aaron Patterson developing gray hairs is so Aaron came to his boss at the time while we were all working at AT&T Interactive and basically put together a proposal that said it had a pie graph that said I spend eight hours a day working for AT&T Interactive. I spend four or five hours a day working on open source software and I think there's two more slots in there. I don't remember exactly what they were. One had to do with sleep and the other one was life or something. And then he proposed another graph that said what I would like this to be is 12 hours a day of open source. And that's effectively what he got. That's why his hair is going gray. And that's exactly it. So one of the things is there's a ton of effort that goes into this stuff. I generally, for those of you who don't know me, I don't write a lot of code and that's because I've written enough code in Ryan and Eric's presence to know that I'm better off hiring other people to get my code written. So the big piece and one of the things that I've tried to do and one of the reasons why I'm going from G5 which is a smaller vocally ran startup to AT&T which is where I'm unemployed at the moment, but I will more than likely be inside of AT&T in the not too distant future. One of the reasons for that is because they represent a very large pool of resources a.k.a. a very large pool of money and a very large pool of technical resources. And you've now got me on my diatribe. So if you want me to stop raise your hand. No, I like to speak your hand. Walk on. Alright, so one of the things that I believe in and one of the things that I'm trying to do by going back into AT&T is open source software is not free. And for every one of you who have released a project, you've paid part of that cost. And part of what we're trying to do and part of what I'm trying to do at AT&T and what we've accomplished at AT&T Interactive where I believe this is a true statement and Eric can correct me but Eric and Ryan now at this point are pretty much doing close to 100% of their time is also out of open source software. So we've now got Interactive, basically employees on that team, three engineers working on open source projects full time. They do not have other delivery responsibilities. When Salesforce.com bought Paroku, they then went out and hired Maps and they got other contributors. No boo. Who are also in hiring them their job descriptions and what they were doing did not change. Actually I guess job Maps has a new title but his effective role did not change. So we were making inroads with a lot of corporations or some corporations to help fund open source software. So instead of paying hundreds of thousands of dollars a year to license B.E.A. or WebLogic or one of the other large job frameworks we're shifting and trying to shift the corporate mentality to the point where open source isn't free. For small companies you end up letting your guys work on or your people work on open source software with some portion of their time and release things that they create to benefit your company that don't necessarily have intellectual property value to your company but do facilitate software development in general and let them release that stuff because it benefits the community at large and the only way that the open source community is going to continue to grow and continue to get healthy and I think this applies to software development in general is by spreading that attitude and part of it to Eric and I think Ray said this also is Aaron is older now. Time does flow, we all get older. Eventually you may be an intern now you may be an associate software engineer you may be a senior engineer down the road you're going to end up running your own company owning your own company being a director in a larger company being a principal architect in a larger company keep this in mind keep the fact that open source software is not free in mind because otherwise there is a chance that the open source environment collapses but it does, we go back to a proprietary world which in my opinion is not a very pretty choice so part of the software craftsmanship part of this movement is to continue to push that whether it's your own personal contribution you do through your open source projects at home or it's something you can do as part of your workforce continue to push to make that happen and then the part that I started on is there are going to be disagreements there was the Ruby gems and what I read is slime gems which was actually a slim gem issue there's going to be some degree of drama in the community around some of these things think about what you're saying think about how you're saying it remember that some of the people that you were arguing with do put a lot of time into this you put a lot of time into this a lot of the times we have to figure out how to just get past those pieces some of them is accepting some of them you don't want to accept because it's wrong and that's why we work things you create an additional version and fragmentation in my opinion is not horribly bad because generally what happens is in the case of Rails and Mirv they eventually came back together but they did that because there was some actual hard long thought that went into what happens if we continue down the major fragmented road with those two frameworks so I'm going to give the mic to Yehuda here for a minute but anyway the big piece is continue doing what you're doing with open source continue trying to make yourself better continue trying to make those around you better it's not utopian it serves your own best interest I'm not a big fan of work doing everything for others I do a lot of this stuff for my own benefit so was that all good? I just kind of want to reiterate what you were saying in general open source software is harder than it looks and in general there are actual design differences that cause the disagreements and I think in general what I usually try to do is try to understand what there's either assumptions or design differences that exist and try to understand those it's very easy to get up and say like this is crazy these people are doing retired things that's easy and I think in general people spend some thousands of hours of time writing software are usually not doing retired things they may have different values than you for instance I have very different values from the node community but I understand what their values are and identifying why my values and their values are different allows me to more easily either decide when to argue or when to just be like I think in general when there are fights like that's basically why Mervin Rails worked is that like there was a fight we sat down and said ok what are the actual differences it turned out that the differences and values were mostly like prioritization questions and adding a bunch more resources basically solve the prioritization problem that's basically the core thing to happen there so I think it's better to figure out what the values the axioms that people have are than to just say like this person The thing about MIRB is that we had very low resources. We had specific goals that we wanted to achieve and I think Matt's point about it was about performance. There have definitely been performance regressions, especially around active record. I think people don't usually do benchmarks of just action back, which actually has pretty good performance characteristics. But when you throw an active record, there were like pretty crazy regressions. But in the larger overall question of like, people who write plugins should have a more solid grant system. I think that for me that was the big thing. People who are doing advanced stuff, they should have a more solid grant stand on. They shouldn't be on quicksand, which was the case in Rails 2. I think we got to the point where the API that plugins use is actually decently well defined now for most cases. It's obviously not perfect, but the fact that MIRB, when people upgrade to Rails 3.2, usually active record plugins are not great. Usually, action controller plugins are not great. Dan? I think so. You can tell me if I'm correct or if I'm wrong, but my feeling at this point is that active record has gotten most of the interesting features that were in that mapper that I cared about. Yeah, it has gotten a lot of the features. I don't know if we're necessarily going to benefit from our merger right now. We're actually looking at doing some stuff, actually a true data mapper, where the objects are actually just normal objects and your mapper is separate, so you can test it separately. Oh, yes. Yeah, thank you. Nice. So the way to emerge in general is if the disagreements are resource constraints, then you can fix it with the merge, right? That basically, what happened with Rails is that Rails was like, we would love to make to add more modularity, but we're basically, we're all a bunch of volunteers and we have no full-time. An engineer was like, seems good, we'll put two full-time people on it. Suddenly, there was no more resource constraint problem about being to be more modular, right? And that meant that the actual points of contention didn't really exist anymore. One needs a higher dam. This is a little bit... Hold on, hold on. I'm going to buy Dan a beer for that. Colton, can you get Dan a beer? That's a nice thing. Do you get yourself a beer? I'm going to buy Dan a beer. Get Colton a beer, if you wouldn't mind. No, that's good. All right. Thank you. Oh, if you have something unrelated, do you mind if I just pop in real quick first? No. So how many people actually get paid, say, to do open source maybe more than 20% of the time? How many would like to? Why haven't you asked your boss if you can? Why haven't you just done it? Yeah, seriously, just do it. What's stopping you? Yeah. I mean, seriously, somebody tell me what's stopping you. A lot of employees that are working on projects are stuck in a corporate environment that don't have the luxury of contributing what they're producing to open source. Like for me, for instance, I can contribute to stuff that I produce at work, get paid for it, and then make it open source. And not a lot of people have the luxury of... A lot of employers want to lock down everything that their employees produce. I've worked in that environment and I've asked my boss and I've done permission. Anything I create is the intellectual property of my employer. Yeah, but... So is mine. So is mine. So depending on your actual work agreement with your employer. Yeah, but I mean, the point I'm making is that there's no reason why that can't also be open source. I release a ton of code that's copyright-living social. It's really not that easy. A lot of the people who are contributing open source are getting paid to do so. The question is the legal environment, right? I think so. Are you guys using open source projects in your... Not especially, but when I write stuff, usually it depends. Well, if you're using an open source product, at least because you go back to that. I mean... I'm waiting for a lot of us who are writing applications. A lot of us are working in real. A lot of the code is not so interesting. For some of the code that is interesting, at least for me lately, it's pretty damn proprietary. I think why I'm clear, really, is not the one I'm giving out. So then why is this stuff that's not interesting, not interesting? It's kind of boilerplate. Can't quite be automated? There's almost both three clubs. I mean, there's an area... You have to do some serious... I heard it goes... I appreciate it. But it's not always... Yes? No, I agree. So I got to where I am today by doing a lot of open source stuff. And sometimes it was just like, oh, we're working on this thing. It's kind of interesting. So I'm just... It's generic enough that everybody else should be able to do this. And how many people have heard of AR Mailer? So I wrote that, and I extracted it out of 43 Things Codebase because I was like, well, this is something that we needed because Rails didn't provide a good enough way to send emails. So I was like, well, we'll just put it in the database and then we'll have another thing that sends it from the database and then it can be completely decoupled. Page won't slow down. And I didn't ask any permission. I just did it. Nobody cared. But I was working with a company that was small and didn't really care what I did. But I think there's a lot of it where you can just be like, this is a small thing, especially tiny things. You just do it. And don't ask permission. And, you know, hey, did you... If they fire you for a reason like that, you probably don't want to work there. Yeah, yeah, exactly. If you get fired, there's probably a good sign that that's not a good place to work for. That family. Well, yeah. A lot of places are hiring. Yes. Who has an employer right now that will not let you open to a shit that doesn't matter to your product, that does not deliver specific business value to you, but it's useful to the community. So it usually has nothing to do with that, right? It usually has to do with the fact that the stuff you work on at work time is owned by your employer. And so there's a bureaucracy by which you have to find someone who will give you permission to do it. I didn't ask. Yeah. So in a small company, you can get away with it. You're a huge company. It's even less. I didn't ask. I haven't asked. I just asked to work on open source at AT&T. So there's a problem. So now what we're basically doing is we're introducing open source into the wild that's owned by people who have not given permission to license it. I agree with you completely that that's not a problem. No, so even if you don't care about whether it's theft or not, what you're doing is you are actually, you are making the choice to license something on it. You are basically giving up the copyright of your employer. And I personally am very fearful of the day where that nuclear bomb explodes. I feel like that open source is full of that and I'm scared of it. Well, that's a good CEO problem. I agree completely that that's not okay, but that should not stop anybody from asking permission. Ask your manager. Have your manager just push on it until you get permission, and you will. If you can't sell it to your management, then it's not valuable to the company to do so. But most of the time for this generic stuff that costs a lot of money to maintain that other people can help you maintain, that's beneficial to the company anyway. I think to be able to sell it to the CEO or it's not valuable to the company. I suspect that we're probably on a good falling ground that we would like to be able to release things into the open source that we do at work that are not proprietary. And you guys are right that there are policies in place that often prevent you from doing that at work in those environments. But these guys are right that we as people in this market in the Ruby job market as sellers of our services in a very good place, because it's such a hot market, because it's such a seller's market, and we're in a stronger negotiating position. We can make changes to those policies far more effectively today than we could, say, five or ten years ago. And those policies are not going to change unless we work towards changing them. I don't think subverting them is correct, but if we're not trying to change them, you can't complain that they're not changing. So we're going to company in, basically Vancouver called First Bay, probably I haven't heard of because we don't like Canadians. And so we move money between, we do a lot of the services that pay to help us, but between businesses. And so one of the things that happened recently, a year ago, I guess, we realized, or before I joined the team, the team realized that a lot of what we do is crud. It's just the basic, let's list some data, let's edit the data, so on and so forth. And so they created a project called Active Admin. The entire web interface of our application is Active Admin. That gives us, the rest of us, the ability to focus on what we do, which is our core competency, which is actually moving large sums of money around every single night. And so it wasn't a hard sell to the CEO because we've gotten bug fixes from the community, we've gotten help maintaining it from the community, we've gotten improvements, and we've got lots of other people using this thing, especially if you're working a small company that has a small user base. If you have a small piece of your code and you have 100 users or even 1,000 users, and you have a piece of code and 1,000 users at most are using that, if you have 1,000 users. But if you release it as open source, unlimited number of users can use that piece of code. It can exercise it. They can find bugs, they can add improvements, they can help you. I don't think there's any reason why you can't sell this to a CEO. There should be no reason why. Yeah. In a company, there's hiring reputation. Absolutely. When we are looking at people, we look at new folks based on their open source contributions as well. Oh, sorry. The question, the seed was that people are valued, but hiring new people, they're valuing the contributions to the community. So, if people don't even work there, they're not allowed to work with that person? Yeah. Right. So, that's the other side of it. If somebody is active in the open source community, people don't want to work there. It's a recruiting budget. I worked at ThoughtWorks for a little while. That sucked. But Martin Fowler is made out of the recruiting budget. That's what I'm paid out of. Exactly. So, Ryan. And Aaron. And Aaron. In the back. So, the one breakdown that I see with this, though, is that you're assuming that your CEO, or in my case, people hire up, even understand what open source is. It's like Congress voting on SOPA. I mean, they have no idea what you're saying. You should be able to explain this to them. Open source is not rocket surgery. So, it is to it. If you have to talk to a lawyer, whose head is stuck up a certain orifice, it makes it difficult. This is the country that invented the assembly line and the reasonable part. Here's the thing. If they are recently intelligent people, you can get through to them. It may take some time. You may have to find new ways to frame it. But it's possible. I've seen it done a million times. There's a book all about this. I don't get serious. I don't get serious. So, I've gone through this a couple of times now. When I started at AT&T Interactive, which is where Ryan and Aaron work, is a wholly owned subsidiary of AT&T. And as such, there is a hand-waving agreement between a guy who runs the division that Interactive is part of. So, AT&T Interactive is the only company where the CEO reports to the CEO, who reports to the CEO, who reports to the CEO. So, there's literally four layers of chief executive officers. So, I know what you're talking about in the bureaucracy, but Interactive had this hand-waving agreement which was basically the guy at the head of the division had the agreement with the CTO at AT&T that said, Interactive can break a lot of rules and because you're not on the trusted telecom network, we're going to let you do that. Now, when, because I left Interactive and came to work for G5, and Chris Kragels over here in the corner, who is a CTO of G5, one of the things that was a real pitch for me to go to G5 was when they'd gone and did the funding and brought in the venture money, Chris went through and looked at the entire code base and basically said, all of the code that's required to run our application, 40% of it's coming from open source. The other 60%, or I could be wrong on the numbers, the other 60% is stuff that we've developed in-house. Because of that, if you want to attract the right talent in the company, we have to have some commitment to supporting the open source effort. Now, if you're in an organization where the CEO barely knows that your department exists or if you're in an entertainment company in LA where IT is a cost center, it's not intellectual property rights, then the battle is going to be hard. The battle is going to be, may very well be impossible. And to your point, yeah, we all have families. Most of us work and we do this because we're passionate about it. The reason you're here, I don't know, how many people are here paid for this out of their own pocket? So you've still got a big chunk of this room at this conference because you care enough to spend the money and to spend your time to come down here. How many people here are on vacation right now? So you've got a little bit of cooperation from your employers. So it is a struggle. The other piece I was talking about though, I left AT&T Interactive because my boss went from being the CTO of Interactive to taking a VP position at AT&T Corporate. And I was supposed to move with him and my teams were supposed to move with us. And if that transition had gone through, what Ryan and Eric and Aaron do as part of their daily job was a terminatable offense inside of AT&T Corporate because AT&T had policies within the, this is what they call the CTO organization. They had policies that said you can use open source software if it's on this white list. And you can fill out exception paperwork to get onto the white list. And we figured out how to manipulate the system so that you quit putting down version numbers and you only put major version numbers so you didn't have to go back through the process every time. But that was their idea of open source. You could contribute a patch back to an open source project after legal review of the code. Legal review of the code. There was no concept within that part of the organization of releasing an open source project. It hadn't occurred to them and it wasn't in their mindset to take a project and set it loose in a lot to give up an intellectual property grant. This is the other fun part. If you don't know, Graphiz is released by AT&T. Graphiz is released by AT&T Labs. So there are lots of segments within the larger AT&T organization who managed to get exceptions in how this behavior happens. And the team that I'm going to be rejoining, if you didn't see the announcement, AT&T officially joined the OpenStack community and is now a partner as part of it. I'm not sure what the terminology is, I don't research it, but they have actually put the AT&T logo, which the folks in the branding department literally look at. If our logo shows up on your website, it's worth this much money to you. Do they call it the Death Star? They do not call it the Death Star. We have graphics of the Death Star, superimposed on the logo and it's awesome. Anyway, so there are absolute issues with doing this within large companies, within small companies where the value of what you're doing is not always there or is not always perceived. Part of it, and part of it is if you can't, it's that maximum, if you can't change your job, change your job, that's not an easy answer and it's not always an easy answer and sometimes it's not the right answer. I mean, Wozniak did it with the original Apple One when he went to HP with his design and basically said, do you guys want this? If not, can I have permission? If you're not going to do anything with it, can I have the permission to release it or go do my own thing with it? And I think that's the main thing is if you've got something that you think is going to be valuable to the community, at least have that discussion. Try to have that discussion if you can, which is this represents no intellectual property value to the company. If you want to do something more with it and you want to help put resources behind it, great, it's valuable. It's valuable to me, I'm passionate about it, I care about it. And if you don't want to own it and help beat it and nourish it, then let me let it go. Let me put it into the community. Don't just kill it. Some people aren't going to get that, they aren't going to care, they're going to tell you to go back to your cube and leave them alone. And part of that comes back to that's when you should really be looking, whether it's Tim and Crawford's idea of just going to work for yourself or looking for another employer. There are a lot of people hiring, there are a lot of caveats on hiring. I had the discussion with, when Eric said we're trying to try to hire him again, we had a discussion the other day about whether or not there was any value in moving them from interactive to AT&T. We're not done with that discussion, but right now they're in a better place where they're being paid out of an engineering, marketing, recruiting budget. If they move to my team, I need them to deliver stuff that is proprietary and can't be open source. So there would be some loss in the amount of time they could spend on open source. That's more or less on the table at the moment. But there's a lot to this process and I'm probably running on that, huh? It's 3.15. Okay, so we've got, let's take a 15-minute break. I can have one other. Sure. There are some companies who absolutely will refuse to allow you to, so an alternative that could be to allowing their employers to have five hours a week. Yeah, I mean the point, the thing is, you just have to ask, and it's important to you ask, and if they say no, find a new job. It's not like quit immediately, but start looking for a job they can fulfill. Start attending conferences, start talking to our user groups, local groups, talk to other people. There are lots and lots of people in the community, and there are lots of people in this room who are looking for people who give a rat's ass about what you do with your software. I don't care about it. You'll be in point in 15 minutes. Yes. Alright, let's keep your hands up for just a minute. The question was, who's in companies that are hiring? Oh, yeah. Okay, now for the next question is, if you are a hiring manager who is hiring, keep your hands up. Okay, look around the room if you are not happy with where you're at. There are faces here who are responsible for bringing new people onto teams who probably have a better understanding of open source than your current employer. If you're in that room. Alright, well, thank you all for your participation. We're going to take the 15 minute break, and then we're going to come back, and you're just going to give us our cue.