Search
Ruby on Rails
Start Your Engines
Edit
#rails-engines
#ruby-on-rails
#rails-plugins
#microservices
#authentication
#authorization
Summarized using AI

Start Your Engines

Ryan Bigg • March 01, 2012 • Earth

Introduction

In the talk titled "Start Your Engines," Ryan Bigg presents an in-depth exploration of Rails engines, a feature in Ruby on Rails, tracing its evolution and sharing insights gained from his own experiences with the technology. While engines are a relatively novel feature in Rails, Bigg emphasizes that the concept has historical roots and has faced skepticism from key figures in the Rails community.

Key Points

  • Historical Context of Engines:

    • James Adams conceptualized engines in 2005, leading to the creation of the Manable Engines plugin.
    • Initial resistance included criticism from prominent figures like Kevin Smith and DHH, who were apprehensive about high-level components in Rails.

  • Development and Integration into Rails:

    • Engines were not formally integrated into Rails until version 2.3, which implemented basic engine support but required constant updates due to version changes.
    • Significant improvements came with Rails 3.1, which incorporated features making engines more user-friendly, like migration copying and the asset pipeline.

  • Practical Application and Challenges:

    • Bigg shares his experiences developing a site for ABC using engines, facing early challenges with the Product model and documentation shortcomings.
    • His process of writing the engines chapter for "Rails 3 in Action" illuminated the lack of thorough documentation and the need for comprehensive guidance.

  • Technical Insights:

    • Building engines begins with the rails plugin new command, which streamlines setup by generating necessary files automatically.
    • Effective engine development includes understanding the inheritance from Rails Engine, enabling applications to function as engines themselves.
    • Important components include generator writing, handling migrations, and establishing clear namespacing structures for ease of use.

Conclusion

Ryan Bigg concludes by encouraging developers interested in writing engines to thoroughly read existing guides and to reach out for help if challenges arise. He reflects on the progress made in Rails engine documentation, which has significantly expanded, thus underscoring the importance of continuous learning in the development community. The talk stresses the need for good testing practices, which are essential to avoid future issues and ensure stable user experiences. Overall, this presentation exemplifies the growth of Rails engine support and its practical implications for developers.

Start Your Engines
Ryan Bigg • March 01, 2012 • Earth

Engines are a new-to-Rails feature that really isn't all that new-to-Rails. The concept has been around for a very long time, it's just only now that they, the Rails Core Team, has Done It Right(tm). In this talk, I go through the lessons learned while developing not just one but two engines.

I also provide more documentation than Rails has at the moment on engines *in one talk*.

Help us caption & translate this video!

http://amara.org/v/FGgb/

Ruby on Ales 2012

00:00:22 Good morning, everyone. I apologize for my accent in advance; I'm from Australia. I've been in this country, America, for two weeks now, but before that, I spent some time in New Zealand.
00:00:35 We had an event called Rails Camp, which took place at the base of a mountain. We climbed to the top, and there was a glider in the distance circling and doing its thing. It then turned and started heading toward us, which was kind of cool until we realized it was heading toward the ridge line, directly above us.
00:01:02 The glider passed no more than 20 feet above our heads. The Rails Camp in New Zealand was amazing; if you ever get the chance to attend a Rails Camp event in Australia or New Zealand, they are pretty spectacular.
00:01:20 My name is Ryan Bigg, and you can follow me on Twitter at Ryan Big. I'm also known as Radar, which you can find on GitHub as radar_on_c. Some people view me as a hero, but it’s just a costume I put on. I help out a lot on Stack Overflow and enjoy memes.
00:01:39 If you see me posting an image link to something, it's probably from a book called 'Rails 3 in Action.' If you haven't read it yet, you should feel guilty! As for my reputation on Stack Overflow, I have 27,126 points, which places me in the top 65%. I work for a little company called Spree, where I serve as the community manager. My days are spent staring longingly at the Rails contributors list, hoping that all the issues will just go away.
00:02:15 I'm surrounded by people like Michael Koski, who commits to Rails every time he goes for a run. Then there's Peter Szakaly, who did a lot of the work on engines, and I'll talk more about him later. Nicholas Se, an interesting character who disappeared in 2007, commits to GitHub occasionally but hasn't worked on Rails since then. There's a story behind that, but I digress. Now, let's talk about engines.
00:03:01 The concept of engines in Rails came from a guy named James Adams, who envisioned making notable applications within a Rails application. On October 31, 2005, when Rails was in its infancy, he created the Manable Engines plugin.
00:03:36 However, some people didn't like it. For instance, Kevin Smith described engines as a nasty hack that breaks with every new version of Rails, which was true because the plugin needed constant updates with each Rails change. His blog post also advised against writing Neo Ajax thingies, advocating against using frameworks like Backbone or Ember.
00:04:02 Even DHH expressed skepticism about the idea of engines. He famously stated that he didn't want Rails to succumb to high-level components like login systems or content management systems. Though he didn't explicitly mention some plugins, his stance suggested that he was against them. He indicated that the goal of Rails was to create an environment where engines were not only unnecessary but also unappealing.
00:04:38 Fast forward to early 2012, and engines are now part of Rails. James Adams, who created the engines plugin, even expressed that the engines have not yet received the blessing of the Ruby on Rails core team.
00:05:06 Despite early skepticism, Rails did implement engine support through the engines plugin. When Rails 2.3 came along, it mockingly implemented engines. While it enabled controllers, models, and views, copying over migrations and assets was still a pain.
00:05:30 The Railscasts link at the bottom is a demonstration of how engines worked in Rails 2.3. Yuda Kats later introduced some much-needed changes. He integrated all the good ideas from engines, resulting in engines becoming more prominent.
00:06:06 Peter Szaky from Poland also came along and committed 322 times to Rails focusing on engine work. Engine support in Rails 3 was much improved thanks to the contributions from James Adams, Peter, and others.
00:06:38 With the release of Rails 3.1, features such as easier migration copying and the asset pipeline made engines more efficient and user-friendly.
00:07:05 At Spree, we utilized engines to build a site for ABC in Australia, a large government-funded broadcasting corporation. Before Rails 1.0, I had no idea how engines worked; the Product model caused conflicts when trying to have the same model within the application.
00:07:45 While writing the engines chapter for 'Rails 3 in Action', I faced many challenges with engines. The Rails documentation proved unhelpful, as it was brief and somewhat confusing. Currently, the Rails engine class has only 300 lines of documentation.
00:08:29 To get started with building an engine, you run the 'rails plugin new' command with the full option. This generates a new plugin, adding the necessary routes file, application folder, engine class, and assets. The mountable option allows the engine to be mounted inside a test dummy application.
00:09:22 The plugins for Rails are G by default, enabling easy integration with GitHub. You avoid the hassle of using separate tools like Jeweler or bundler for setup. Dependencies should be included inside the gem spec rather than the gem file.
00:10:04 Inside an engine, you have the 'EngineName' file that requires the engine and defines a module. This module allows for setting up initializer within the engine before it boots up and provides the capacity for web scale performance.
00:10:44 A Rails application inherently inherits from Rails Engine, which is fascinating. Understanding this inheritance means that any Rails application you’re writing is, at its core, an engine.
00:11:29 Inside the blog engine class, you can set an endpoint for the rack application. This enables your engine to serve requests while obtaining the full power of Rails features such as generators and initializers.
00:12:19 You can write generators directly inside an engine, and packaged features like migrations can be included for ease in updating systems. However, it's essential to write good test cases to avoid issues or conflicts later.
00:13:05 While developing the best Rails 3.1 forum system, we also faced challenges regarding authentication and authorization within our engines. We provided a common API to handle various authentication mechanisms.
00:13:54 The theming process within Rails 3.1 proved to be much easier thanks to the asset pipeline, allowing us to define styling resources within the engines.
00:14:59 For installation and setup of forums, a streamlined process was introduced to simplify user onboarding which included a guided setup for defining user classes and methods.
00:15:58 I learned valuable lessons while writing the engines chapter and developing forum components, which I later introduced into Spree 1.0. As a result of my involvement with the Spree user group, I ended up getting a job for my efforts.
00:16:46 At Spree, we now have a clearer namespacing structure that simplifies mounting process, ensuring users do not need to navigate complex routing or configuration challenges.
00:17:45 After addressing the stability of tests, we overcame several bugs and issues to ensure a smooth user experience. All contributions helped improve the Spree framework.
00:18:56 I apologize for the earlier statements regarding documentation, as it has grown to cover more than 800 lines, including guidelines for testing engines. There is a lot to be learned when creating engines.
Ryan Bigg
@radar
Explore all talks recorded at Ruby on Ales 2012
+5