00:00:13.280
Okay, let's start. Let's go down the line and have everyone introduce themselves.
00:00:20.560
Jeremy, are those mics working?
00:00:25.920
Okay, go ahead and try again. I'm Jeremy from Basecamp.
00:00:31.039
A bit sweaty, I'm Aaron. I'm not a pony.
00:00:39.840
I'm Godfrey. I'm Santiago, co-founder and CEO of White Works.
00:00:44.879
I'm Guillermo, from Colombia, and I work at a company named Wright.
00:00:52.480
Hi, I'm Andrew, the CTO of Unboxed and also working on Pixel Tricks on GitHub.
00:00:58.960
I think we don't have a lot of time, so I thought we could talk about upcoming changes. We talked a lot during Ruby Heroes about how each of you ended up on the Rails core. I think that’s very interesting to a lot of people.
00:01:04.720
Let's start this way: How long have you been on Rails core, and how did it come about? Just take a minute or so to share your experiences.
00:01:16.400
I've been on the Rails core since late 2012, and that came about through contributions to Rails. I started contributing in 2007 because I had a problem with my app. A bug in Rails broke my application when the next version came out, so I thought, 'I can fix this in Rails.' I submitted a patch and gradually worked from there.
00:01:35.680
Like Andrew, I began contributing to Rails after encountering issues with the latest versions breaking my application. I've been part of the Rails core for about three years now.
00:01:52.720
I've been involved with Rails core since 2010, primarily based on issues I encountered in my applications. I got started through a hack fest where I helped triage the issue tracker, and that's how I got involved in everything.
00:02:31.040
You might notice a trend: it seems like everyone started contributing by finding bugs in their own applications. I thought, 'Why doesn't this work?’ and figured I could just fix it. Years later, I came onto the Rails core when Aaron merged my patch, and I started doing more from there.
00:02:55.840
So have you ever done that? We're still here, and you can still do that.
00:03:16.560
My turn! There were no bugs in my application; I just wandered in off the street. I have no idea why I'm here. How long have I been on Rails? I have no idea. Maybe four or five years, so that seems legit.
00:03:32.440
I'll echo the pattern; that's how I got involved with Rails too—when it first came out. I was trying to port applications I had written in Ruby, PHP, and Java to do new development in Rails, and I noticed missing pieces.
00:03:39.200
What I've noticed is that many people come into Rails by noticing issues and addressing them. It's interesting because while it seems easy, it's actually surprisingly rare to find long-term contributors. If you check out contributors.rubyonrails.org, you’ll see thousands of people who've done one thing, which is great. However, once you start doing two or three things, it becomes a rare territory.
00:04:01.760
This leads into my next question for you. We'll start with Jeremy, as you probably have the most to say about it. Can you explain the process for introducing new people into Rails core? Is it a formal procedure or more informal?
00:04:14.720
It's a very informal process. While it has become more formal over time, I often feel like the way people get introduced to the core is through their contributions. It’s almost as if they are already part of the core team by virtue of what they're doing. For example, Aaron was doing things, and it became more of an issue not to have him on the team.
00:04:51.919
If you hassle the other people too much, you'll find a way in!
00:05:10.880
So you've been on the Rails core for different amounts of time. One way Rails stays fresh is through change. For instance, not many people are doing RJS anymore. Let’s have everyone answer two parts: What’s the most interesting change you've seen since you joined Rails core, and what upcoming change are you excited about?
00:05:49.440
I’ll start. The most exciting change I'm looking forward to is Action Cable because I have no idea what it is. Since joining core, the work I did with Active Record was probably my favorite. Another important focus for me is the emphasis on performance and measurement. We are introducing benchmarks and monitoring performance between versions, which I hope will help make Rails faster.
00:06:26.479
In the past, I think the most interesting feature was Bundler and the asset pipeline. People have often loved to hate them, but they have turned out to be incredibly positive and constructive additions to app development. I remember struggling with Bundler issues, but now I could not live without it.
00:06:56.800
I'd like to give a shout out to Rafael, who handles most of the new contributors. He’s the first contact for most people with Rails contributions. His comments on pull requests are invaluable; he serves as our welcoming committee and has been one of the best things that's happened over the past five years.
00:07:26.560
This is a just-in-time question generation. Sometimes I need to pause and think. Are you taking questions from Twitter?
00:07:42.120
No, but if you want to tweet questions at me, I'll put them in the queue. We have a whole slew of people wandering in, and I don't know where they've been all morning!
00:07:56.400
What interesting changes have you seen or are excited about?
00:08:07.760
I'm excited about the work Santiago has been doing on the Rails API project, which will be included in the next version. Good job, buddy! I'm also excited about our performance work, making integration tests faster and requiring Ruby 2.2 as a default to run our applications.
00:08:36.320
Regarding the Rails API, not only because I didn't work on it, but also because at Wakers, we deal with multiple applications, some using Ember on the client side. I believe this will help integrate such applications as first-class citizens in Rails.
00:08:55.760
While everyone else is discussing code changes, I’d like to mention the improvements in the ecosystem. We have a much better process for testing our releases, like using Discourse to test the latest version of Rails. Rafael has done an amazing job managing the issue tracker. We even now have a weekly newsletter detailing what goes on with Rails every week!
00:09:34.200
I remember when Rails progressed from version two to three; there was a performance regression. Given the increased code complexity, does it feel like those performance issues have been resolved now?
00:10:01.280
I don't think so. We have much better tools now to monitor performance, allowing us to answer these questions more definitively. In the past, we didn’t necessarily know about regressions until they were reported.
00:10:16.560
The questions that are easy to ask are often easier to answer. Active Record often receives a lot of attention. Regressions tend to be glaring and easier to identify. However, it's the subtler changes that sometimes lead to performance issues that we might overlook.
00:10:43.560
Additionally, the large surface area of the Rails API makes it difficult to catch every potential performance issue. Even with benchmarks, there can be specific use cases in certain applications that we miss during monitoring.
00:11:08.560
The improvements in Ruby itself from 1.8 to 2.2 have significantly boosted Rails performance across the board. These changes, although subtle, contribute to how we write Ruby code today.
00:11:44.960
With Rails having such a large feature set, how do you individuals and as a group decide which areas to work on? For example, you finish something on Friday and sit down on a Monday morning—how do you prioritize your Rails work?
00:12:01.600
Personally, I often pick issues related to time and routing. I search for interesting problems in the issue tracker. I usually do work on weekends or evenings, but I try to set aside specific times for Rails work when I can.
00:12:45.000
As a group, we keep a loose list on Basecamp of major areas we want to work on. For myself, I handle issues that arise at work and compile a to-do list. Random projects often pop up when it's time to prepare for things like Google Summer of Code.
00:13:30.239
As a team, we also follow the significant changes throughout Rails development, which often emerge from our ongoing work on Basecamp, where we identify areas that need enhancement due to our experiences.
00:14:00.320
We approach this collectively, speculating on which features will be incorporated in the next major or minor release. Some features, like Action Cable, require extensive planning due to their nature in Rails.
00:14:49.600
Many times, upcoming changes are influenced by our real-world experiences with Rails, with our legacy app becoming a reference for what developers want. We can address performance challenges and design insights through the lens of our organization's application needs.
00:15:37.760
Does the issue tracker primarily serve as a tool for tracking bugs and pull requests? How does the community assist in shaping new features versus reporting bugs?
00:16:11.600
We use the GitHub issue tracker mainly for tracking bugs and pull requests. New feature suggestions are usually directed to the mailing list to allow discussions prior to formalizing issues on GitHub. Valid feature suggestions necessitate community engagement to ensure their viability.
00:16:43.840
While we receive feature requests, they often lack the follow-through requisite for actual implementation. A simple wish without engaging in the broader discussion does not help move a feature forward.
00:17:12.800
Rails is in a unique position. Many people use it in various ways, leading to organic discussions regarding community needs. Just because something is convenient for one developer doesn't mean the entire community will benefit.
00:17:44.800
It's crucial to consider what changes will ultimately help the most users, rather than implementing features that might only serve specific use cases. Sometimes, creating a separate gem becomes a valid alternative when a feature has clear benefits.
00:18:21.920
If community members have an idea for a feature, do you prefer them to discuss it on the mailing list before creating a pull request? This could help prevent unnecessary work both for the contributor and for the Rails core team.
00:18:49.600
For larger features, I recommend mailing list discussions first, but if it’s a smaller addition, like adding a method to Active Support, then a pull request is fine. It's often beneficial to gauge community feedback prior to investing too much time in implementing new features.
00:19:18.400
The development of a gem is another way to validate an idea before proposing it as a feature in Rails. Implementing a solution independently provides insight into its usefulness without altering the Rails codebase.
00:19:46.240
The integration of API work has streamlined how web apps can be developed with Rails. Given that many members of the panel are practitioners in Rails, how are you personally utilizing it within your projects?
00:20:15.040
As a consultancy, we employ various approaches depending on project requirements—some using Ember or Backbone, while others utilize the default stack. Ultimately, we align our tech stacks to best serve each project's needs.
00:20:40.800
Similar to Santiago, our team is pragmatic. We might utilize microservices, separate Rails apps for different components, or a monolith based on what’s most suitable for the project at hand.
00:21:26.080
I think our applications are mostly built using a standard stack; nothing too out of the ordinary, but we prioritize maintaining effective integration across different platforms.
00:21:45.760
Speaking of integrations, we recognize the power of small teams in delivering applications across various platforms. By sharing a single codebase, we effectively maintain simultaneous iOS and Android applications that utilize the same resources.
00:22:16.880
It fosters an enjoyable work environment and advantages our flexibility while allowing us to tackle multifaceted projects with a smaller team.
00:22:41.920
With numerous mobile apps being built, are there specific aspects within Rails that have made interfacing with mobile applications easier? The intersection of iOS and Android apps with Rails holds significant importance for many developers today.
00:23:17.440
Achieving content negotiation and providing multiple representations for RESTful resources has enabled construction of apps effectively. Over time, this has proven beneficial, allowing us to serve tailored responses based on device specifications.
00:23:46.080
This functionality has significantly enhanced our workflow, enabling an adaptive delivery tailored to both web and mobile experiences from a unified resource structure.
00:24:13.919
To wrap things up, we have a few questions to explore. Ernie wants to know about the future of 'hash with indifferent access' regarding Ruby 2.2's symbol GC.
00:24:34.080
The concept won’t disappear as that would break existing APIs. Even if symbols and strings became nearly indistinguishable, we would retain the functionality for compatibility.
00:25:07.200
Internally, we don’t use 'hash with indifferent access,' but we do rely on it for user-facing features to maintain usability across various systems.
00:25:36.720
As we wrap up, I want to ask the group about recurring problematic patterns you've encountered in Rails projects. Are there specific ‘code smells’ that you’ve noticed while consulting on different applications?
00:26:03.840
Commonly, I see models excessively split across numerous files, making them hard to locate, particularly when joining as a consultant. I often come across issues where business logic is improperly housed in controllers, leading to confusing structures in the codebase.
00:26:56.560
I've seen gigantic models with lines of code in the thousands. Some contain HTML directly in string format, such as 'render text, complaints,' which can lead to difficult debugging situations.
00:27:35.720
There’s a vital balance in maintaining code readability and organization—striking the right size for models and their methods is imperative.
00:28:09.120
I’ve encountered challenges from developers lacking clear awareness of their application's structure, whether it’s through design patterns seen in talks or through accumulating dependencies in their gem files.
00:28:27.760
Managing gem dependencies and employing effective design patterns is crucial. As Rails practitioners, being conscious of our app's overall organization plays a pivotal role in sustainable development.
00:28:54.560
Lastly, a common coding issue arises from excessive use of modules leading to convoluted debugging scenarios. It’s essential to maintain clarity and keep the code manageable.
00:29:19.360
The final thoughts highlight the importance of code maintainability and organization, positively influencing both user experience and application performance.
00:30:06.320
Thank you all for being here today and fielding my questions. Let’s give them all a big hand!
