Rails World 2023
Rails Core AMA
See all speakers
See all 11 speakers

Summarized using AI

Rails Core AMA

Aaron Patterson, Carlos Antonio Da Silva, David Heinemeier Hansson, Eileen M. Uchitelle, Jean Boussier, Jeremy Daer, John Hawthorn, Matthew Draper, Rafael Mendonça França, Xavier Noria, and Robby Russell • October 16, 2023 • Amsterdam, Netherlands

The video titled Rails Core AMA - Rails World 2023 features a panel of ten Rails Core members discussing various community-submitted questions regarding the future of Ruby on Rails, best practices, and contributing to the core team. The session, hosted by Robby Russell, engages the audience with insights into the development and governance of Rails, as well as the integration of community contributions.

Key Points Discussed:
- Introduction and Format: The AMA begins with a light-hearted note, with members humorously sharing their favorite colors before diving into serious topics.
- Essential Parts of the Rails Codebase: Members discuss no specific must-read section in Rails but recommend examining parts that seem like magic to understand the underlying processes better. Carlos suggests focusing on the integration of controllers and views.
- Lesser-Known Features: The team reflects on Rails 7.1’s support for composite primary keys, highlighting their preference for keeping complexity hidden until required.
- Database Support: Matthew explains the historical use of MySQL in Rails applications but advocates for PostgreSQL as a preferable choice for new applications due to its compelling features.
- Community Involvement: Eileen discusses the criteria for joining the Rails Core team, outlining a pathway from triage to becoming a core member and emphasizing community interactions.
- Feature Integration: David explains that features should solve general problems in web development, not just specific application needs, and he highlights the importance of proving out ideas through gems before integration into the core.
- Backward Compatibility: The complexity of maintaining backward compatibility in Rails while introducing new features is discussed, with emphasis on security updates and regular upgrades.
- Future Vision: The team encourages pull requests for extending functionalities, linking them to developers' real-world needs and applications.
- Open Environment: The AMA wraps up by encouraging an open community atmosphere where diverse backgrounds are welcomed, and contributions respected. The panel recognizes the dedication of core team members.

Conclusions and Takeaways:
- Community engagement and contributions are essential to the ongoing evolution of Ruby on Rails.
- The development process requires balancing new features with maintaining general usability and compatibility across different applications.
- The Rails community promotes inclusivity and encourages new contributors to engage in meaningful ways, ultimately nurturing a supportive ecosystem for developers.

Rails Core AMA
Aaron Patterson, Carlos Antonio Da Silva, David Heinemeier Hansson, Eileen M. Uchitelle, Jean Boussier, Jeremy Daer, John Hawthorn, Matthew Draper, Rafael Mendonça França, Xavier Noria, and Robby Russell • October 16, 2023 • Amsterdam, Netherlands

Ten of the current 12 Rails Core members sat down to answer questions submitted by the Rails World audience in Amsterdam, such as: How do they decide on which features to add? How should Rails evolve in the future? What does it take to join the Core team?

Rails Core members present were: Aaron Patterson, Carlos Antonio Da Silva, David Heinemeier Hansson, Eileen M. Uchitelle, Jean Boussier, Jeremy Daer, John Hawthorn, Matthew Draper, Rafael Mendonça França, and Xavier Noria.

Hosted by @Planetargon founder and CEO @RobbyRussell.

Links:
https://rubyonrails.org/community
https://rubyonrails.org/
https://github.com/rails
https://www.planetargon.com/

#RubyonRails #Rails #RailsCore #AMA #RailsWorld #opensource

Rails World 2023

00:00:17.560 Good morning, everybody! So, let's see. We posted the last couple of weeks, and we had questions from the community. We reached out and received about 40 questions. We have an hour, so I don’t think we’re going to get through all 40 questions, but we’ll do our best. Thank you, everyone, for being here bright and early. I hope you had a good time yesterday on your first day. Here’s how it’s going to work: I’ve kind of curated the questions and talked about different topics and themes that you were interested in. I’ve combined some questions a little bit, so if your name is not referenced, I apologize. I'm just trying to make sense of 40 questions for everybody. So, if everybody's ready, let's get into it.
00:01:02.680 Uh, also blue. That's great! David, do you disagree?
00:01:11.280 Yeah, I gotta be on Team Blue.
00:01:24.240 All right, this is going well! So, Dr. U, which part of the Rails codebase do you think is a must-read for every Rails developer?
00:01:31.360 I don’t think there’s any specific part that you absolutely must read. The part you should read is whenever you say, "Oh, this seems like magic." You absolutely need to examine it and realize that it’s not magic. You should just go read that.
00:01:42.720 Carlos, do you have anything more specific to say?
00:02:06.079 Yeah, I think the part that people usually use in all of their applications is the integration between controllers and views. So getting to know that a little bit better is a good place to start.
00:02:17.319 What about you, Aaron?
00:02:40.920 I think the number one thing you should read is the implementation of 42—what is that, R 42? Which library is that in?
00:03:01.760 That would be in Active Support.
00:03:08.360 A similar question came through from Anonymous. Is there a lesser-known Rails feature that you wish more developers were aware of?
00:03:36.599 I don’t think there’s anything specific that lots of people should know about but don’t. I think that it’s valuable that there are a lot of features that you only need to find when you need them. I hope that we hide away that complexity.
00:03:56.480 So something like composite primary keys is being better supported now in Rails 7.1. Hopefully, you’ll only come across it if you’re actually looking for it because most of the time, you shouldn’t be reaching for that as your default.
00:04:21.560 For those of you who don’t know what composite keys are, it’s okay. Everybody knows—great!
00:04:41.920 Also, there was a question that came in related to this. Matthew, you know, there are a lot of references to MySQL, and I know from running the Ruby on Rails survey every couple of years, PostgreSQL is far more popular and preferred, despite some of the legendary companies using MySQL.
00:05:06.160 So some people were curious, is there something wrong with PostgreSQL or is MySQL better? What’s your take on that, Matthew?
00:05:47.720 Yeah, I think it’s true that most of us work on MySQL applications. Personally, if I were starting an application today, I would choose PostgreSQL. PostgreSQL is always going to have first-class support in ActiveRecord.
00:06:05.560 I think there’s some historical context to the fact that several of the largest and oldest Rails applications started on MySQL and have remained there without much opportunity to change that choice. There are also benefits where MySQL has a longer history of effective replication, which matters at certain huge scales.
00:06:38.840 But yeah, PostgreSQL is a fully supported database, and I encourage everyone to use it! But as we’re hearing, it sounds like SQLite is the future.
00:07:05.600 Quick thing—I want to do a little activity for you all. Yesterday, David and Eileen both mentioned that there have been nearly 7,000 contributors to the Rails core project.
00:07:22.720 So outside of these 10 people, and all the other two core team members who weren’t able to make it here, if you have contributed code and that code has been merged, could you please quickly stand up so we can see you?
00:07:40.400 Now, stay standing for a moment. If you’ve ever contributed a comment or helped review a pull request, also stay standing.
00:08:03.160 If you’ve submitted a bug report or participated in GitHub issues on the Rails project, tested something, could you also quickly stand up? Look around; these people are part of the community as well. Thank you to everyone, whether you stood or waved your hand. You can sit down now.
00:08:30.960 So, the question for you, Eileen, is just to sip some water. Joshua from Brisbane asks, "What’s the criteria for joining the Rails core team? Do you have any hot tips on joining the cool kids' club?"
00:08:54.560 Well, we actually recently added another team we call triage. Part of that is because issues have merge rights, and we wanted a way to let people get involved earlier before they built up the trust to not merge the wrong PRs. You start out on the triage team, and usually, it’s just if we see you around commenting on issues, running bug reports that people leave, and reviewing pull requests.
00:09:43.000 Once you get triaged, then you can actually add labels and close issues, which is nice because it helps us out a lot. Then the issues team is allowed to merge documentation changes, but not code changes. GitHub has no way to differentiate, so that’s why it’s a high-trust transition from triage to issues.
00:10:01.039 Once you do a lot of work on issues, you move to committers. Committers can merge pretty much anything, but if it’s a big feature, we don’t want you to merge without talking to core first. Core gets the final say.
00:10:32.280 As a committer, usually, you’ve built a couple of features and are really present and active, and you’re nice to the other new contributors. The interaction with the community on GitHub is essential.
00:11:08.440 For triage and issues, we don’t really need a consensus; we just add people to those. For core, we usually have discussions where someone might say, "I think this person is ready for core," and then others might agree or provide feedback.
00:11:49.440 It’s not a strict process and has changed over time a little bit, but I don’t know if anyone has anything more to add.
00:12:12.339 It’s great that many of you are eager to join the cool kids' club! Now, regarding the Rails development environment setup, I’ve found it a little intimidating to start just to run the test suite. Do you feel like there are things the community could do to make that easier?
00:12:58.240 Does anybody want to pair on my laptop later, and we can get this going? Yeah, great! David, how does Rails core decide which features to abstract from the framework? How do you balance proven features from your own apps, like 37signals, against contributions from other teams and different domains?
00:13:41.720 That’s a good question. For me, the most important thing for putting stuff into Rails is that it represents a core element of the problems we’re dealing with in web development. It has to be general enough that it’s not particular to a specific app. You need the vision that if you were starting a new app, you would also want to use that.
00:14:28.760 A lot of the approach I’ve driven for my own contributions and the contributions from 37signals to Rails over the years has been that whenever we start a new application, we have a golden rule: you are not allowed to copy any code from an old application without contributing it to open source.
00:15:29.240 Sometimes that means direct contribution to Rails; sometimes it means a new gem, but having that firewall when we started working on Hay, we were not allowed to just copy things over from Basecamp. That led to the creation of Active Storage, which was an unextracted feature that lived inside of Basecamp for many years.
00:16:13.160 We needed the same kind of code in Hay. It wasn’t going to make it straight in, so it meant the extraction of Action Text, and Active Job came out of that transition as well. There are three major frameworks that emerged from that large transition.
00:17:02.720 I really enjoy working on new greenfield applications because it’s an opportunity to do that. I think the same has been true for other major contributions happening from other companies. GitHub had a wonderful implementation for handling multiple databases, and Eileen and their team worked to extract that.
00:17:53.560 That enabled them to use it for new functionalities, and we can all benefit from that as well. In terms of contributions from the community, one that stands out to me is the internationalization feature, which was added relatively early on.
00:18:31.920 This feature did not originate from any of the core applications. We had discussed it for several years, and then someone stepped up, did exceptional work, and provided a gem that was excellent. It became an obvious choice to include it in the framework.
00:19:03.720 Proving things out in a gem, if you’re not already part of the Rails core team or contributor team, is the best way to go about it: make a wonderful gem and get it on the radar of someone on the core team.
00:19:48.240 A lot of questions that came in were related to the interesting dynamic of 37signals building new apps every few years, while many people have apps that were started 14 years ago. It’s challenging to keep up. How do you balance that and ensure that Rails remains backward compatible, while also providing security updates, which I understand is necessary?
00:20:44.480 At GitHub, we’re actually upgrading Rails almost every week—we are running on Rails Main—similar to what Shopify is doing. Our hope is that by doing this constantly, we can catch any regressions immediately and ensure that things stay forward and backward compatible.
00:21:40.880 Hopefully, that has been your experience that modern upgrades have been much easier. They have been. However, I know it’s still challenging for companies.
00:22:30.800 Raphael from Japan asks what criteria makes a feature worthy of joining the Rails core project? What kind of problems should it aim to solve?
00:23:03.560 I think it needs to be generic enough to solve problems for web developers. One specific aspect I focus on when I review a feature is how generically it will be useful to applications. You might want to add a feature that is specific to a user case, but not every application will need it.
00:23:35.680 I personally dislike most of the Active Support extensions because they tend to not be generic enough. Adding something to prime your boolean is very specific to your needs, and I think a feature I like is one that introduces a stepping stone for your application.
00:24:16.760 Rails is good for starting your application to IPO. There are lots of stepping stones you need to take to get there. It’s not just a matter of throwing Rails on and being ready to IPO.
00:25:00.440 You sometimes need to implement features that increase the resilience of your application or how many requests per second you can handle. I particularly enjoy features that increase the scalability of Rails.
00:25:45.360 Jeremy Benjamin from Del asks if there are plans to support key rotation for deterministic keys in Active Record encryption. Yes?
00:26:10.360 Could you explain what that means? When you have a bunch of data encrypted with one key and need to rotate to a new key, how do you read data that was encrypted with the old one while encrypting new data with the new key?
00:26:41.280 Actually, this is already supported. If you look at the old FastSKeys option, there’s also a method called `reinc` that will decrypt with the existing key and then re-encrypt with the new key. There was a good talk on that yesterday.
00:27:45.360 Aaron P from Seattle asks if you might ever make AAL table public. No. There has been a request to expose AAL, which is the underlying library for low-level relation management. Many feel they need to go deeper when, in fact, Active Record can do what you need.
00:28:56.320 The hazard in exposing something lower level is that everyone may feel the need to reach for that to do something already possible out of the box.
00:29:57.280 Aaron, where do you live? Seattle? What do you say you do here?
00:30:23.160 I didn’t know it was time for reviews, so I received some feedback from the team. I know you had a retreat recently. That was like the first time everyone could meet together in a while. What were some of the big decisions made behind closed doors that we’re all curious about?
00:31:35.679 Sure, I feel very put on the spot here. In general, a lot of my involvement has been around security stuff, which is extremely not fun.
00:32:21.440 Brandon from Brazil asks about the Rails core vision for the future of Rails. Are you open to pull requests for extending existing functionalities, such as how to handle image optimization?
00:32:58.800 A great example is if you want to fix something with Active Storage, I would love a PR. The important thing is to do the feature you want for your own application and that you would have done anyway.
00:33:50.560 I try out ideas often and see if they may be a valuable feature for Rails. Quite often, I learn it’s not generic enough, or the implementation isn’t good enough. These ideas often do not progress further.
00:34:38.880 If you find something that you actually use in your application and feel it is good, that is the time to share it with the community.
00:35:22.760 Rafael, could you speak a bit more about how the team evaluates submitted features? We recently had our first panel discussion about pull requests, and we usually don’t discuss external contributions. One person spearheads it to take ownership of the decision.
00:36:42.560 If we need consensus, we do that; if we don’t, we individually decide whether to merge something. So we have a streamlined way of unblocking ourselves.
00:37:35.920 Everyone has opinions, but it would take too long to wait for consensus. We usually align well, which is why we are keen on it.
00:37:56.240 Joshua from Zurich asks, with Rails being approximately 300,000 lines of code, who on the team really feels like they understand everything?
00:38:27.680 The truth is, everyone on the team is capable of understanding the whole framework. It doesn’t mean we all have it loaded in our heads at the same time.
00:39:07.440 If there’s an issue open, you can read the code. There are a few touchy parts, and you might ping the original author to ask them about it.
00:40:07.680 However, most parts—Active Record aside—can be navigated easily, and we all do our part in bug fixes and new feature developments.
00:40:50.360 Talking about the pressure of being ready for the release of Rails 7.1—it’s not like a strict clock ticking.
00:41:12.080 Aaron, how do you describe the difference between releases (like 7.0 to 7.1 versus 8.0)? Is it arbitrary?
00:42:01.040 It’s pretty much what David decides.
00:42:30.080 Aaron says many things have the potential to be clear, but the issues often lie in naming them correctly or simple life catch-up over ambiguous ideas.
00:43:38.560 On security handling, the general process is to report bugs via our HackerOne account. We hold monthly meetings to monitor and fix issues.
00:44:37.760 Thus, the community can report any security issues and keep dialogue alive as necessary.
00:45:19.680 John, which areas of the framework do you personally find most difficult to work on? Active Record is definitely the most complex with deep mysteries.
00:46:21.680 And as Carlos mentioned, the more recent Active Storage frameworks may seem daunting without a deeper dive.
00:46:59.680 Realizing that many developers come from different backgrounds, it’s important not to become discouraged by paths taken or qualifications.
00:48:24.800 Our community should remain open to all newcomers, celebrating experiences shared, whether by education or self-taught endeavors.
00:49:02.600 Lastly, we take a moment to recognize members of the core team for their extensive contributions and dedication to the Ruby on Rails community.
Explore all talks recorded at Rails World 2023
+25