00:00:06.580
Oh, good afternoon everyone. It's been a long day, and I think we made it. Well done to all of you. So this is Type. Context. Let's get started.
00:00:19.810
Founding a startup that does software is hard. Writing an application in Java Enterprise Edition is hard. Building a physical server, taking it down to the data center, wiring it in, and plugging it into the internet to go to production is hard. Going home, associating back into that server, and writing thousands and thousands of lines of XML to configure your Tomcat server is a nightmare.
00:00:40.570
If I walked 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 with companies like Digital Ocean, and platform as a service companies like Heroku, to ensure that most developers would never have to go to a data center to get their job done again.
00:01:07.869
We spent years building frameworks like Rails and Django to ensure that these thousands of lines of XML from the past would not be a reality today. But back in the year 2000, if I told you that I was going to do my startup in the late ‘90s, you would have said that was probably a reasonable thing to do. If not the best thing, then certainly acceptable. You have to remember this was a time when the slogan 'Nobody ever got fired for buying IBM' was prevalent, popular, and widely believed.
00:01:35.800
In 2017, it’s really easy to laugh at those ideas, but for some of us in this room, I suspect we ran screaming from them, coming to Ruby to escape that nightmare. The truth is, at that time, these were clever and brilliant people who were working out how to build the Internet. They spent days at a time collaborating to ensure we could have all the wonderful technical inventions we enjoy today.
00:01:57.220
In some cases, these individuals now have more money than most of us could possibly imagine. The point is this: in software engineering, context changes over 10, 20, or 30 years of a career. The technologies that you use, the places you work, the sizes of the companies, and the domains you work in will change. One of the great things about us as a community in the industry is our ability to adapt to that change and evolve.
00:02:31.810
So let’s talk about Ruby, which is why we are 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 comfortable programming in Ruby. It has been around for ten years already, and some of us have been programming it pretty much since the language’s inception.
00:02:58.970
There are several reasons why Ruby, and in particular Rails, is so conducive to comfort as a developer. You can work in very diverse domains within the programming language. I have worked on healthcare applications, selling children's books, dating applications, music information systems, and now the internet itself, all from the comfort of Rails.
00:03:26.600
I suspect many of you have also worked in varied domains, doing different things with the tools and frameworks, which is really exciting. We have the ability to learn new things we’ve never encountered before, and we share a common language that allows us to understand and work in new domains. The set of conventions that Rails provides gives us the mechanism to learn the language used in various domains—models, controllers, views.
00:03:56.360
The terminology helps us understand our projects better. We don’t have to be experts in healthcare to understand a healthcare Rails application, provided we understand how Rails works. One observation I've made is that every time I come back to build a new Rails application, a familiar set of actions takes over.
00:04:28.170
I type 'rails new' and breathe an application into life. I spin up a bunch of scaffolding, get the baseline functionality of my application up and running, then pull in some gems, add some CSS, and suddenly I've created another software-as-a-service application. It really is that easy.
00:04:56.160
One thing Rails isn’t often given enough credit for is just how fast you can churn out a truly productive application that starts generating productivity or business value—or, if you’re bootstrapping, actual money. This speed is somewhat driven by the mentality of the people in this ecosystem. It’s not just about the code; it’s not about the technical details. It’s also about the people.
00:05:37.420
This is reflected in actual applications we have in production. This is a controller taken from an application that is in production today at Digital Ocean. The interesting point is, this looks more or less exactly like a scaffolded Rails application, apart from one line of code: 'validate people team' which just calls out to a helper to check that you’re a member of the people team at Digital Ocean. The rest is scaffold, and I've managed to create useful, meaningful production business value without having to write practically any code. It’s a powerful thing.
00:06:12.630
Now, Rails controllers don’t always look like this. Sometimes they resemble a twisted mass of unpacked parameters, new enough objects dispatching service method calls. The fact that I couldn’t fit the whole controller on the slide should tell you something. Remember, as members of this community, I think most of us have an inherent reaction to that, which is, ‘I have to refactor that right now.’ That urge is built into our ecosystem.
00:06:45.500
I look at this and, as an expert maintainer of open-source software used every day, I have strong feelings about how I would begin to break this apart. But if you’re newer to our community, or if you don’t yet understand how to do that, it turns out we’ve built resources for you. We have talks from people like Ben Ornstein, Katrina Owen, and Sandy Metz about how to refactor. We have books by Sandy, Katrina, and others.
00:07:11.630
The point is, if you don’t yet fully grasp how to execute what the community values, we also value learning. You can learn, pick things up, and it’s incredible that we’re all here exchanging knowledge and learning from each other. I believe this is reflected clearly in the number of boot camps that have sprung up in recent years, which are teaching people new to programming how to get the skills to switch careers.
00:07:51.520
If you look at the curricula of these boot camps, they almost all feature test-driven development from the very beginning. Now, 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. However, it's a useful tool when you're a beginner because it gives you an understanding of stability. It helps you grasp how well-factored a piece of code is, and when you’re starting out, everything seems daunting.
00:08:40.180
Having something to hold onto that the community has blessed, built, and nurtured over many years is incredibly powerful. This brings us to understanding Ruby as an ecosystem, where we prioritize software quality. We spend considerable time thinking about our objects, our factorizations, our growth, and our applications—or so we claim. I know everyone in this room has, at some point, worked on a Rails app they weren’t proud of—one full of bugs, mistakes, and paired-down code.
00:09:20.530
But the important thing is that we all hold within us an understanding of where we want to go. I suggest that the ideal Rails application is a well-factored monolith. It’s a single, sizable codebase that everyone on your team collaborates on. It's supported by a single large database, and there may be some caching involved; it looks a lot like the Rails way.
00:09:52.160
Despite many things said on the internet, design practices work for specific people, but who are those people? Think about who's in the room, the age of the Ruby programming language, and how businesses tend to operate. You can sort of chart a curve. Rails is a relatively young framework; it’s only been popular for five, six, or maybe seven years at this point. Ruby is not significantly older than that in ways that matter, which means most Rails companies are small.
00:10:35.810
They haven’t had the time to become the run-away successes that the usual patterns predict. So, if most Rails companies are small—and we are a community that values sharing our knowledge—it implies we’ve created a toolkit suited for small teams and small companies. That isn't a bad thing; it’s who we are and where we came from. However, it’s also important to note that in 2017, you as the engineer of a Rails app are more likely to succeed than ever before.
00:11:12.720
It’s never been more likely that Rails will work for you and that you’ll become a runaway success, leading to hiring hundreds of engineers. However, these are outlier cases—the few survivors among us. We don't have a large number of cases represented here. 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.
00:11:45.300
This is not yet our sole problem; they are effectively research talks exploring new inventions for which we don’t yet have optimal patterns. So, the question I’d like to explore is, how can we prepare to build effectively for companies that scale? To help them grow successfully, breaking away from our wildest dreams, because that is happening more frequently.
00:12:14.130
I think the reason we hear a lot of 'Ruby is dead' rhetoric is because our community is growing in a way that it hasn't before, and it feels misaligned. When considering how we can change our perspective, I suggest taking a step back and looking at what others are doing differently. It’s crucial to recognize that there’s one language, one ecosystem, and one group of people particularly well-designed to build large scalable teams, and that’s Google.
00:12:58.390
Now, don’t malign me for this, but none of us have the problems that Google does. Google’s engineering organization is larger than any engineering organization represented here, unless someone from Google is present. It’s unfathomably massive. It’s interesting because if they value certain aspects, those may not be the things we care about, but understanding why they do can be enlightening.
00:13:25.640
To understand why Google created the Go programming language, we need to consider their hiring patterns. Google recruits thousands of fresh college graduates annually, and while working within teams, it’s highly unlikely they ever directly communicate with the people whose software they’re consuming. As a result, they have to build scalable designs beyond just single-team communication.
00:14:06.410
For example, one valuable principle is that machine communication scales better than human communication. If you can have a computer inform someone about a fact, it saves a human from having to communicate it directly. Go exemplifies this well through forced error handling—a concept where, if an error can occur in your system, you must handle it, or the program won’t compile.
00:14:35.070
Ruby, in contrast, loves the happy path. Matz's Nice (Matz is nice, so we are nice) philosophy results in an obsession with programmer happiness. We think about designing programs to succeed but largely ignore the error cases. How many of you are running an exception tracking framework in your application? It's probably everyone.
00:15:16.044
The underlying reason why programs fail is that any I/O operation can fail for various reasons. It's not always clear whether an operation involves I/O or not. Previously, I have had to dig as deep as possible into the source code to ascertain potential exceptions, relying on documentation written by humans to be accurate.
00:15:50.640
Go’s error handling approach is different; functions can optionally return errors as value types. Errors are values that don’t crash your program; they don’t disrupt execution. Instead, you simply return them, and the compiler requires you to handle them. Many Go programs have a clear linear flow in code, while error handling is handled in indented sections. This pattern ensures that we build correct network communication.
00:16:27.910
Nothing prevents us from doing this in Ruby. We can create forced error handling in Ruby too! For instance, I can define a GET method that takes a URL and fetches it, returning response objects. We can enforce consumers of this client to deal with the error transparently in their error-handling parts.
00:16:59.960
Imagine this context: if a request fails, the program won’t run successfully anymore unless we shovel a success and failure proc into it. This provides clear documentation in the method signature that this action can fail; no need to sift through source code or documentation to find hidden traps.
00:17:29.990
Next is GRPC, short for Google Remote Procedure Call, addressing the challenges of JSON communication. Sometimes, errors arise due to incorrect keys or the remote API sending back the wrong response payload. GRPC forces you to define a manifest of your service, detailing the methods and messages utilized, ensuring your client-server interaction operates seamlessly without hassle.
00:18:04.860
There’s no need to deal with serialization or error-handling code manually. This embodies the principle that machine communication can scale more effectively than human interaction. Moving away from this concept slightly, I want to bring up Go's context system.
00:18:38.110
In Go, context is an object that works as a map from strings to other strings that you can pass through functions—user IDs, request IDs, etc. Every function handles that context, collecting state they can use later. How many of you dread wading through Rails logs? I suspect it’s a few. For instance, when you run an Active Record call, you can lose track of which request instigated it or when it started and finished.
00:19:23.560
Rails production logging can turn into a puzzle. Did the third-party service get called? Did it not? What transpired? It can be confusing, but Go’s logging system is structured to remedy this.
00:19:56.050
To quickly summarize, there’s this concept in software engineering that your codebase reflects your organization's structure. If you're a small team communicating all day, every day, then a small Rails monolith is exceptionally well-suited for you. I’m not criticizing Rails; I wouldn’t be here if I did. However, as those teams grow, it becomes more challenging to work on a single monolithic Rails application.
00:20:22.740
I suspect many of you have experienced this at least once. As companies using Ruby expand, I constantly ask myself whether I'm beginning to dislike Ruby due to its faults or due to how we have developed. I believe it’s the latter.
00:21:04.270
I predict the Ruby ecosystem will continue to evolve, growing exponentially and accommodating larger teams. To counteract the 'Ruby is dead' narrative, we need to embrace these changes, transforming how we construct our applications rather than resisting them.
00:21:34.160
If our code reflects our organization, then on a grander scale, our ecosystem mirrors our community. Our community today is undergoing massive changes, and I believe we need to adapt to those changes to keep moving forward.
00:22:04.150
That’s everything I have. I just have two quick wrap-up notes. First, I work for Digital Ocean, in case that point hasn’t been reinforced throughout this conference.
00:22:09.190
Like every other tech company in the world, we are hiring. I’d love to chat with you, or you can reach out at the back to connect with my colleague who has just joined us.
00:22:29.670
Now, on a personal note, if you couldn’t tell by my accent, I’m from elsewhere, but I currently live here in New York City. It’s been a remarkable experience, and I'm excited about tomorrow's New York City Pride Parade. If you’re around after the conference, consider attending.
00:22:51.850
Thank you very much, and enjoy the rest of the conference.
