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!
