Jengas & Legos: Rails as a stack of components

Talk about Rails apps' architecture seeing it as a stack of different components, using Jenga and Legos as a metaphor for coupling and cohesion. Talk given at MagmaRails 2012

Transcript

1. Jengas y Legos: Rails como un Stack de componentes Rubén Medellín @chubas chubas7@gmail.com
2. Jengas y Legos: Rails como un Stack de componentes Rubén Medellín @chubas chubas7@gmail.com LEGO® is trademark of The Lego Group Jenga® is trademark of Hasbro
3. Rails MVC MVC was THE killer feature of Rails
4. Widespread adoption Everybody was talking about it. Some of them were even using it.
5. “Rails doesn’t scale” Oh you meant, “my app doesn’t scale”!
6. Rails is not your application The right tools for the right job.
7. Choose your weapon Strong tool ecosystem
8. Rails is MODULAR Choose with the less friction
9. Bad analogies are like cowboy monkeys
10. Legos Jengas   &  
11. Coupling Dependency of a module in other modules
12. Cohesion Dependency between the inner parts of a module
13. Friction The most changing parts are the ones related to your application’s logic The other ones change too little that other people already did that for you
14. Own code is Jenga Vendor code is Lego
15. Where does my application live? /app /models /controllers /views /lib /config /lib /tasks /test /vendor /…  
16. Where does the vendor code live? config.ac)on_mailer.default_url_op)ons  =  {…}   config.assets.ini)alize_on_precompile  =  false   rails  g  devise  User   devise  :database_authen)catable,  :)meoutable   devise_for  :admins   before_filter  :authen)cate_admin!   user_signed_in?   current_user  
17. The Great Triad ActiveRecord ActionController ActionView
18. Rails conventions Conventions are interfaces Interfaces create coupling
19. Coupling is not bad Different types of coupling
20. How should I program, then? “Knowing the difference between what the Rails documentation says Rails developers do, and what Rails developers actually do” Giles Bowkett
21. Who has… •  Monkey-patched a library? •  Forked and edited a library? •  Rewritten a library?
22. Library smells •  The library does too much or too little •  You need to patch the library to fit your application •  A lot of gem dependencies •  The gem dependencies duplicate or conflict with your gems •  Coupling through global variables, Rails or Ruby patches •  Lack of test coverage •  Not mature/stable. Unclear interface. •  No active maintenance or community •  Hard to read and understand. A lot of code. Peter  Marklund   hFp://marklunds.com/  
23. What to do Minimize dependencies “look at all the libraries I’m not depending on!” There’s the inevitable code you cannot get rid of
24. What to do Use alternatives to monkey patching Extending modules, aliasing method chains, create façades and adapters
25. What to do Create your classes with functional cohesion
26. Rails engines Rails Engines (and Railties) gave Rails’ internal components more cohesion, and less coupling
27. As a plugin / gem developer •  Do only one thing. If you can, do less than that •  Clearly expose your interfaces, but provide hooks •  If you provide multiple functionalities, make sure those are decoupled
28. Not only Ruby Applies to any other language / platform JS OC P
29. Thanks! Questions?