Ruby Video
Jeremy Kemper
Panel: Rails Core
Aaron Patterson
@tenderlove
Santiago Pastorino,
1 talk
5 more speakers
See all speakers

Panel: Rails Core

by Aaron Patterson, Santiago Pastorino,, Godfrey Chan, Jeremy Kemper, Guillermo Iguaran, Andrew White, and Evan Phoenix

The video titled 'Panel: Rails Core,' featuring prominent members of the Rails community, addresses the experiences and contributions of Rails core contributors during RailsConf 2015. The panelists share how they became involved with Rails, predominantly through encountering issues with their applications and offering solutions.

Key points discussed include:

  • Introduction of Panelists: Each member introduced themselves, stating their backgrounds and roles in the Rails community.
  • Entry into Rails Core: Most contributors began by fixing bugs in their own projects, with narratives emphasizing a common journey that starts with problem-solving.
  • Changes and Enhancements: The panel reflected on significant changes in Rails such as Action Cable, performance improvements, and the introduction of Bundler and the asset pipeline.
  • Community Engagement: The informal process of how new contributors are introduced to the Rails core team was discussed, highlighting the importance of contributions and volunteer work.
  • Ongoing Developments: Upcoming changes like the Rails API project and continued work on performance benchmarks were mentioned as exciting prospects for the future.
  • Feature Request Process: The role of the GitHub issue tracker versus mailing lists for discussing new features was clarified, with encouragement for community suggestions to be well thought out before contributing.
  • Best Practices in Rails Development: Panelists shared insights on common issues encountered in Rails projects, highlighting areas such as code organization, gem dependencies, and the importance of model structure.

Overall, the discussion underscores the collaborative nature of Rails development, fostering an inclusive environment for newcomers while continuously evolving the framework based on real-world issues faced by developers. The panel concluded with a focus on maintaining code quality and functionality to ensure a positive impact on users and applications.

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!
Edit