00:00:27.289
Before I get all the way into that, I wanted to mention that sometimes you write a talk proposal with certain ideas in mind, and then it ends up coming out completely different from what you imagined. This is one of those cases, so I really hope you like it. This talk is titled "Type. Context." Let's get started.
00:00:48.000
Founding a software startup is hard. Building a Java enterprise application is difficult enough, but when you add in the need to set up a physical server, take it down to the data center, wire the networking, and configure it to work, it becomes a real hassle. I remember spending thousands of lines of XML configuration just to get my application working in production using Apache Tomcat. It was a nightmare.
00:01:06.000
If I walked into a VC office in 2017 and told them that was my plan to build a new software startup, I would have been laughed out of the room. We’ve spent years developing infrastructure as a service, with companies like DigitalOcean and platform as a service companies ensuring that no developer ever has to go to a data center to put an application on the Internet. We built frameworks like Rails and Django to ensure that we don't have to write thousands of lines of configuration to create an application.
00:01:35.600
These days, technology has advanced significantly compared to the 2000s and late 90s. Back then, it was entirely reasonable to have a heavy reliance on heavy, complex configurations. It’s worth noting that in those times, there were advertisements claiming that 'nobody ever got fired for buying IBM.' People in 2017 can be quick to criticize the technology choices of those earlier eras, but the truth is that they were clever individuals working hard to build the internet as we know it today.
00:02:12.000
When we work in software engineering, context changes over the multiple decades of a typical career. The industry evolves, and what companies thrive may change. If you can't keep up with these changes, your career may suffer compared to those who can. With that in mind, let’s discuss Ruby.
00:02:58.000
It's easy to become comfortable as a Ruby programmer. Ruby has been a popular programming language for about a decade, and many of the longest-serving Ruby programmers in this room will likely have been programming in Ruby for nearly that long.
00:03:10.000
There are many reasons why it’s comfortable to be a Ruby programmer, and I think one of the biggest reasons is the robust set of domains now available with Rails applications. We have applications built in Ruby for everything from healthcare to children's book publishing, cloud services, dating websites, and music analysis. You can essentially build anything with Ruby, and people are indeed doing so, which allows Ruby developers to transition across various industries easily.
00:04:06.400
Having a thorough understanding of how Ruby and Rails operate lets you quickly grasp what’s happening in any given application due to the conventions we use for structuring our code. We're very deliberate about how we organize our files and how we interact with the tools we create, which gives us a significant advantage. If I were to build a new software as a service application in 2017, I’d be using a set of techniques that are now ingrained in me; creating a 'rails new' command would breathe life into an application.
00:04:43.900
I would generate some scaffolding to lay down all the basic functionality, sprinkle in a few gems, add some CSS, make a few tweaks, and I could be done very quickly. With minimal effort, I would have built an application capable of generating revenue. Rails deserves credit for this, as it enables developers to build applications faster than anything else around.
00:05:25.300
However, Ruby on Rails is more than just incredible productivity; it represents a mentality and a community. It's the group of people in this room who have come together to discuss what our community values and where we are headed. This is evident in the code that we write in most Rails applications. A common sight is code that looks almost identical to the default scaffolded Rails controller.
00:06:05.000
Even the simplest changes we make can serve important purposes. My own application is currently live, serving real web traffic, and it provides genuine value. The power of Rails enables us to write minimal code while delivering tangible business value, which is impressive to decision-makers in our organizations.
00:06:51.000
Yet, not all Ruby on Rails applications are clean and efficient. Many can devolve into complex, unwieldy code bases featuring massive searches, excessive data manipulation, and easy-to-lose threads of logic. As a seasoned Ruby programmer, I recognize when this form of code doesn't adhere to our community standards. We have clear guidelines around when to refactor code and how to keep codebases manageable.
00:08:08.400
For newer developers, this complexity can seem daunting, but our community has invested years in creating tutorials, talks, and resources aimed at fostering learning and improving skills. We are a community deeply committed to learning from one another.
00:08:31.500
When newcomers to the Ruby community attend coding schools or bootcamps, they are often introduced to test-driven development (TDD) early on. TDD serves to help beginners understand how to write functional, high-quality software. While TDD doesn't guarantee clean code, it acts as a helpful crutch for newcomers, while highlighting our commitment to software quality.
00:09:31.200
Despite this, it's clear that not every Rails application fulfills the standards we aim for. You might find yourself using messy, poorly structured code, which might stem from a need to accelerate delivery due to business pressures. Many developers experience frustrations related to cumbersome application upgrades and long deployment times.
00:10:11.300
Despite imperfections, we construct methods for specific reasons. Often, we operate within a business context that necessitates rapid application deliveries to provide value or meet deadlines. Generally, we intend to return to refactor later, but the reality is that many of us never do.
00:11:01.500
So, when we talk about what constitutes a good Rails application, a reasonable answer might be a well-factored monolith. It's cumbersome, yet easy to work with, despite potentially relying on one significant database to conduct various operations.
00:11:43.000
It’s fascinating to note that there are more smaller companies compared to larger corporations, and Rails has only really become popular in the last five to seven years. This means that many companies leveraging Rails fall within that smaller context.
00:12:29.900
While Rails has been around for ten years, with a few standout successes like Heroku and GitHub, not many are achieving similar scale. This raises questions regarding Rails' future viability for teams who want to maintain growth. If Ruby is going to see greater adoption, we must facilitate larger use cases.
00:13:26.300
Kari mentioned earlier that it's great to use Ruby until it stops being suitable for your system, which presents an increasingly common challenge. My objective for the next ten minutes is to explore how we can optimize Ruby on Rails to better serve larger teams.
00:14:02.300
To achieve this, I’d like to look at other programming languages and communities for insights. I might be that person at a Ruby conference discussing Go, but there's a valuable paradigm in the implementation of this programming language.
00:15:01.000
Go was designed by Google to address engineering challenges faced by a large engineering organization. Google’s engineering team is vast. They hire thousands of fresh graduates each year, creating a context that's drastically different from what most Ruby developers experience.
00:15:55.700
In the Ruby ecosystem, many job postings require seasoned individuals, which poses a practical challenge in hiring. Google, by contrast, can deploy software across a massive organization, navigating systems that operate at a scale most of us rarely encounter.
00:16:24.300
However, taking lessons from Google doesn't mean we should all rush to emulate Google's infrastructure. Instead, we can examine their practices for ideas that could translate into meaningful improvements in Ruby.
00:16:59.900
One aspect we could consider is error handling—which is a central feature of Go and a focus within professional programming environments. Ruby, as a language, attempts to make developers happy, yet recovering from production errors remains a critical component of operational success.
00:17:55.900
With Go, error handling involves explicit checks and the handling of potential failure states, leading to a clearer communication of intent throughout the code. While it may seem cumbersome, it ensures that developers are aware of possible failure states when utilizing external systems or libraries.
00:19:12.100
If a system doesn’t allow for proper error handling, unrecognized exceptions can cause significant problems in production. One suggestion is to adopt a pattern similar to Go, ensuring Ruby developers must address potential errors instead of sweeping them under the rug.
00:19:49.400
Another crucial aspect of Go worth discussing is the 'context' object, which enables the passing of request-specific data throughout the various calls in a system. Its usage ensures that valuable data, such as request IDs or user info, travels with the request, simplifying logging and auditing processes.
00:20:32.000
When we encounter issues in our systems, not having complete context hinders our ability to debug effectively. By employing a context-like mechanism in Ruby, we can navigate complex interactions more robustly.
00:20:55.600
In wrapping up, I want to stress that the Ruby and Rails ecosystems can still thrive within the larger context of technology should they adapt to accommodate the needs of rapidly growing organizations. We are in an environment with an increasing number of developers and complex codebases.
00:21:18.130
I work for DigitalOcean, and they were kind enough to sponsor my presence here. We are hiring, so I am morally obliged to mention that.
00:21:59.960
That really is all I have. Thank you very much for your attention!
00:22:10.000
I will take questions for the next few minutes if anyone has any. Great, no questions. Thank you very much!
