 Okay, let's start and let's just go down the line and everybody introduce yourself. Like, are those mics working? Okay, go ahead, try again. I'm Jeremy, Basecamp. That's what? I'm Aaron, I'm not a pony. I'm Godfrey. I'm Santiago, I'm the co-founder and CEO of Yorgz. I'm Guillermo, I'm from Colombia and I work in a company named Rhype. Hi, I'm Andrew, I'm Unboxed CTO and I'm Pixel Trek, some GitHub. Okay, I think, you know, we don't have a ton of time, so I thought what I would do is we talk a lot about, we could talk a little bit about kind of like upcoming changes and stuff, but I thought sort of going along with what we talked about during Ruby Heroes, we talked a little bit about how you ended up in, on Grail's Core. I think that's really interesting to a lot of people. So why don't we go, we'll go back this direction. How long have you been on Rails Core and how, like, how did that come about? Did you just, you know, just take a minute or so? I've been Rails Core since like 2012 and that basically came about through just contributing to Rails. So I've been contributing to Rails since 2007, where I contributed to Rails was, I had a problem with my app, broken Rails, fixed it in my app. Next version of Rails could have broke my app, I thought. But they fixed this in Rails, so it's a message of passion, just gradually worked from there. That's basically it. Okay, yeah, like Andrew, I started contributing to Rails, looking for the problems and the bugs that I found in my app. Yeah, I've seen that every new version of Rails started to break my app, so I need to fix this. And I am part of the Rails Core since like three years. Okay, I'm part of the Rails Core since 2010, I think, and I started to get involved with Rails development, basically based on issues I had in my applications. Also, once I joined to a hackfest or something like that, that happened during a weekend, like triaging the issue tracker and working on that, and that way I get involved with all the stuff. So we've probably noticed a trend by now, like everyone knows, I started contributing to Rails by finding bugs in my own application, like, why isn't this work? And I was like, well, maybe I can just fix it. So I brought patch to fix it, and then, like, some years ago, I came to the Rails Core, this hour, made Aaron merge my patch, and I started doing more, and that's basically it. So if you haven't done that already, we're still here, and you can still do that. My turn. You can say answer all of them, and that's okay. Yeah, so there were no bugs in my application. I just wandered in off the street. I don't know why am I here. How long have you been on Rails Core? I have no idea. I don't know. How long have I been on the Rails? Maybe five years. Maybe. Four years or five years. Seems legit. I'll echo the pattern. That's how I got involved in Rails, too. When Rails was first coming out and trying to port applications I'd written in Ruby and PHP and Java to do new development in Rails and finding missing pieces. And that's what I've seen with everybody coming into Rails, the consistency of noticing issues, addressing them, following up on them. It's kind of interesting because it seems like an easy thing, but it's also a surprisingly rare thing. The long tail of contributors. If you go to contributors.rubionrails.org, there are thousands of people who have done one thing, which is awesome. But doing two things or three things already gets you into kind of a rarefied territory, so I encourage it. So that's a good transition to my next question. We'll start with Jeremy. You probably have most to say about this. We'll pull the curtain back a little bit for a moment. Do you maybe say what the process was for introducing new people into Rails Core? Is it just like a discussion amongst all of Rails Core? Is it a formal thing or is it just a very informal process? It's very informal. It's gotten more formal. Sometimes I feel like people really introduce themselves. It's like the way that you fix issues and it's like people are there on the door. They're already in the core team essentially just by virtue of their contributions. It's like the way Aaron came into the core team. He was doing things and it became more of an issue to have him not on the core team. Basically if you hassle the other people too much ... Okay, so let's see. You've been on Rails Core for various amounts of time and one way that Rails stays fresh is change. It's not sticking with one thing. For instance probably not many people are doing RGS anymore. So this is sort of a two-part question and we can have everybody answer both parts at once. Probably what I'll say is since you've been on Rails Core the most interesting change that you've seen happen while you've been on Rails Core and the most interesting change that you're excited about coming up. I won't make anyone start because I've got a lot of like ... Does anyone want to start on this question? The most exciting thing that I'm looking forward to is Action Cable because I have no idea what the hell it is. What about since you've been on Core? What's one of the most interesting things that you've seen, maybe you did it or maybe you saw someone else do it since you've been on Rails Core? I don't know. All the work I did with adequate record is probably my favorite stuff that I worked on. Adequate record. Yeah, I think probably the most important thing to me is to focus on performance and measurement. We're kind of making now introducing all these benchmarks and then monitoring the versions different performance between versions and then hopefully make Rails more like the pastest version of Rails. What about interesting things in the past? I think back when you were like, finally, we're doing this. The Rails 2.3 to 3 jump was probably the most interesting thing. The thing that kind of got me contributing more to Rails. So that was kind of my most interesting for the past. Bundler and Asset Pipeline. These are things that people love to hate and it's for the most part turned out to be incredibly positive and constructive contributions to the way that I build apps. I remember going through Bundler issues and now I love it. I could not live without it. It's great for deployment and it's one of the kinds of things that I think everybody having been kind of patient through its growing pain really paid off. I think a shout out to somebody who's not here, Raphael, who handles most of our new people. He's our first contact for most people with Rails. New contributions is seeing Raphael comment on the pull request. He is our patch monster, our pull request monster, our comment monster, and our welcoming committee. So shout out to him. He's probably the best thing that's happened in the past five years. This is a just in time question generation. So sometimes I have to do a little compiler pause. Are you taking questions from the Twitter so that what's happening? No, but if you want to tweet some questions at me right now, I'll put them in the queue. So we can do that too. We have a whole slew of people who are all of a sudden wandering in. I don't know where they're at all morning, but come on in people of the hallway. Um, Guillermo Santiago, I've read anything about interesting things that you've seen change or that you're excited about? Yeah, I'm really excited about the work that Santiago is doing in the Rails API project. Finally, we're including the next version. So I want to congratulate Santiago. No, I'm excited about the performance of work we have been doing also. The integration test being faster and all that stuff. And having Ruby 2.2 as a requirement to run our applications. And also about Rails API, not only because I didn't work, but also because at Rails we work with several different kind of applications that some of them use Ember as in the client side. And this will enable I tend to think that this will enable these kind of applications to be first set in Rails. I must. Everyone else is talking about code changes, so I guess I'll talk about something else. Personally, I'm most excited and I've been pretty happy about some of the changes around the ecosystem, some process that we have. We have a much better process of testing our releases these days like we have. We test out latest version of Rails with discourse and with other open source projects. And Rust.Rail has been doing a music job managing the issue tracker. We now have a weekly newsletter if you don't know about what goes into Rails every week and stuff like that. I think I'm pretty excited about some of the changes around the ecosystem making everything better. That's excellent. This is a more maybe a question for me than anybody else, so I've got the mic, so suck it. I know that when Rails progressed from two to three, there was a performance regression and a whole bunch of things because there was a whole bunch more code, whole bunch more sound ways of doing things. Does it feel like and maybe this was true last year when I think about it, that all of those things have been made up now and now it's sort of like all always better performance than previous versions. Does that make sense? Any thoughts there? I think we have much better tools now to monitor that. So you can now answer that question instead of... I think we just didn't know before in the two point three to three change. It wasn't until somebody kind of filed an issue saying, that's a record of five times slower than we did. I think there's also what we see is that the questions that are easy to ask are the ones that are easier to answer too. The active record gets a lot of attention because it's really glaring when there are regressions in it and the kinds of regressions that occur are often like in plus one or worse. So they're in your face and a situation like that is because there was some design change and less often because there was a regression in some micro-optimization that somebody might not have noticed. But we can often miss the things that affect the performance of our applications. What are the choices that we're making that makes the person who's using the application, what's their experience and how does Rails change that? Some things like asset pipeline can be kind of hidden stars and making things like delivering your entire application faster for real people rather than faster in our benchmarks. Well the problem is like the surface area at Rails' API surface area is so large that even if we have performance benchmarks we're not going to catch everything. There will be some use case that somebody has in their application that we didn't have a benchmark for and then eventually it's like that might regress. So it's difficult to keep track of that stuff. I can say too that we've really been helped by the improvement in Ruby itself. Going from 1.8 to 1.9 was a massive boost despite some small pains and going to Ruby 2.0 and then 2.1 and 1.2.2 each one has brought significant massive improvements that just work across the board. Ruby 2.2 symbol GC it's going to change the way that we write Ruby code just due to the fact that we can use symbols everywhere and it seems like kind of a small thing but those echo throughout the code base technically not everywhere. That's another good sort of transition you know it's a very, like I said, or else it's a very large surface area. There's tons of features and tons of things in there. How do you individually and as a group sort of decide what to work on? So you know like you sit down on a Monday morning and maybe you finish something on Friday. How do you, you know, most of you have other jobs. For all I know you all have other jobs as well. But when you're like okay I want to do some Rails work. How do you decide what you want to work on? You can start anywhere on this. Yeah personally quite often I'll get on issues that are to do with time or routing so I tend to pick up those a lot or if I haven't got any of those then I'll just go and dig into the issue you're tracking and find something interesting. Do you set time aside in your week to work on Rails work? Or is it just that when it pops up you're like okay now I'm going to put aside a day or a few hours or whatever. I'll try and put aside some time. Not really I think I work mostly on weekends or on nights. But I see later in the work has become easier times to raffle. Yeah I think you can see the issue tracker and almost all the issue was already reviewed by raffle. We don't follow like a process or anything like that. I tend to work on stuff based on issues we have at work or from time to time I have to do list and put their pending things that I would like to fix and maybe at some point I just jump there or something like that. Yeah I think we as far as as a group I think we have a kind of loose list on base cam about some of the big areas that we would like to eventually work on. Individually for myself it's just whatever I bump into at work and yeah other things kind of find themselves on my list. I don't know how to get in there but they just automatically pop up. It's April it's time to do Google Summer of Code and make sure we have enough projects for our students and things like that. Random just random. Yeah just no usually it's it's a mixture of stuff like for me it's a mixture of things that will either be stuff like typically performance issues that we're running into on work apps or just things that I'm interested in. Either one of those two is just. I'll say that this actually isn't true. Aaron looks for the things that give the largest look of disapproval or the greatest table flip and then he dwells on them until they're fixed. So as a group do you set and decide and you know this is maybe a question for David that he's not here so we'll answer it is though maybe he would answer it. As a group do you figure out like okay what's going to be the next major release? Like the minor release is I guess a group. What is a group? Did I say something funny? Or is it I mean I know that he drives a lot of the big features maybe they're going to go into the releases. Is that still mostly the operating procedure? Let's just use Action Cable as an example. Action Cable yeah it's a different kind of example. We haven't really done something like that before. From my view we take a lot of what we've seen in working on Basecamp for the past number of years as it's integrated into each version of Basecamp becomes our legacy app and we get very intimately acquainted with the things that we'd like to do differently and so those are the things that come to mind when we do new development. Coming back to your last question about how we choose what to do like I'm often reactive also when there's an issue go fix it but during new development is also a great time to shape the way Rails is going to turn out and get on Rails master and find the things that kind of work on their own but don't quite work in concert together and make them work with your app and those are the times where you can make design contributions it ought to work this way versus things seem broken here I stub my toe. So within the issue tracker does it seem is it self? Oh I tried this and it doesn't work or it blows up for some strange reason or whatever. You're gonna have that presumably because it's software and then hopefully you're gonna also have some feature requests. Hey it'd be really nice if it did this, really nice if it did that. Is there a split? Like is it way more issues? Is it just a few features that actually feature requests that come in do you get a lot of pull requests? Do people try and scratch your own itch on the features a lot of times or I'd love to just know kind of how that split breaks down especially as you kind of said you're all sort of work on demand as things come up. That doesn't necessarily necessitate a lot of features except the ones that you personally say like oh this is a thing. So I'm just wondering how the community helps you figure out what features should go in and that kind of thing versus just pure bugs. The issue tracker on github we mainly use for tracking bugs and pull requests so just new feature suggestions. We generally direct them towards the mailing list so we can have a discussion about it otherwise they just sit there on github with nothing there. So if you want to send in a feature request you can send in a pull request. But if you sent one in it would behoove you to also start the conversation on the mailing list. Hey I sent in a pull request about this feature and here's my justification for it let's have a discussion but that's the place to do it rather than me. And does it feel like that happens often? Do you have a lot of feature requests a lot of feature discussions from the community on the mailing list? Very frequently. I wouldn't say it's high volume though. The difference between having something you wish for versus enacting your wish is a huge gulf and going from the first contact to github for something like an addition rather than a bug fix is a pull request which means that you've thought through a lot about how your idea needs to interact with Rails and with other people's applications which takes a lot more work. I wish this was here for me already which is easy to do and easy to say but when it's left on github issues there's not much anybody else can do about it other than just know that you had that wish. And if a lot of people have that wish great somebody can come and do something about it but there are a lot of wishes and not enough people doing things. Rails is also in a pretty special place in terms of its maturity as a project as you probably know a lot of people use Rails in a lot of different ways and we already have a very very large API surface and so some of that also boils down to how many people can actually benefit from this because we can't have too many things in Rails so like a lot of times people would come oh like I need this in my app like it seems pretty obvious everyone will need it while it turns out that perhaps not everyone will need it but it's still a very useful thing even though we couldn't justify putting into Rails perhaps you can put it make it into gem and that's actually how some of the new features in Rails was merged in and then over time this actually works and it would actually be beneficial for most people so it merged in Do you on that sort of on that note as people are in the audience or watching this some future time on the internet do you prefer if someone has an idea for a feature that they bring it up on the mailing list before they go off and write a pull request so that at least you can say well that's a good idea but there's all of these other things to think about before you do the pull request because I know that sometimes it could be that a pull request shows up and you feel bad someone spend a whole bunch of time on some feature that you're like well but it's actually really orthogonal to all these other things that we're doing and if we add it I know that you spend a bunch of time on it but if I merge it in it's going to cause all these other problems so do you prefer the discussion on the mailing list or do you prefer to just get the pull request and then have that discussion afterwards I think it depends on the size of the future like if it's a really big change then absolutely mailing list first but if it's like oh I just want to add I've got this really cool method I want to add to active support probably a pull request is fine Are there things that people shouldn't send pull requests for? New methods to active support I was hoping you'd say that that's why I asked I think it's a strong preference in any direction because I think that if you have something that you need to get done you really want to do then making a library or Ruby gym or a Rails plugin it's almost everything can be done that way these days unless you're trying to change something in the internals of Rails which I think is the less common case but you can implement it and you can prove it's usefulness by spreading use of the gym yourself there's been a lot of talk about especially with action cable and how people are writing web apps and the API work for inside Rails so you're all not just implementers of Rails but practitioners of it as well so maybe it would be interesting to find out a little bit about how you personally within your projects are using Rails are you using it using it for a lot of APIs and generating it using it for a lot of JSON APIs I'd love to hear what your personal philosophy is because that in itself helps drive what Rails looks like as well we can start however, do you want to start something? Given that we are a consultancy company we have several different projects and we don't have a strong preference of one way of doing stuff it's just the way that it's a better fit for the projects so we have some projects where we use Ember or Backbone and then we have a lot of more projects where we use the default stack so basically I mean it depends on the project what stuff we do Yeah similar to Santiago we're very much agnostic with micro services, separate Rails apps for different parts or a monolith depending on the application We've been working on a Pico service framework It's lighter weight Our apps at work are basically regular stack nothing amazing I'm going through the internet questions now so that's why I'm looking at my phone Any other thoughts there? Every time I hear monolith I just think of that Simpsons episode where he's like monorail What if I electrified five car monorail One thing that I felt after years of working on base camp was the power of small teams and what we can do with something that is well integrated, a monolith With a small number of people we're able to deliver an app to multiple platforms, we have iOS and Android apps that work from the same kind of canonical source We don't write a separate JavaScript app, we write one app that works everywhere and we can do it with a small number of people We have a workplace that I love and something that I've come to treasure like being able to design a workplace that can afford you that kind of flexibility where we can work on this whole breadth of base camp without needing tons of teams, people I don't know, we all work together That's a really good sort of quick question if anybody can answer if they have any thoughts there Obviously people building mobile apps and doing lots of things on mobile, do you feel like there are certain things within Rails that help you be able to build out interface with mobile apps or I'm just sort of throwing it out there to see if you have any thoughts The intersection of iOS, Android apps and Rails is a very interesting spot and I think a huge number of people are at that exact point in time Any thoughts there? Anybody? Merging the API stuff in the master will help I think going back in time a little bit for the technical end of things, doing content negotiation and being able to return multiple variants for each RESTful resource allows you to keep your representations close to your resource and the interaction and the controller and that single thing has turned out to we've gotten a lot of mileage out of it. We're going to adding explicit HTML only variants where we could serve a different page to mobile versus serving a different page to desktop we're able to build out entire apps from the same resources just with that tiny little feature How many miles? Ten? 15? Okay, so I have a couple of quick internet questions and then we'll get to one sort of pessimistic question for me if we have time. Ernie wants to know with 2.2 symbol GC, how soon will hash with a different access die? It won't die It can never die! Well, because you, I mean that would break the APIs, right? Because you have to be able to access with a similar way doesn't it? Right, the only thing that would happen there is if like symbols and strings all of a sudden became the same thing inside Ruby then you're like, okay, yeah, I guess it couldn't die now. Well, I mean we try to do it so I think with regards to hash with a different hash with in different wea with that we try not to use it internally so we don't use it internally but we use it for stuff that's user-facing so I don't know I like internals so I don't really care Most user-facing stuff is coming, like we're ingesting it from the outside world where it is strings too so it makes sense to build a hash of strings and address it within your program using symbols. Okay, I'll ask my pessimistic question and this will probably be the last question then so we'll try to have everybody answer you all have worked on, especially a number of you are consultants so you've all worked on a lot of different Rails apps that are probably in a lot of different states of usability, you know what I mean as you've been working on those is there some like specific smell some specific thing that when you run across a Rails app you're like, oh no they did this that you every time you see it you go, oh no they did you know, maybe it's overloading something weird I don't know, sorry what did you say Aaron? Concerns they concern me Any thoughts there, Andrew? Yeah, I mean you see people break models up into like loads of little files all over the place and you just don't know where stuff is, especially when you're coming in as a consultant Yeah, I've seen a lot of people that are still putting business logic in the controllers Yeah, that's hard I have seen models with 10,000 lines of code or controllers doing render text and all the HTML in the string, something like that So, don't break up your models but don't leave them as 10,000 lines it's just a very careful balance the feast of the famine of how big the makeup I think one of the biggest problems I've seen and like I personally sometimes have this problem too is not having a good grip of what you're putting in your app like whether it's like design patterns that you see at talks or what is gems, right like over time you have 20 folders in app like with everything, every pattern possible and like in your gem file there are gems that no one really understand like there's a block pose on top, if you put this gem into your gem file it magically makes your app faster, so you do that and then like over time you don't actually check whether that is still useful and turns out that well on latest version of Rails that actually makes things slower, right, like so it's those things like you really understand your app and be conscious of what you're doing Prune your garden, and your garden is your gem file, in other words is what you're saying Putting tons of actions in the application controller stuff I've seen, I was thinking about changing the route to just be like changing the router to just say CGI bin in that case but yeah actually a lot of, I was being kind of sarcastic when I said concerns but not that sarcastic like basically abuse of modules, so using tons and tons of modules mixing in tons of modules where you try to debug it, it basically becomes a debugging nightmare because you look at the module and the method in the module depends on an instance variable and you're like where did that come from, and then you're like good luck trying to figure that out, but honestly the worst is there's just so many methods, there's so many actions at the top level. Jeremy, you've seen code base evolve enormously over time. Yeah, I could speak to like past me and there's this perfect, it's base camp this is the reference application. I look at what we did with early Rails and some of those early things are hard to change, there's not much motivation to change things work and places where I drift from convention because I'm under time pressure or impatient and just want to get shit done and you can pay for that impatience and you pay for the next thing where you go touch that bit of code, but places where we've seen changes in Rails respond to that are like when we introduced RESTful everything it's now common to think of your controllers as resources instead of controllers that are like functional bags of stuff and so if you see any Rails applications that were born before that migration it's very common to see where you're like this kind of stuff happens here I'm going to have a bunch of actions that do that kind of stuff so it's organized like namespaces of RPC calls rather than nouns that you do things to I think everybody here is probably new enough that they don't remember that transition but I think that was one of the biggest feature that was added to Rails or the most impactful in my opinion which was what? Adding, introducing RESTful controllers just it was huge okay well I think that's we're going to call it on time thanks for being up here and fielding my ridiculous questions and let's give them all a big hand