Today I Learned

TIL, 2017-04-18, Enterprise Rails--Plugins

Chapter 2: Organizing with Plug-ins


  • I need to read this because GC might support multiple match types.
  • At some point you will get to 100 classes.
  • Refactoring is harder late in the game.


  • Plug-ins provide a convenient mechanism to separate architectural enhancements from business logic. Intertwining these two can be a quick route to bugs.
  • Plug-ins can be tested independently from the rest of your application, giving you greater confidence in the overall robustness of your code.
  • Limiting application code to business logic makes application easier to upgrade when new Rails versions are released.
  • They can be shared between multiple applications. This is good for SOA.
  • Think of your application as layers. There’s the Ruby language itself. On top of that is the Rails framework. Instead of dumping a behemoth, unorganized “code layer” on top of the framework, you can gain a lot by splitting that layer in two: architecture enhancements (plug-ins) and business logic.

Why Extend Hash?

  • Ex: of when Ruby is slow: Converting the results of an SQL query into AR objects.
  • Along with the sugar that AR provides comes a heavy overhead of creating the object itself.
  • Getting your results out of the database as hashes is much faster–more than 50% faster than requesting AR objects.
MyObject.find(:all) => 7 seconds
MyObject.connection.select_all(select * from my_objects) => 3 seconds

Custom Extensions

  • Make a plug-in out of a mixin (acts_as...).
module Animal

  def self.included(base)
    base.extend ClassMethods
    base.class_eval do
      include InstanceMethods

  module ClassMethods
    def acts_as_animal(params)
      class_eval <<-STUFF
        def noise

  module InstanceMethods
    def generic_animal_thing
  • Testing: Include the module again, then create a small class that implements that module. Then test that the small class can do the plugin thing.

This project is maintained by daryllxd