Hey, this is David Heimer Hansen. I'm sorry I can't be with you all at RailsConf Kansas. This is a fantastic year to be at RailsConf and I'm really sad to miss it.

We have Rails 5 almost ready to roll. In fact maybe the release candidate will even drop during one of these days. But in my stead you have something perhaps even better. Jeremy Dare, who I've worked with since, what, 2004 on Ruby on Rails, the framework itself.

He is one of the few, actually I think perhaps the only person who's still around from the inaugural core team, has committed to the framework going back all the way to 2004. So when people ask, hey, you need 10 years or more of Ruby on Rails experience, Jeremy

is one of the very few people who can ask, oh, yep, got it. And in addition to that, of course, I worked with him at base camp and has for many, many years now. It's been an absolute pleasure. Jeremy is one of the very best programmers I know. Whenever there's anything I can't figure out, Jeremy is usually the person I tap and ask.

So you're in for a real treat and I hope you all have a fantastic RailsConf in Kansas and I will see you all next year. Enjoy. Geez, David.

No pressure, right? Well, thank you. Thank you, David. He stole a bunch of the stuff. I need to explain about why David's not here, that I'm not David, I'm Jeremy.

It has been 10 years and it's really kind of boggling to look back at that. I was sitting here in the conference room full of anticipation. We had a company meet up last week with base camp and we're also looking back at where we've come from and where we've arrived, where we want base camp to go, and I think

Rails has a lot of parallels with that. I was feeling, it was kind of interesting, like, what can you say about something like Rails? My impulse, I work on Rails, I help build Rails. I help other people build Rails and that's what I really love about it.

My impulse is to talk about what's going into Rails, what's next for Rails, and kind of a, I can give a litany of all the sweet things and features and things that we want for base camp, but really, I love Rails itself, the community that's formed

around it, the kind of business we've been able to build around it, the kind of team that we run, because we assume that software like this is normal. We were looking back, David in 2008 talked about the great surplus, and I'm going

to talk about that some more. We're here for Rails 5, of course, and to me it feels like Rails 5 already happened because base camp 3 is running it. We've been really pushing to make Rails 5 the best it can be for base camp, and

I think it's also going to be the best it can be for all your apps. David kind of tripped me up thinking about time with base camp, and I know a lot of you have also had similar kind of tenure and experience with people you're close to, coding partners, people you've been in business with, people you've seen

come and go at your companies, and you may be rejoined later. I remember back in the dot com era before Rails, depending on where you lived, you could recycle and you'd see somebody that you had left and missed, you'd see them again six months later or a year later, and there's a kind of camaraderie in that, that

despite the circumstance and despite feeling like really this dot com role is kind of shitting on us, we're in it together, and that was great. I kind of missed that in that period after, like, what happened? Rails came along and it was the first time I really participated in open source in a

way like this, and it's something I wouldn't have even known to look for, but it's something that grew around me. I learned to help others a lot, and that's really what I came to enjoy about it. But first we've got to get back to the couple of misconceptions that David's already

cleared up, but fuck it, I'm not DHH, and you know, the saying goes that there are a few hard things in computer science, naming, caching, concurrency, so we can say

that we hit a race condition, so David's racing in the six hours of spa, I don't actually know how to say this because it seems like saying spa would not be a thing,

like spa's a place, spa's a thing you get in, but it's a place and does these long endurance races. If you're interested, if you want to cheer him along, you can find him on Twitter at DHHracing because he has a separate Twitter account because there's so much racing. And sorry, Aaron, I warned you before, but this was the primo pun, and no more puns, I swear, I swear.

So I'm, well, this is all I can dispense with this, GitHub, Twitter, and you may have also noticed, you might have known me as Jeremy Kemper, I'm not Kemper anymore, I got married.

Got married to Renee Davis last year, and we combined our surnames, so now we're Renee Dare and Jeremy Dare, and I give a shout out to the state of California and the Name Equality Act for making that possible. Reflecting again on base camp, I've been at base camp for nine years now,

and it seems like an eternity to me, and it really isn't, and you hear all the time about people retiring after a 35 career doing something, and here, my tenure here is just a,

it's a blip. I don't even know how to think about that yet, and my first day still feels like yesterday almost, even though, well, I can also, I start thinking about the details of what I did, what I'm still doing, and I feel like all those chunks of career, the things that,

all the efforts you make, all the things I've forgotten, and those things, how they snowball into what turns into a career. My first project was a search engine, and using, I think it was solar at the time,

and reflecting, I think it was something like five years later, and I was working on a search engine again. What's happening here? Ten years later, I'm going to avoid the search engine. Ruby on Rails, even longer, and also something that I don't really know how to synthesize

or make sense of yet because Ruby on Rails has been around now for going on half of my career as a programmer. But, okay, we're here to talk about Rails 5, so here I am, here we are.

You're all building Rails apps. Are most of you on Rails 4? Yes? The big pain, the great discontinuity, the meteor strike was Rails 2 to Rails 3,

and I will say that we still run Rails 2 apps at Basecamp, and that's part of our legacy. It's something that we've chosen to fully embrace, even knowing the hue and cry about very real problems with running Rails 2 apps. And we run some apps on Ruby 1.8, 1.8.7, REE, and so we take on a greater kind

of responsibility for our legacy and our past. But at the same time, we make our greatest efforts to stay current, especially with new development.

I'm not going to talk too much about Rails 5. This was my impulse. I made a talk that was really mostly about, there's a bunch of new, sweet stuff. I mean, let's get that out of the way. Action cable's pretty cool. I was a real action cable downer at first because I'm thinking, like, web sockets, you know? Web sockets were kind of cool, and actually I haven't used them that much.

But HTTP 2, like, are we going to leapfrog this? And the thing is, web sockets totally work great today. They're at their sweet spot, the prime of their life and their tech curve. Web sockets, trying to use them even two years ago, it's a total hassle.

Everybody implementing a different kind of version of the draft spec, blah, blah, blah, blah. So you ended up having complex libraries to handle all kinds of fallback mechanisms, use some other technique if it doesn't work, and a big split between should you start with a simple technique and upgrade to the more sophisticated ones, or should you start sophisticated and downgrade?

Well, these days, in most browsers, most of the time, web sockets totally work. And they totally work for the things we need them for. We designed Basecamp 3 around being able to push, to publish updates out to people. And we've done that in past apps. This is not a new thing. These are not even, these are not new ideas.

The new thing for us is that this is part of the framework. Working with these things is like working with any other part of Rails. You build a controller, it's what I know. I think about my interaction with resources, and Action Cable's built in the same way. So rather than one-off things where I know that my app is gonna need to know about,

I need to broadcast things out to a bunch of people, so I build it as a one-off feature. Now I have this available as part of Rails, and so I start seeing opportunities to use it, and seeing the places where it's natural to rely on it. Or I might not have even thought about it before.

There are two other big things that I think are selling points and are really some of the most important features of Rails 5 that aren't really features either. First is the Rails Code of Conduct. We also chose to adopt a code of conduct.

And in reflection on this, looking at why we would do this, it's interesting having that kind of perspective. Why would you be in the position of asking why do this?

This is something everybody should do. It should be why not. And as we arrived at the decision of why not, why aren't we there already, we also decided to take a step back and look at what it's like to work with Rails, what it's like to interact with our community, and what we look for from contributors,

what we look for from ourselves, and the kind of commitments we like to be able to make to new people in the community, to new contributors, to know that when you submit your first pull request, the kind of experience you're going to have. And we'd really like to see this reflected throughout the Rails community, because it's huge.

It's not just the Rails committers. It's what it's like when you go into an IRC room. I mean, who goes into IRC rooms you're just going to get shit on, right? It sucks. But the Rails IRC room has historically, it's bucked that trend. And there are a lot of other places where you can interact with the Rails community. And we've somehow set a tone,

and I can credit Ruby for setting these kinds of initial conditions, of a good, welcoming, wonderful place to work, to learn, to not get shot down. And you can read this online at rubyonrails.org slash doctrine. We've written up, it's really a first draft,

a first version of the things that we value in working on Rails together, and we hope you do too. Third one, there's a new start page. When you make a Rails app, there's a new start page.

I really should have put a photo here, and actually, I cut it out, but it's sweet. It really is. We had one of our designers at Basecamp, Jamie DeHanson, redesigned the reboundrails.org website.

Timely for Rails 5 coming, timely for Rails Doctrine, for Code of Conduct, for projecting what we feel about Rails. And lovely to him, to redo all that for us. Totally kicks ass. So if you start a new Rails 5 app, just wait for it.

So I said I wasn't gonna get too much into Rails 5 stuff, like what Rails 5 does. I wanna talk about the how and why of Rails, how we got here, and this is the questioning I went through, like, in a situation like this,

like why Rails 5? Why Rails? And last week, meeting up with everybody from Basecamp, we're remote, getting together every six months or so, also having this opportunity to say why Basecamp? Why Basecamp 3?

And well, okay, I've got this little splinter in my mind, so just indulge me for a second. Seriously, what is up with this?

So, I mean, this is literally a problem I was having a couple nights ago as I was putting some polish on this. I've thought about this before, it's the kind of thing that might stick in the back of your head, it's just some knowledge I don't have.

But it became very concerning to me. What is Kansas City doing in Missouri? What, did they move it? Did the river shift around it and the border changed? Like, there's gotta be a reason. Some kind of engineering solution. So I looked it up.

In case any of you had the same splinter in your mind, 1830s Kansas, it's founded as a Missouri River port town and Missouri River, why call it Kansas? Well, because the Kansas River comes in from the West.

So let's call it Kansas. You know, after the river. And cool story, Kansas didn't exist at that time. Something, everything clicking here. But Missouri did. And the river was named after the native Kansa tribe, also known as the colonization. Also making sense. 1854, Kansas Territory.

Okay, now we've got a town called Kansas and we've got a territory called Kansas Territory. This is like kind of confusing. So people in the town of Kansas are thinking, that's confusing, right? Yeah, so they renamed Kansas the City of Kansas.

Let's be clear that it's different from Kansas. Okay, so next up you can guess. 1861, Kansas becomes a state. This time, no problem. No confusion, Kansas, City of Kansas, Kansas Territory.

Okay, 28 years later, for some reason, 1889, Kansas City, screw it, we're Kansas City now. So we have Kansas City on the Kansas River next door to the state of Kansas in Missouri. And by the way, there's a Kansas City, Kansas.

And it's right across the river. Okay, so now that we've cleared that up. Okay, factorial's five, I swear nothing else. But now you know, like this was really bothering me.

And I feel better knowing that you know. Okay, so this is a huge release for us. It is the release that launches Basecamp 3. It launches Action Cable, it launches Turbolinks 5. It brings Active Job.

Active Job's been around since Rails 4.2, but it really brings Active Job to full bloom. It changes the way you build apps that you'll probably end up reaching for Active Job a lot more frequently. Action Cable in particular. Action Cable is accepting a ton of connections

and doing stuff. Well, what are you gonna do when you've got 10,000 connections in one process and you start trying to do stuff? You're gonna block everything that's happening on that server. So your typical response is you wanna offload any kind of processing as soon as possible. So the interaction pattern you're gonna see with Action Cable channels is give me a job.

Instantly, give me a job. Otherwise, you're gonna be blocking everything that's happening in your server. This is also the Rails that introduces a full API mode. This means the locus of control in your app,

if you wanna move it to another service, if you want Rails to be a collaborator to some other place, if you wanna implement in something other than Rails, if you wanna implement in the browser, totally cool. The way that Rails works remains fundamentally the same. You're thinking in resources, you're thinking restfully.

None of that changes. So this is particularly something that's, this is not a new thing either, right? Single page apps have been around for ages now, browser apps, and so it's really recognizing where a lot of the Rails community is headed and is already headed. This is particularly true for some

of our larger Rails businesses, as they've grown and have embraced other platforms, particularly if they're multi-team, if they're a medium-sized company that can accommodate iOS, Android, and decides to run on the browser kind of as a almost isomorphic counterpart to having a client on other platforms,

treating the browser as a platform itself. That's probably the biggest change that I feel in Basecamp 3, is the transition to Turbolinks 5. And this is something that's very personal to Basecamp and the way that we work and the way that we've grown.

We couldn't contemplate, and I know a lot of you can't contemplate either, creating an Android app on top of what you already build or creating an iOS app on top of what you already build. A team can only do so much and has to make choices about what you do.

And especially a small team. When your choice to expand to something like Android, when you feel the pressure from everybody in the world telling you you need an app, well, how the fuck do you do it? Like, what, you hire somebody, right? You grow into being a larger company

or being a larger team so that you can take on those bigger challenges. And we took a different path, and I think it's something that we might, it was risky. It's something I think a younger Basecamp might not have done. And we second-guessed ourselves

and we doubted several times along the way because we hit some just gnarly roadblocks or like, this platform is not meant to integrate cleanly. But we made it through thanks to some considerable effort on part of the Turbolinks team and our iOS and Android developers.

So part of Basecamp 3 and part of Rails 5 is the paired release of Turbolinks 5. Turbolinks 5 comes with iOS and Android bridges. This is something you can use to build your own Android and iOS hybrid apps

on top of your mobile apps. So you can think in terms of your Rails apps, your Rails resources. You don't need to build a completely separate experience. If you're a team who already has mobile development, this is not a win for you.

If you're a team that doesn't, check it out. So enough of Turbolinks 5. How do we get here?

I'm looking back and thinking, why Rails, why Rails 5? Here's my first thought. I'm getting into David's mind here. So this is David, circuit 2003. Seems legit, right?

David isn't here to vet this. So that's not wrong, is it? We can take a closer look. I think there is something to this. There is an element of truth. But really, the story of Rails 5 is also the story of Rails 1. In the early days, let's break it down.

We can see, here's David, 2003. It's not just that we need to make Basecamp. It's the sense that there is this, there's an opportunity. There's something that can be done. Here is a single person, 10 hours of time a week.

And you can make something in that time. And you can reach further than that. You can make something great in that time. And so I'm imagining him going through this. You know, how is a Basecamp formed?

XML, duh, duh, duh, duh, duh, duh, what? So, fuck no. And lo, Rails is formed. Now, there's truth to this, and it's kind of glib, but working with David over the years,

this is not too far off. Working with a sense of anger, not in a sense of like, screw you, but with a sense of higher expectations, having a higher bar, wanting to maximize tools, what you can get out of something, being impatient with roadblocks.

There are so many things I've recognized that I'll let build up in my code because I'm thinking like I'm taking kind of a longer-term view, and I keep stubbing my toes on the same things over and over again, and you get that frog-in-a-pot effect of like, this is just the new normal. Everything's fine.

And maybe it isn't. Maybe it takes saying like, I'm not gonna put up with this. I'm not gonna spend my week trying to build applications this way. So I think there's a much more positive story to this, too, that I think this is also David's story. It's the story of programmer happiness.

And this is the story that we all know has brought most of us into Ruby and Rails. But it's more than just Ruby. It's the web. It's the story of a universal platform that we all have access to. Anybody can create anything.

I mean, the web is full of crap, right? And it's full of great things. And it's a testament to your freedom to publish and your freedom to use. Anybody can go to any website. And I mean, I'm preaching to the choir here, but it's changed the world, and it's changed the course of my career

and probably all of our lives. And beyond this, it's really a story of the outsized impact of just having these great tools, that you can do something on the web as a single person or as a small team that you don't need to work in a big company

to have any kind of impact. You can have it on your own. You can be responsible for it. You can own your product. You can be responsible for your customers. These are all things that are essential to small business. And many of us probably don't think of ourselves as small business, but if you're a freelancer,

if you work on a development team with yourself, one, two, three other people, you are. And this is the world that we can thrive in. This is a wonderland for what an individual can do.

And really at the end here, it's what we see as the surplus that comes from having access to the web, having access to tools like this. And really that becomes Basecamp One. The surplus here is really what made Basecamp One

possible. I think about what David could have achieved with 10 hours a week using really anything else. You could make a fantastic product. You could make a competent product. You could make a Basecamp One. It might take you longer. You could argue about the differences.

But what comes after Basecamp One? It's the products you keep building. It's the world you've made for yourself where you can be happy building the next version or the next feature. You don't have a grudging relationship with your tools or with your work, with your product. And ultimately, I think, with your coworkers,

with what you expect from each other. This again just is the big one for me, that it's the barrier to creation is so low. I mean, it's like a crack in the sidewalk. It's changed a lot over the years.

Like it's certainly not the early web where everything seemed balanced. Every consumer was also a creator. But as creators, it's the same world today. We can still, we can launch anything, anytime. And for the individual and the small business,

launching something on the web is a completely different story than launching something on iOS or launching something on Android, much less launching something on all of them. And there's a little more that's proved more enduring. We've seen platforms come and go.

And of course, browsers got their issues. But 10 years ago, the web kicked ass. Like I would encourage anybody 10 years ago to work on the web, to become a web developer, to become a web designer, to bet on the web. And I don't think that's changed. I would do the same today,

and I think we all will 10 years from now. The web's gonna remain a place to create like none other. And Ruby, of course, is why a lot of us found our way to Rails in the first place. Ruby, so I was looking back on this a little bit,

and it was kind of like looking back on Rails. And Rails seems, it feels normal these days. When Rails came out, it was audacious. And of course, David was too. The way that he pitched Rails, also positioned it as something that other things aren't. So it was being purposefully exclusionary.

Like you aren't these things. But it was really to get people's attention. Like maybe these are the things you want. Maybe these are the things you want to include. And in 2003, Ruby was audacious too. The idea of using Ruby in a production environment,

a toy language, are you kidding me? No, and now Ruby is completely normal. Ruby is considered mainstream among a certain set. It's still something where you're not deploying Ruby to Google.

But for a startup, a small business, and many companies adopting something like Ruby and deploying it to production, it's just another choice on the menu. And at the time, it's really because Ruby had a spark like none other. Ruby was designed for programmer happiness, and it does sound completely normal now.

It's something everybody knows. But there's something left out there, because Ruby's become a professional programming language too, which has been a huge struggle, growing pains in the Ruby community, going from something that's the domain

of the intrinsically motivated, those who found Ruby and built it into identity, and to see it become something that's professionalized is almost like taking something away. But I think that's why Ruby succeeded,

and why, particularly in some professions, in places like Rails, in small teams, in places that look for this kind of relationship with their tools and with their product, why Ruby has thrived. Because it's more than just happiness. For me, it's fluency.

It's love of the language, of the community that's growing around it. Ruby is, I can say, my native tongue. And in a world where, especially in a tech world, where you're supposed to want to be a polyglot,

and I can write other languages, but there's something special about Ruby to me. Ruby feels like home. I really feel, I suppose it is like developing a more personal relationship with your tools,

with my tools. And I like other languages, but I love Ruby. It's wonderful to write, it's wonderful to read, C, Go, JavaScript, totally sweet, Rust. Hey, Swift is cool, and they're all fantastic. But they're things I learn and I can use,

but it's a completely different story from coming home, from opening an editor and just knowing in me that this is, I know how to create with this tool. I feel the same way about Rails. And before we get to the surplus,

what about the first step? Why Rails? And of course, it's because Basecamp needed to be built. Obviously, right? But Basecamp, so Basecamp actually started as, I believe, a PHP prototype.

As David was looking for something quick and you can make it happen, and got frustrated along the way, like this is not something I wanna keep doing. And so built Rails along the way. This is where we joined my story with Basecamp and Rails. I had my own story of Rails before Basecamp.

I did, I was doing freelance work, I did PHP, Java, J2E. And I had found Ruby because I liked the language. I don't know why I liked it. I remember learning Ruby and Python around the same time.

And I liked them both. But Ruby had that little kinda something special. And so for fun, I would look at some client work I was doing and just think about how could I do this in Ruby? Is this even possible? And in this era, a lot of the Ruby libraries

were kind of like transliterations, copycats of another language does something, and it seems to do a pretty good job. So let's bring it to Ruby. And so as I tried building my own apps in Ruby,

it didn't feel right. It just didn't feel right because it felt like I was building my Java servlet app and I was just writing Ruby instead. And then Rails came along. I felt at the time like I had a pretty good collection of Ruby tools.

I had my own kind of set of conventions, things I'd use. And Rails was enough of an eye-opener. It did so much of what needed to be done. It was a complete vision of doing web development

end to end. It wasn't a vision of here's something that I've seen someone do. I like Ruby, so I'm gonna make that too. It's a vision of I wanna create products and I wanna use Ruby. It's a vision that I found easy to see myself in. And so it's hard to deny. I can see myself doing this.

Let's do it. I worked at CD Baby and I had already had my kind of come to Rails moment. And so that's how I ended up at CD Baby because Derek Sivers also had his come to Rails moment and was looking around for a fellow acolyte.

Somebody else know about this? Have you heard? And he actually, he looked me up from a who is entry. I'm like, who does that? But I was surprised pleasantly.

And from the who is entry, I was living in Los Angeles at the time. And he didn't know that I had since moved out to Portland where he lived. And so this was like manna from heaven. Like your who is entry said this and look, karma's coming back to me.

It's meant to be. So I had my own, let's do something with Rails. Let's change the way that we build products, experience before Basecamp. And this was entirely mine. I really liked this.

And it's something that made me appreciate what life was like when I decided to join 37 Signals Basecamp. Because it showed me it's not just Basecamp. It's not the Basecamp experience. And it wasn't the CD Baby experience. It wasn't the me freelancing experience.

It's really the experience you're all having. You know, if I ask why Rails, then why Basecamp? It's really why CD Baby. It's why GitHub, why Shopify, why every one of you has chosen to use Rails and you've built successful apps,

you've built successful companies. This is something that I saw in myself and I think you saw in yourself too. This is something that we can all do. So really, Rails is built to power teams like Basecamp

and it's also built to power teams like yours. It's designed to build products like Basecamp and it's designed to build products like yours. And the big one is that it's designed to sustain businesses like Basecamp and I think it's also designed

to sustain businesses like yours. Ruby on Rails itself is a surplus engine. It can create this for ourselves as individuals so that we can do this as a business. To me, this is mind blowing. As a freelancer, I can do kind of tech work

and I have my role, like I can make something happen. I can build a web app. And the idea of like a startup, having been through the dot com era, it was like, you know, muckity mucks do that. People have like a bunch of money do that.

Anybody can do that. And a lot of people did. So really, it's that we can rely on Rails end to end product team and business and I tell this story knowing that it's many of yours too. The big thing for me today is that

we're still a small business. Basecamp is still a small business. We have a large footprint but we're wearing a larger shoe really. We still aim to build outstanding products. We still use Rails the same way we did

when we were a young company. I mean, we all do, right? We all aim to build the best and nobody sets out to build crap, right? Well, sometimes building crap is like the great idea. And we all share these basics. And looking back, I felt traces of Basecamp in CD Baby,

the things that I really appreciated about Basecamp and that I also saw there. And I also saw things that I really appreciated and loved about CD Baby. I saw them in Basecamp. And I can even think back, like I saw these things in an Enterprise Java mill or two

and I felt the best traces of all these places in Basecamp today. But Basecamp did feel different too.

I think the big thing that I noticed was that it got a lot of things right for the kind of people doing work there. For people doing creative work, this was a company that was built for creators to create products. I mean, it was founded by a programmer and a designer, after all. But CD Baby felt this way too.

CD Baby was built by a creator who had this idea that we could make this kind of creation together and was able to invest that same sense of ownership and pride in everybody who came through. It was just infectious. This is something we're doing together. You're not a cog.

We rely on you. These are the kinds of things that I love seeing in Rails companies. That this is the Rails ethos that I'd like to see if I'm somewhere else and I'm gonna use, it's not even using Rails. If I'm gonna do software development, if I'm gonna work on products somewhere, this is the kind of world I wanna live in.

And it's having that mindset of creating a better place to create, of designing a workplace that you wanna work in. And this is what I feel like Basecamp really cultivated in me. And this is somewhat about your team,

like cultivates in you. You're looking for some of these same things. So my story, the things that have stood out to me and that are really the why of Basecamp and I think probably the why of many of your teams, what we look for from each other,

focus, limit our appetite. We're small businesses. We have small teams. We rely on everybody seeing the big picture and owning their product, having a sense of how things fit, having an intuition for what to work on next, being able to identify your point of greatest impact.

And how do we know where to focus? It's having a sense of value, knowing which lines of code to write. I mean, it sounds kind of silly, right? But there are a lot of lines of code out there that could be written and some of them are just don't matter, they're muck work or you're working on the edges of a problem.

You're not tackling the center. You're making deliberate choices. You're limiting scope and you're always seeking the center of a problem. And if I've learned anything, this is probably the most valuable skill for a programmer to have and to cultivate, knowing which, I'm not gonna say it again, which lines of code to write,

but it really is seeking value, identifying it and building an intuition for it because it's what's gonna serve you in the next project and the next project and the next one. And this is the big one. As a team, being able to seek out the epicenter,

working with a small team, especially you're often not orchestrating, you're not having somebody tell you what to do or having a Gantt chart laying out the sequence of things that need to be done. You're having to decide together and you're having to triangulate together on what's valuable and not spending time hashing it out together

or spending, you know, days in disagreement. You need to find points of accord, don't nip around the edges, don't back into a problem, don't get stuck with sunk cost, find your highest risks, find your greatest unknowns,

find what you want out of a product and tackle it straight on. You're gonna yield the greatest wins and everything will fall in place around them. Together, we can't do this alone. Especially in our teams, we don't have divisions. There's no wall to throw something over. There's nobody to dump something on.

Sometimes you're a team of one or two and we each own the product in its direction. Something I've struggled with is there can be a dark side to this. And you can cultivate overwork,

you can cultivate workaholicism. I don't know if that's a word. It can cultivate a kind of like 110% effect, like you need to be crushing it. You don't need to be crushing it, you just need to be doing a good job. And part of that is like taking responsibility

for what you can possibly do and looking out for each other. It doesn't mean that you're on your own doing the 110% thing, not getting enough sleep and feeling like you're working your ass off and so you're kicking ass, but you're really suffering.

The flip side to this is that ownership's personal. As we develop this kind of relationship with our products and our tools and our teams, this is what I was feeling with Ruby and Rails itself.

This is a personal thing and yet it's also a professional thing. How do I think about this? Are you supposed to tease these apart and treat them separately? I don't think so. I think, I hope by being mindful

you can avoid seeing this play out poorly because it can. You take, when you have a personal relationship with your product, that can turn into negative things too. It can turn into hoarding, it can turn into politics, gamesmanship, guarding and kind of defense, the kinds of things that reflect a selfishness

about your work or your work in relation to others, stature within a team rather than a team working together. And if we can act it all out together, I mean, fantastic, we're in concert. And this is when things really friggin' click.

And the first feelings of joining a new team and getting your sea legs and having those first experiences of like, this is gonna work. Having the first bad experiences, like you screw something up, you have a post-mortem and you move on.

Feeling like your team has your back. Those are the first times where you can really feel like we're in this together. I can trust not in just how this iteration's gonna work out, how this project's gonna play out, but in how the next one is, and the next one and the next one. It's what allows you to gather up your sense of trust

and cast it out in the future and see what it pulls in. And in this sense, really, our team, our firm, is our greatest product. We do all this work together

and we create one thing after another. And what we're really creating is the ability to keep doing it, to build a better team, to keep choosing our tools, to create the place where we can create like this. And bar none, and I think Basecamp is Basecamp,

best product, because it's the place where we can keep creating Basecamps, it's where we can adapt to the future and where we can trust and feel that this is not, it's an unknown, it's a risk, but it's not something to quail against and to be afraid of the future.

It's something knowing that when I think about five years from now, or 10 years from now, it's gonna be great. I have no idea what it's gonna look like, but I know that we're the group that can do it. This was new to me. I know it's probably familiar to many of you

because you've done it. You've cultivated and nurtured a team into being more than just a collection of programmers and designers and marketers and writers and business people. And that feeling of crossing the barrier into something that's self-sustaining and becomes something that you continue

wanting to be a part of. When you've grown together and you've matured, the things that I felt were the kind of resilience that come from a team like this, the kind of wisdom that you gain, and you build an identity together

that this is something that can endure, and you can do it again and again and again. You've really built an engine for surplus. So thinking of Rails as this kind of surplus engine, what Rails offers over a mainstream tool

is also something that you've all probably built in your own teams, looking for the best you can make with each other, looking for those points of surplus, choosing to magnify them, choosing to identify the best points, choosing to shed places that don't work.

It's really awesome. Your team can do things that a crowd 10 times its size couldn't. The whole idea of a 10x programmer, I mean, maybe, but a 10x team, a team that works together and trusts each other, kicks ass together, completely different.

And really, this probably boils down to any team that's getting a shit done together effectively. The big things for me here are the surplus engine, and beyond that, once you have a team like this and you work on it, it becomes a recipe for endurance.

You reinvent yourself over the years throughout products, throughout new ideas, and so have we. I'm sure you have, too. The surplus engine is healthier than ever, and it's no accident. We design, we maintain, we adapt,

and when we think of this just like our tools, this is something that we're on the lookout for. You debug, you have legacy. This is something that we're all responsible for, and a new kind of sense emerges. For me, a sense of permanence, and this is also an interesting one, a kind of bedrock sense that I feel from the Rails team,

from Rails committers, from the Rails community, from my colleagues at Basecamp, and it's the rarest thing that I've experienced because it's also something I wouldn't have known to look for or even to identify,

that we've set sail together, and we've made it again and again and again. We've done it so many times, we've forgotten times that we did it. It's basic trust in each other, and what we don't need to do this, again, 110% battle mentality.

We aren't an invading army. We aren't trying to beat a problem. We're trying to build something. We don't need the extra 10%, even the extra 20%. If we even see this, I've done this on occasion, where I feel like there's,

I've got too much riding on my shoulders, and the answer, the natural answer, the immediate answer is, well, I'm gonna do more. I'm gonna, I'm not thinking like, well, I'm gonna crush it, but like, I'm gonna put in that extra 10%. I'm gonna try to make it happen, and come out on the other side, and burned out a little bit.

Sent the team kind of topsy together, and why? We didn't need to do that. What we really rely on is patience, focus, keeping focus, willfully maintaining our constraints, being disciplined about it,

being cautious about growth, what we choose to take on, openness together, having strong opinions, holding them loosely, being willing to share without fear of somebody's gonna shoot this down, a kind of psychological safety, step one, being open to change in general,

being open to revision. Everything's up for reconsideration. Insight, simple one. Not being afraid of new things. At some place like Basecamp, it's been around a long time. Working with Jason and David, they're like, they're strong voices in the community,

and it can seem, especially to a newcomer, like, shit's figured out. Like, all the insights have kind of been had, like, not even. If anything, we've codified what it looks like to do product development, and to design a business for that time. It's perishable, it's gone the next moment,

and we're still learning. And persistence, the biggest one for me as a programmer is just, most of the difference you can make is showing up with it, bringing your game. It's 90% of the battle, and doing a great job, obviously, but weathering the ups and downs together,

sustaining each other, being patient, and trust. Okay, back to Rails 5. So, that's my story of really, it's kind of a pie into what I look for

from community I'm in, and that community is Basecamp, what I would look for in a new place, what I would encourage any of you to expect from each other, to expect from your teams, and to create for each other.

Because you are in this with your team. You're starting a business, you're seeking this kind of permanence. You want an outsized impact for your efforts. And our story is a lot like yours, and your story is a lot like ours. So, why Rails?

Because we love Ruby, and it's home to us, it's home to me. Why Rails? Because we love the web like no place else. It's a platform for creation, open to all of us. It's like none other. Why Rails?

Because these are the kinds of teams, and relationships, and businesses I want to see in the world. And I see Rails as this surplus engine. That's why Rails.

And more than that, so are we. We make this happen. We invest in ourselves. We trust each other. We do the work that matters. We build great products. We build this great surplus. This is going back to 2008, eight years ago.

David looked back on five years of Rails, and at this time, Rails was old, five years old. Look at all the things that have changed. Let's gauge where we are relative to the mainstream. Like how do we even judge that?

So here's what it looks like in 2008. So here's the difference in what you can do with Rails compared to what you could do at the time. And what do you think it looks like today?

Well, here's my view. It's the fucking same. If anything, I find myself in the same boat more than ever. 2016 is a very different place than 2008, but the kind of surplus that Rails offers

is very similar because Rails hasn't entered the mainstream. What Rails has done is enter a different kind of mainstream where Rails is commonplace, it's acceptable in worlds where it wasn't in 2008. It's 10 years, and so what are the bets

that have paid off? You know, if we're looking at this 10 years from now, what's gonna be the same? So the big bets at the time were confessing commonality. We're all facing the same challenges, we're scaling the same mountains,

and the audacious part of Rails at its beginning was that we don't just present a set of tools that you build your product from, make your own choices every time. We're all in the same boat. So you need flexibility. You don't need to set a new route of the same mountain every time.

Classic convention over configuration. And really, we've had this omakase from the very beginning. Pick your choices when it matters. Pick your choices when you need them. Deciding that tech matters. This seems, of them all, kind of probably the most stale to me, because duh, tech matters.

And in 2004, tech wasn't necessarily your choice. Tech was something decided in a boardroom, and the agenda should be set.

by those doing the work. The big one was that we care about us. Programmer experience matters more. Ruby's designed to make programmers happy, and this was like, what the hell?

Your programming language choice should enable your product, enable your tool. It should have these other kinds of characteristics and constraints. Well, 2016, these are all as true today as they were in 2004, in 2008, 2012. So what's the bad news?

We thought we'd lose the surplus. There's no way the market's gonna let this endure, right? Well, a few hypotheses. Mainstream copies, Rails? What do you think in 2008? Highly unlikely.

2016? Well, it happened, kinda. There's no XML sit-ups. Everybody does convention over configuration. It's commonplace, awesome for everyone. Flexibility, still kind of a no-no in mainstream tools. Like, you want to be able to have the kind of choice

to build things the way you want. But it's commonplace in tools aimed at teams, products, and businesses like ours. Deciding tech matters. We had faints toward this with adoption of Go, Swift, JRuby, but the agenda's still set elsewhere in the mainstream. But it's commonplace in tools aimed at teams,

products, and businesses like ours. You care about us? Yeah, still same faints toward this with Go, Java 8, and making things more programmer-friendly. ECMAScript 6 and 7, pushing languages toward programmer fluency, happiness,

making them a joy to write and read. And this is commonplace now in teams, and products, and businesses like ours, but not the mainstream. Mainstream is budged a little, but it isn't looking to copy. So, another option, Rails Go's mainstream. What did we think in 2008?

Maybe. Seemed hard to imagine. But kind of ambivalent. We were a tiny little piece of the pie. Wouldn't stay asleep like a tiny little slice. Retain our surplus. Is that really so bad? But can it scale? Let them ask. Have a little thud act as its own barrier to entry.

Well, can it? Yeah. It's been proven time and again, even Twitter, that something interesting has happened, 2016. Ruby is not the choice for the mainstream, but it's definitely the mainstream choice

for teams, and products, and businesses like ours. The bad news? Probably not bad news. We still have a surplus relative to the mainstream. And, well, going mainstream against, among David's is fine, as long as we're all challenging Goliath's.

Last one. Dramatic alternative. Is this gonna come up? Is there gonna be a new approach that builds a greater surplus over Rails? 2008 thinking, probably what's gonna happen. Alright, of course something's gonna come along. Be ridiculous. 2016, eh, we've seen alternatives rise,

some quite notably, but none to mount a new great surplus. We've seen cousins, really, partners. We've seen something different. Invention of new platforms, maturity of old ones, and there's one notable, phenomenal newcomer

that's changed the web development world. Node. You got it. That's probably the biggest impact I've seen on the web development landscape, and being able to think in JavaScript, it gives me, it harkens back to my feeling

of what it feels like to be in Ruby. And I feel that way for all the JavaScript programmers who are stuck on the front end, who felt like they're in a front end box, and they get enormous instant surplus. They already call JavaScript home,

talking about it needs to be isomorphic. Well, no, it doesn't. It's not a determinative success. The new JavaScript surplus for all these people is that they have a home language on the client and the server. They aren't boxed in front end developers anymore. So they can love JavaScript the same way I love Ruby. They can own the whole stack,

and really makes me thrilled that the front end is bursting out end to end. So JavaScript's not my home. Maybe my Airbnb. But our surplus does share common roots and common aims, and most notably, the real platform

that's emerged for all of us is the browser. This is true for Basecamp 3. It's true for apps that are calling themselves client-side. It's true for apps that are single page apps. It's true for pretty much all the apps we build. We all rely on DOM APIs and things

that only became possible because the browser improved. Kinda. It's a lot better than it was. We hit potholes, polyfills, and we can thank everybody for making it better. These are all evergreen browsers now. It used to look like this,

just like, great, the web. We can all create on the web. Fuck me. Total minefield. So what sparked this C change? I don't really know. I got hand wavy, kind of.

I don't know how to say that. What WG, what wig? But these guys, they changed everything. Splintered from the W3C to fix, well, to get rid of XHTML. HTML5, it's what we all rely on now. It led to browsers competing on standards,

on completeness, on chasing the cutting edge, trying to jostle to set the pace for new standards, to set competing visions of the web, for being predictable. I mean, this is just, this is the norm now. The list goes on.

We have an increasingly full-featured platform to build on. For the first time, we can even contemplate full-fledged browser apps. Nearly all of our apps today are browser apps. Fewer are built to run without using DOM APIs, much less without JavaScript. At the greatest reach, we have browser-installed apps. We have single-page apps for rich, responsive UI.

We have single-page apps to wriggle out of having a server at all. It's when you want to take on state management and browsing context yourself. And we have, let's say, multi-page apps. This is Turbolinks, Pjax, Stacker, and Basecamp2. You're all working with a managed browsing context,

which is really kind of a degenerate case of a single-page app. You're using these APIs to be able to interact with the browser. We have web components, custom elements, Shadow DOM, Polymer, and this is just the beginning for the browser. This is the golden age. So what's a dramatic alternative? Nah, not quite.

We've gained an awesome new partner. Our sickly, unreliable, flaky milieu of browsers has been nursed back to health, and they're all kicking ass. They're all evergreen. You can count on all of them. So to teams like ours, this is our surplus magnifier. The web is a platform that we can count on.

It's revitalized, works everywhere. We can put it on equal footing with native platforms. Turbolinks 5 magnifies it further for us. This is amazing if you're in our shoes, and I think many of you are. You wouldn't have contemplated going multi-platform, and you can do it.

Check out Sam's talk. I can't believe it's not native. Give Turbolinks a shot. If doing an iOS app is something that wasn't on your plate, or you hadn't even thought of, think about it. It's a huge opportunity for small teams and small businesses. The bad news?

Looking like not. It's rad news. Even better, teams, programmers are seeking surplus. They're finding us. They're finding Rails. New programmers, starters, kids, they're finding us because of this kind of surplus, because we're approachable, because you can start and build with Rails

from square one. So I'm feeling good, full surplus, magnified, engined, whatnot. So what's up with Rails 5? Almost. Beta 4's out for a week.

So here's how we're looking. I'll give you some large, irrelevant numbers. Shitload of commits, bam, crushing it. Look at all those merges. That's all since Rails 4.2. Like, who knows what's in those? I thank you, Rafael, our resident merge and patch monster and gatekeeper to all Rails quality.

And it's more than just headliners. Check out Sean's talk, all the features you haven't heard about. You can find out what's in all those friggin' merges. Befeatingly, the new and Rails 5 track has even more to tell. Look for this tag. This is deeper dives into Rails 5.

It's on schedule, it's on sessions. You can find out about action cable, Turbolinks 5, testing Rails 5, using RSpec with Rails 5. I think, going a little deeper even, look behind the magic. You can find out about active job, what Sprockets is gonna look like, Sprockets 4, source maps,

the innards of active record, what goes on when you boot a Rails app, what it's like to test, and hell, can you fit a Rails app in a tweet? Find out. That's actually a session. So, we're here now. Basecamp 3 is running Rails 5. So can you. We're working hard to polish up a release candidate.

And we're gonna do it this week, I swear. I swear, I swear. Aaron's gonna ship it. So, thanks to everybody who's contributed, there's still time to pitch in. There's a ton of pull requests. I know those were big numbers before, but you can add to them. So, long live the surplus, long live Ruby,

long live the web, and, well, every one of you. Thank you, and have a kick-ass RailsConf.