Ruby Video
Rails 3
The Great Rails Refactor
Yehuda Katz
@wycats
Summarized using AI

The Great Rails Refactor

by Yehuda Katz

In his presentation titled "The Great Rails Refactor" at the MountainWest RubyConf 2009, Yehuda Katz discusses the ongoing evolution of Rails, particularly focusing on Rails 3 and its development trajectory following the Merb merger. Katz emphasizes the strategic shift in Rails development towards a more modular, user-friendly framework that supports ORM agnosticism and improved performance.

Key points from his talk include:

  • ORM Agnosticism: Katz highlights the importance of enabling Rails to work seamlessly with various Object Relational Models (ORMs). He introduces the concept of Action ORM, which allows different ORMs, including Active Record and DataMapper, to be compatible within Rails, simplifying the development process for users. This shift aims to provide a single, expected interface for various objects without forcing developers into rigid architectures.
  • Use of Rack: The discussion moves to the integration of Rack, which helps unify how applications process requests. Katz notes the significance of middleware in enhancing Rails applications' performance and reliability and emphasizes the modular approach being adopted to facilitate connections between different components of the framework.
  • Callback Optimization: Katz discusses the historical challenges of callbacks in Rails applications, proposing a more structured callback system to reduce processing times while maintaining needed functionalities. This is part of the larger initiative to improve performance throughout the Rails framework.
  • Action Pack and Action Controller Enhancements: A reorganization within Action Pack and Action Controller aims to streamline complexity. This modular approach allows developers to mix attributes like helpers and layouts, making it easier to enhance Rails applications.
  • Community and Compatibility Focus: Katz stresses the importance of improved accessibility and clarified API distinctions for developers. This is aimed at fostering innovation and developing a more inclusive environment where smaller developers can thrive without being limited by tightly coupled libraries.
  • Performance Progress: Finally, Katz remarks on Ruby and JRuby's performance, noting significant improvements that align them with other mainstream dynamic languages, paving the way for future developments in the framework.

In conclusion, Katz's presentation advocates for a flexible, user-oriented Rails framework design. He encourages the developer community to engage in building extensions and alternatives, ultimately driving a healthy and competitive ecosystem of development. Participants are invited to a hack fest later in the day, emphasizing community collaboration and hands-on experience with the new features of Rails 3.

00:00:11.759 I'm here today to talk about Rails and, more importantly, the future of Rails. Rails 3 relates to the merge, but over time, our focus has shifted more towards planning the next version of Rails. So, today, I will discuss how Rails 3 is progressing rather than detailing the specific features being integrated from Merb. However, if you're familiar with Merb, you will recognize elements from it in my talk.
00:00:37.440 First of all, who am I? I work for Engine Yard, which is an awesome company. Many of us are here today; for instance, John has already spoken, and HurriKane will be discussing Vertebra soon. I'm here to talk about Rails, and we're also hosting a hack fest later today, about which I will provide more details shortly.
00:01:08.640 For a year, I worked for Engine Yard primarily on Merb. I joined in January and worked extensively on Merb until December. Now, my focus has shifted to Rails, and I collaborate closely with the fantastic UI Solo team. EO Solo is currently a Merb application, and I'm hopeful it will evolve into a Rails application one day. Essentially, Engine Yard Solo is our cloud offering, using the Engine Yard stack on AWS.
00:01:44.560 We're giving away two days of Engine Yard Solo access at our hack fest tonight, so I encourage you to stop by. If you sign up, you'll receive a $50 rebate on your first month. The first month is prorated, so you will be paying a minimal amount.
00:02:00.479 We will have several people from the Solo team available to provide support, helping newcomers get up and running, and demonstrating what's going on. It's interesting because Solo is a non-trivial application, so being in the same room as the team and discussing both Merb and Rails has provided me with insights into some obscure topics I wouldn't typically encounter in a standard app.
00:02:22.400 Now, let's talk about some significant topics.
00:02:28.160 I have 30 minutes, so I've narrowed down the discussion to a few essential topics. While I won't cover JavaScript or performance in detail, I will focus on some critical points. The first topic is ORM agnosticism. This was a significant discussion point in Merb, aiming to allow the seamless integration of various ORMs into Rails.
00:02:58.640 This was a key aspect of the merger, and everyone agreed it was a good idea. Indeed, it is possible today to use different ORMs like DataMapper or SQL within Rails, although it can be quite challenging. For instance, while you could use SQL or DataMapper with Rails, specific objects may not be compatible with form four at all. What we mean by ORM agnosticism is that an object should support various types like Active Record, SQL, CouchDB, Data Mapper, SimpleDB, or any other object, as long as it adheres to a designated interface.
00:04:12.879 Merb previously attempted to approach this in a somewhat unclean manner. We relied on a method that checked if an object had errors, and if it didn’t, we presumed that it was non-compliant. Depending on whether the object had an error or not, we would identify if it complied with either SQL or Active Record. However, this led to two valid interfaces, making it impossible to support objects that did not have errors. This situation needed to be avoided in Rails 3. The ideal solution is a new abstraction, which we are calling Action ORM, written by Laurie.
00:05:53.840 Action ORM essentially provides a way to specify a proxy around an object. For example, Action ORM looks strikingly similar to Active Record, essentially allowing any ORM to mimic Active Record. This is an essential part of the design, ensuring that all the required functionality is met. There are two options for ORM makers: the first is compliance, mimicking Active Record precisely, and the second is specifying a proxy that aligns with Active Record.
00:07:01.320 As end users, you will simply use DataMapper, and Rails will manage all of this internal complexity. The difference is that the existing systems must now accommodate either situation, whether it's an object that complies or an ORM proxy that fulfills all necessary criteria. In essence, using Action ORM simplifies the process significantly for developers.
00:08:17.600 The changes we're implementing also lead to performance optimizations by preventing redundant proxy object generation whenever possible. This also reinforces the importance of easing the code requirements within Rails.
00:09:52.000 The second key area I want to discuss is Rack. In Merb 1, Rack was primarily used to address the proliferation of framework servers. It abstracted server interactions significantly, simplifying the booting process for various applications. Notably, we transformed the IRB version of Merb and the script runner version into Rack handlers.
00:11:00.800 With Merb 1, we went a step further by adding the ability to run supported servers in a forked cluster, benefiting from Ruby Enterprise Edition's forking capabilities. This innovation was possible due to the existence of the Rack abstraction. Additionally, we've integrated middleware into our applications, such as path prefix, conditional get, and static file serving middleware. These middleware capabilities enhance performance and reliability in production modes.
00:12:45.840 While Rails 2.3 improved middleware usage significantly, converting every controller and router into a Rack endpoint, we also included several middleware options tailored for flexibility and user customization in Rails applications.
00:14:01.600 Merb 1.1 will similarly adopt these implementations, allowing for a unified approach alongside Rails' forward momentum. Our goal is to have a master router that can efficiently integrate and route requests to other applications, such as Sinatra or advanced Rails-embedded controllers.
00:15:16.000 This structure promotes a modular framework aimed at robust competition. We want to enable developers to build and connect discrete components flexibly without undue interference, thus encouraging diverse development paths. It's essential to support the emergence of numerous viable plugin APIs as well, allowing smaller developers to innovate without being overly reliant on core code.
00:16:05.600 We recognize that callbacks historically account for significant execution time in Rails applications, and as part of the ongoing refactoring efforts, we're adopting a more unified callback system with improved compilation capabilities. This approach will reduce time spent on callback processing without sacrificing functionality.
00:17:55.280 Additionally, there are substantial advancements within Action Pack and Action Controller, resulting in a more streamlined system that reduces complexity while enhancing performance and reliability. We're also in the process of extracting Action Dispatch into its modular framework, which will facilitate better organization and understanding of our components.
00:19:45.680 The Abstract Controller reorganization will allow developers to mix and match attributes, such as callbacks, helpers, layouts, and renderers without the constraint of their current coupling. This modular approach aligns with providing strong abstractions that enable users to optimize their applications in Rails 3.
00:21:38.880 As we evolve Merb and Rails 3, we are fundamentally addressing the community's need for better APIs, including distinguishing between public and private APIs and laying the groundwork for a formal plug-in API. This will ensure that users are not overwhelmed with unnecessary complexity while providing robust extensibility.
00:23:00.480 We want to prevent the bottleneck scenarios that arise when too many functionalities are tightly packed into traditionally coupled libraries. This will enable the community to focus on their domains of interest and rapidly innovate and enhance the framework.
00:24:53.600 In terms of performance, both Ruby and JRuby are now comparable to other mainstream dynamic languages. This is a significant achievement for Ruby, and it paves the way for future evolution. While the frameworks themselves still have performance considerations, we are continuously making strides to enhance their efficiency, especially considering upcoming features.
00:26:50.560 Lastly, we're striving for competition to manifest on a feature-by-feature basis rather than across the entire framework. We aim to create a robust interface environment where innovative elements can coexist. In closing, anyone can now engage in building extensions or alternatives within Rails 3, fostering a healthy development ecosystem.
00:28:40.560 Thank you for being here today. I'd like to open the floor for one question.
00:30:26.160 Yes, the hack fest is tonight at Engine Yard on the 16th floor. There will be food, drinks, and free Engine Yard Solo access for two days. It's going to be an exciting event!
Edit
Explore all talks recorded at MountainWest RubyConf 2009
+3