00:00:04.920
Before I start, I just want to say I'm no longer an engineer, but I want to thank Engine Yard for essentially funding the Rails 3 effort. In addition to Rails 3 getting funded, there’s a lot of community multiplier effect that happens with contributions from people like José, Alim, Aaron Patterson, and Santiago Paez in the audience. We have a bunch of new people that Engine Yard helped pay for by funding full-time developers to answer questions and help newcomers get started. This really made a significant difference to Rails 3 and will continue to make that difference moving forward. I believe Rails 3 is now so strong in terms of the community that we might not need as many full-time contributors, even though Aaron is still full-time. I think we did our job right and that's something to be excited about. I want to thank Engine Yard as they continue to invest time, energy, and money into Rails 3, which is fantastic.
00:01:16.320
My original talk title was 'Extending Rails 3,' but I decided it wasn't the best topic because it's actually too extensive for a 30-minute discussion. José has written a book titled 'Rails 3 Internals for Daily Use' which will be released soon. His book covers many topics, and each topic could easily be a 30-minute talk by itself. I considered focusing solely on that, but I thought you might want to know about some other aspects of Rails 3, so I’ll cover those.
00:01:50.520
The first major topic is that engines have undergone significant changes. We should give a shoutout to Drogus, who worked on this during the Ruby Summer of Code project. His overhaul of the generators was quite ambitious, and he accomplished everything we had hoped for, delivering on his promise to enhance modular applications. I’ll discuss what engines have to offer now, starting with migration. This is the last feature not included in Rails’ real migrations from the engines plugin.
00:02:25.860
Now any engine can ship with a migrations directory, allowing you to copy any migrations easily. For example, it creates a timestamped entry for migrations within your engine, making it so that if you run migrations as you update the gem, it won’t continually copy old ones. There's been extensive discussion on how to best implement this feature, particularly on how to ensure that migrations are not re-copied. I’m happy to report that the copying approach we've adopted has proven to be the best solution, and thus far, it’s working well.
00:03:17.819
The next big advancement involves static assets. There's currently no standard approach for managing static assets in Rails 3 with engines, which can be cumbersome as each engine historically manages its own asset copying. What we want is a solution where engines can simply drop their static assets into a public directory and have everything work seamlessly. In development mode, the static middleware will handle serving assets from multiple engines without necessitating complex setups like nginx.
00:03:41.000
In production mode, the static middleware will continue to serve assets from gems like Devise and Turbo, while nginx will manage the main public directory assets. To ensure that performance isn’t hindered, the static middleware will utilize pre-populated caches, eliminating performance issues by simplifying asset lookups to hash table lookups. We've finalized these details and are confident about the implementation moving forward.
00:04:50.820
Another essential feature introduced is the concept of isolated engines. In Rails 2 and earlier versions, engines were merely a hack that let you modularize parts of your application. However, they were limited in their functionalities, as everything merged into a single application. Now, with Rails 3.1, we have the idea of isolated engines, which are separate, mini Rails applications functioning without the boilerplate boot-up processes.
00:05:19.220
This means that every isolated engine can have its own scoped functionality, making for a more seamless integration with the primary application without worrying about naming collisions or context bleed. With isolated engines, you can directly mount them within your Rails application, treating them like fully-fledged applications within your larger app architecture.
00:06:02.160
For URLs, isolated engines will also possess their route helpers. If, for example, you'd want to create a blog, you could utilize URL helpers that point to its routes without any namespace conflicts. This streamlined approach allows for flexibility in routing and linking components of your application.
00:07:16.020
Furthermore, if you create forms in an isolated engine, the same principles apply: you only need to use the singular entity in the context of your engine. This reduction of complexity simplifies the building of isolated components in your Rails applications, allowing developers to work within the scope of their application logic without having to consider namespace clashing with the application's primary routes.
00:08:44.040
As a result, the mounting process for engines parallels the process for mounting any Rack application. Once you set your namespace, everything else falls into place as it should. This enhancement emphasizes that engines are now treated as first-class citizens in routing and application composition in Rails. They are just as robust as main Rails applications without the overhead of starting from scratch.
00:09:38.400
The next significant improvement is around page caching. With the evolution of Rails towards a focus on HTTP standards, Rails 3 provides a structure for effectively managing cache layers. Traditionally, page caching was somewhat rigid, relying heavily on file system structures. However, with Rails 3, we will be utilizing HTTP mechanisms that allow more flexibility and adaptability.
00:10:24.840
The beauty of the new caching mechanism lies in its ability to create dynamic identifiers for cached elements, namely E-tags. This allows developers to manage resource-heavy operations efficiently by letting the server know if it still holds the latest version of requested content. When the server acknowledges that nothing has altered, it can return an HTTP ‘304 Not Modified’ status instead of processing a full render cycle.
00:11:35.580
This optimization drastically reduces server load by limiting expensive rendering tasks. Moreover, this introduces an opportunity for developers to implement custom responders that can automatically manage E-tags across their controllers and actions without requiring extensive overhead.
00:12:31.920
As for cache validation, Rails will seamlessly incorporate these identifiers, allowing for quick lookups to see if content can be rendered from memory rather than rebuilt. This not only enhances application performance but also alleviates the complexity of requiring manual cache invalidations. The implication of this adjustment will permit a more responsive experience for users, as heavy rendering tasks are offloaded during interactions.
00:13:45.720
Additionally, Rails 3 will shift focus towards optimizing static assets and compiling them during the asset pipeline process. The assets such as SCSS and CoffeeScript will be treated similarly to ERB templates, not just top-level files like before. They will be processed and rendered directly inside the application, ensuring that they are precompiled where necessary without involving cumbersome steps during deployment.
00:14:47.460
The benefit is that Rails developers will no longer need to worry about manual compilation as the asset management will have dedicated processes compensating for it. By implementing tools for production and development parallel usage of assets, Rail 3 seeks to standardize how assets are handled and optimally delivered to clients, further accelerating performance.
00:15:53.520
Shifting gears, there’s also talk about a merging of Compass and Lemonade into Rails, which brings additional capabilities into the asset delivery process. The integration will provide built-in support for managing sprite assets. This lets developers define and combine their assets into visually cohesive presentations with minimal effort. In essence, these integrated sprites streamline image management in Rails applications.
00:17:11.520
When combining sprites, you can easily manage your image directories without having to handle CSS merges yourself. By declaring image directories and implementing necessary imports, the Rails app will automatically handle sprite generation while adjusting CSS class declarations to reflect the appropriate sprites. This level of control simplifies design processes within Rails.
00:19:06.780
With respect to performance optimizations, the Rails team is committed to continual improvements. They are actively identifying performance bottlenecks across the framework with plans to enhance action pack and active record. This commitment aims at streamlining how Rails processes requests and manages resources internally to cultivate faster response times for users. Every effort is directed at ensuring that Rails remains performant and competitive in a diverse ecosystem.
00:20:51.840
Through elaborating on these various improvements, Rails 3 is set to expand beyond just core functionalities, as it continues to optimize for community needs. Thus, the framework embraces contributions from the user base that collectively make it robust, innovative, and suitable for modern development demands. As we gear towards future versions, the fidelity of functionality will further reflect user preferences and usage patterns.
00:21:20.400
Moving towards flushing, Rails will introduce a mechanism that allows for more immediate output to browser as page rendering progresses. This flow aims to mimic user experience intuitively, where sections of a response can be sent as they are constructed rather than waiting for all content to be ready before dispatch. Aspects of this approach will ensure that content can be delivered promptly and efficiently to enhance user satisfaction.
00:23:35.520
Finally, with exception handling encapsulated within Rails controller contexts, we can enhance the way exceptions are managed across apps. This will facilitate more controlled error responses subsequent to exceptions that arise, allowing for tailored user experiences even in failure cases. Care will be taken to ensure that errors are reported correctly and that developers have access to all necessary controls without compromising application stability.
