 Good afternoon, everyone. It's been a long day. I think we made it. Well done to all of you. So this is type context. Let's get started. Founding a startup that does software is hard. Writing an application in Java 2 Enterprise Edition is hard. Building a physical server, taking it down to the data center, wiring it in, plugging it into the internet to go to production is hard. And going home, SSHing back into that server and writing thousands and thousands of lines of XML to configure your Tomcat server is a nightmare. If I worked into a venture capital office in 2017 and told them that was my plan to launch a new hot software startup, I would most likely be laughed out of the room. We spent years building infrastructure as a service companies like DigitalOcean and platform as a service companies like Heroku to ensure that never again do most developers have to go to a data center to get their job done. We spent years building frameworks like Rails and Dejango to ensure that the thousands and thousands of lines of XML of the past are not a thing of the present. But in the year 2000, if I told you that's how I was going to do my startup in the late 90s, you would tell me that was probably a reasonable thing to do. And if not the best thing, then certainly acceptable. You have to remember this is a time when adverts like nobody ever got fired for buying IBM, were prevalent and popular and believed in. And in 2017, it's easy. It's really, really easy to laugh at those things. And for some of us in the room, I suspect we ran screaming from them coming to Ruby to escape the nightmare that all of that stuff was. But the truth is, at the time, these were clever people. They were brilliant. They were working out how to build the internet. They were spending days at a time working together, collaborating to ensure that we could have all of these wonderful technical inventions that we have today. And in some cases, these people now have more money than most of us could possibly imagine. The point is this. In software engineering, context changes. Over 10, 20, 30 years of a software engineering career, the technologies that you use, the places that you work, the sizes of the company, and the domains that you work in will change. And one of the great things that we're able to do as a group of people in the industry is adapt to that change and evolve and buy into the new technology. So let's talk about Ruby. That's why we're all here today. We've gathered as a community to discuss what I hope is our favorite programming language for most people in the room. I think it's easy to be a comfortable person programming Ruby for a long, long time. It's been around for 10 years already, and some of us have been programming it basically for as long as the language has existed. And there are a few reasons why Ruby, and in particular Rails, is so amenable to being comfortable as a developer. You can work in crazy, varied domains in the programming language. I've worked on healthcare, selling children's books, dating applications, music information schemas, and now the internet itself, all from the comfort of Rails. I suspect all of you have also worked in varied domains doing different things with the tools and frameworks, and that's really exciting. We're able to go and learn new stuff that we've never seen before, and we have this shared, common language that Ruby gives us in order to be able to understand and work in new domains. The set of conventions that Rails provides us gives us a mechanism to go in and learn what language people are using to describe things, models, controllers, and views, the names that attach them are English, and that English tells us something about the domain we're working in. We don't have to be an expert in healthcare to understand a healthcare Rails app if we understand how Rails works. One thing that I observe is that every time I come back to wanting to build a new Rails application, a familiar set of moves take over. I'm going to type Rails new and breathe an application into life. I'm going to spin up a bunch of scaffolds, that's hard to say, and get the baseline functionality of my application going, and then I'm gonna pull in some gems, add some CSS, do some whatever, and frankly another software as a service application has just come out the other side. It really is that easy. I think one of the things that Rails is not often given enough credit for is just how fast you can churn out a truly productive application that can start throwing off productivity or business value or if you're bootstrapping actual money, and this is powered somewhat by the mentality of the people who work in this ecosystem. It's not just about the code. It's not about the technical details. This is as much about the people as it is anything else. This is reflected in real applications that we have in production. This is a controller taken from an application that is in production today at DigitalOcean, and the thing that you should note is this is more or less exactly the same as the scaffolded Rails application apart from one line of code, validate people team, which just calls out to a helper to validate that you're a member of the people team at DigitalOcean, and then that's it. The rest is a scaffold, and I've been able to create useful, meaningful production business value without having to write basically any code, and that's a really powerful thing. Now, Rails controllers don't always look like this. Sometimes they look more like this. We build a twisted mess of unpacking parameters, newing up objects, dispatching service method calls. I actually couldn't fit the whole controller on the slide. I should tell you something, but as members of this community, I think most of us have an inherent reaction to that, which is I have to refact to that right now. That's a thing that's built into our ecosystem. I look at this, I have as someone who's an expert, maintainer of open source software, used by every day by everyone, I have strong feelings about how I would begin to break this apart, but if you're newer in our community, if you don't know how to do that, well, it turns out we built wayposts for you. We have talks by people like Ben Orenstein, Katrina Owen, Sandy Metz about how to refactor. We have books also by Sandy and Katrina and other people as well, and the point is this, if you don't yet quite understand how to execute something the community values, we also value learning, and you're able to go in, learn, pick stuff up, and it's kind of an incredible thing that we're all here today, exchanging knowledge, teaching, learning from each other, and I really like that. This has shown nowhere more, I think, than the number of boot camps that have sprung up over the last few years that are teaching people who have never done programming before and wanting to switch into careers new programming skills, and if you look at their curriculums, they almost all feature test-driven development from the very beginning, and that's not to say that test-driven development is an absolute good. I will stand here on stage as an aspect maintainer and tell you that I mostly dislike it, but it's a useful tool when you're new because it gives you a mechanism for understanding stability. It gives you a mechanism for understanding how well-factored a piece of code is, and when you're a beginner, everything is terrifying, and having something to hold onto that the community has blessed and built and developed over many years is really, really powerful. This is all to say that Ruby is an ecosystem, I think, of caring about software quality. We spend a lot of time thinking about our objects, our factorings, our growth, and our applications, or at least we say we do. I know everyone in this room has, at some point in their life, worked on a Rails app that they were not proud of that was full of bugs and mistakes and code that was coupled together far too strongly and they weren't happy with it, but I think the thing is we all hold in our heads where we want to go. I posit that the ideal Rails application is a well-factored monolith. It's one big code base that you like working on and everyone on your team is collaborating on one piece. It's backed by a single large database. There's maybe some caching mechanisms, but it looks kind of like the Rails way. It turns out that despite many of the things that have been said on the internet, that design is good for certain people, but who are those people? Well, if you think about who's in the room and the age of the Ruby programming language and how businesses tend to work, you can sort of plot a curve like this and Rails is a relatively young framework. It's only been popular for five, six, maybe seven years at this point. Ruby is not significantly older than that in any way that matters. And so most Rails companies are small. They just haven't had the time to become huge runaway successes. That is not the normal case. And so if most Rails companies are small and we are an ecosystem that values sharing our knowledge, that implicitly means that we have created an ecosystem of tooling for small teams and small companies. And that's not a bad thing. That's who we are. That's where we came from. But the other fact that's really important is that in 2017 it has never been more likely that you as the engineer on a Rails app will succeed. It's never been more likely that Rails is going to work for you and you're going to become a runaway success and you're going to have to hire hundreds and hundreds of engineers. And those are the outliers. Those are the survivors. We don't have a great number of cases represented in this room. I mean, in the previous talk, we just heard about how painful it is to scale a Rails app to millions of lines of code. And it's not yet a solved problem. Like, these are effectively researched talks and new inventions that we don't yet have good patterns for. So the question I would like to pose it is how can we make Ruby great for the companies that scale, that get bigger, that run away beyond our wildest dreams? Because that's going to happen more and more often. And I think the reason we hear all of this Ruby is dead rhetoric is because our community is growing in a way that it hasn't before. And it doesn't quite fit. And so when I think about how we can change our perspective on this, I like to go as far away as possible, look at the things those people are doing differently and come back. And not to be that guy, but there is one language, one ecosystem, one group of people who are really well designed to build big scalable teams. And that would be Google and the Go programming language. I know, don't lynch me, it's going to be fine. So none of us have Google's problems. Google's engineering organization is bigger than not only any engineering organization represented here, unless you're from Google, but also like the probably, probably the sum total of the sizes of all of the engineering organizations represented here. It's unfathomably massive. And that's interesting because if they have things that they value, those aren't necessarily the things we want, but it might be interesting to think about why they value them. To understand why Google invented the Go programming language, you kind of have to look at what their hiring pattern is. And basically what Google does is hire thousands and thousands of fresh college graduates every year. Those college graduates are working on teams where it's extremely unlikely that they will ever actually talk to the people who software they're consuming. And so they have to build patterns that scale beyond just single team, single communication, single monoliths. I have a few examples, and I wanted to sort of talk through them with you today. The first one is this idea, ah, these slides are in the wrong order, that's a problem. So the idea is that machine communication scales better than human communication. And if you can have the computer inform someone of a fact, that's saved a human having to spend some time communicating that fact to somebody else. And one thing that Go does really well to demonstrate this is this idea of forced error handling. Forced error handling is a concept where if you have an error that can possibly happen in your system, you have to deal with it or the program refuses to compile. I mean, Ruby is a happy path obsessed ecosystem. Matz is nice and so we are nice. Ruby is for programmer happiness. We obsess and think about how we can build programs that work, but we mostly spend our time considering the happy path cases because frankly, Ruby is a programming language, doesn't do a great job of exposing those sad cases. How many of you have an exception tracking framework running in your application? It's probably all of you. And the thing is, right, if you look at the underlying reasons why programs can fail, it basically comes down to any operation that performs IO can fail at any time for any reason, but it's not always immediately obvious whether or not an operation is performing IO. I have to, if I'm making a request, I have to dig all the way down into source code, see what exceptions it might throw or read documentation, but that means a human has to write the documentation in order for it to be correct and there's a burden placed there on people that the machine is not taking care of. The forced error handling go takes the opposite approach. Functions can optionally return an error as a value type and errors are values. They don't blow up the stack, they don't cause your program to stop executing, you don't deal with them with a try catch mechanism. Functions just return them and then the compiler makes you deal with them and you'll see in many Go programs that if you read just down the top, there's the straight line and any indentation is error handling and anything down the straight line is not. This pattern really, really helps you ensure that you're building correct network communications which when you're building larger teams that are potentially communicating across many services is really important. And there's nothing about Ruby that prevents us from doing this, actually, right? We can invent forced error handling in Ruby, look, I'll show you. So, load Faraday, define a get method that takes URL, boots it up, gets the URL and returns a response object. In order for this not to explode if the network is down, there's a timeout, something catches fire, someone starts a microwave and the Wi-Fi goes down, I have to rescue the base Faraday client error, but to know that I have to rescue the base Faraday client error, I have to go to the Faraday documentation, read it, consume it, understand it, I can basically get going in my head and then work with it. We can force consumers of this client to actually deal with the error. It's not even hard. Add two keyword arguments, on success, on failure. These are procs. You must pass a success and failure proc in and if you don't, this program won't execute. If you do, if the request fails, you will be forced to deal with it in your error handling proc. And if you succeed, you'll just call the success proc. We did it, we invented forced error handling in Ruby, it wasn't even hard. But just think about that for a second. This is now documented literally in the method signature that this thing can fail. I don't have to go and read source code or documentation, I don't have to dig deeper. I think that's a big win. I think we could do a lot better to make our API consumers deal with errors in Ruby. Next up is something called GRPC, which stands for Google Remote Procedure Call. So there's this problem in the world where JSON exists. Apparently that guy really likes that that's a problem. And sometimes you get keys wrong or like your remote API sends you the wrong response payload or something goes crazy wrong. GRPC is another example of documenting how your service works. You have to declare a manifest of what your service does, all the RPC methods that are on it and all the messages that those take. Those then get compiled into server and client implementations that you then expand upon. And this means that you know for a fact your client and your server can talk to each other with no difficulties whatsoever. You don't have to bother with error handling on a response to code, you don't have to deal with serialization. It's all handled for you. And again, this is an idea of scalable machine communication. You don't have to guess what those JSON keys are, you don't have to come up with a crazy contract testing cross-service discovery thing, which is something I think every larger Rails company has done at this point. They all tell me about how they're using their aspects and I'm like, please stop. Or like cross-service integration tasks because who wants to boot up five Rails apps to validate that something is working? We have a system here to prevent that just entirely and it's really, really nice. We use it a lot at this lotion. We began a lot of mileage out of it. This is something you can do in Ruby, you don't need to go to go to do this. But the idea comes from this core concept of machine communication scales better than human communication. To move away from that idea just a little bit, I wanna talk about Go's context package. Context is an object which is basically just a map of strings to other strings. But you can parse it through functions, request IDs, user IDs, basically in Go, every function takes a context and every function does something with that context object. It gathers state and you use that state to rehydrate information later. How many of you hate dealing with your Rails logs? I suspect it's a few of you. When you do an active record call, for example, you don't know which request caused it to start. You don't know when it began, when it finished. Production Rails logging can be a nightmare. Did this third party service get in vote? Did it not? What's going on? It can be very confusing and the Go context object is designed to prevent that and it's really interesting and I recommend you take a look at it. So to sort of quickly summarize, there's this idea in software engineering that your code base reflects the design of your organization. If you're a small team that all talks to each other all day, every day, a small Rails monolith is absolutely perfect for you. It's a great way to build a system. I'm not trying to hate on Rails. I wouldn't be here if I was. But our organizations grow and it turns out that beyond a certain size of team, working on a single monolithic Rails application turns into a real pain. I suspect some of you have gone through this at least once in your lives. Excuse me. And so as companies that are using Ruby grow, the question I keep pondering is am I beginning to dislike using Ruby in this context because of Ruby's fault or because of where we have come from? And I think it's that latter one and I think what's gonna happen is the Ruby ecosystem is gonna grow and grow and grow and we're gonna get bigger and bigger teams and to prevent the Ruby is dead meme, I think we need to go with that current and change the way we build our applications, not fight against it. If your code base reflects your organization, then at a larger scale, your ecosystem reflects your community and our community today is under change by any stretch of the imagination and I think we need to change the ecosystem with it. So that's kind of all I got. I just have two quick wrap up notes. So I work for Digital Ocean in case that point hasn't been flogged to death yet by the rest of the conference. Like every other technology company in the world, we are hiring. I would love for you to come and chat with me or Austin right at the back there, organize a t-shirt, also works with me at Digital Ocean, we just hired him so he can give you the new person experience, I can give you the old grizzled jaded experience. It's fine. I have a This Is Fine dog on my desk at work. It's the best thing. I just have one more thing. So, if you couldn't tell by my accent, I am not from here. But I do actually live here in New York City now and it's been an amazing experience. I've really been enjoying it. But for me, tomorrow marks a really special occasion. Tomorrow is the New York City Pride Parades. I am very excited to go see my first one. I think it's gonna be really, really enjoyable. And if you're around tomorrow after the conference, you should consider maybe going to see it too. So, that's everything. Thank you very much. I'm Sam Perkin.