▸ DRY - "Do not repeat yourself"▸ KISS - "Keep it simple, stupid"▸ Convention over configuration▸ Fat model, skinny controller▸ Rails is not your application
▸ YAGNI - "You aren't gonna need it"▸ Prefer composition over inheritance
DRY"DO NOT REPEAT YOURSELF"
JUST AVOID DUPLICATION, RIGHT?
PRICE
PRICE:MORE RELATIONS
DRY PRINCIPLE AT THE EARLY STAGES
Duplication is much cheaper than wrong abstraction
— Sandi Metz
KISS"KEEP IT SIMPLE, STUPID"
RAILS IS SIMPLE, RIGHT?
RAILS WORLD IS SO COOL,THAT WE DON'T EVEN HAVE WHOLE CLASS OF PROBLEMS,
WHICH MILLIONS OF JAVA PROGRAMMERS
STRUGGLING EVERY DAY!
ACTIVERECORD, ANYBODY?
▸ input data coercion▸ setting default values▸ input data validations
▸ interaction with the database▸ handling nested structures▸ callbacks(before_save, etc...)
BUT WHY SHOULD I CARE?
Polymorphic STI model which belongs to another polymorphic model through another model, which also has some valuable JSON data stored in Postgres using
hstore
WHAT ARE YOU GONNA DO?
▸ reorganize your associations & app▸ become Rails contributor
IT IS GOING TO BE PAINFUL
PAINFUL BECAUSE OF THE COMPLEXITY
RAILS IS NOT SIMPLE, IT IS CONVENIENT.
CONVENTION OVER CONFIGURATION
IMPLICIT VS EXPLICIT
METAPROGRAMMING
PRICE
PRICE:FLEXIBILITY
FAT MODEL, SKINNY CONTROLLER
RIGHT PROBLEM IDENTIFIED
BUT IT IS PART OF THE PROBLEM
YOU SHOULD HAVE NO FAT CLASSES AT ALL
PROPER SOLUTION REQUIRES THINKING
OUT OF MVC BOX
RAILS IS NOT YOUR APPLICATION
IT JUST DOESN'T MAKE SENSE. HERE'S MY RAILS APPLICATION. HERE'S app FOLDER. WHAT'S
WRONG?
Many developers are trying to fit business logic into MVC design pattern
But MVC is only for how we're going to serve stuff to the web
P.S. GOOGLE FOR:
▸ Clean architecture▸ Hexagonal architecture
YAGNI"YOU AREN'T GONNA NEED IT"
WHAT IF IN YOUR APPLICATION DON'T NEED PERSISTANCE YET?
WHAT IF IN YOUR APPLICATION DON'T NEED WEB FRAMEWORK YET?
PREFER COMPOSITION OVER INHERITANCE
Question everything generally thought to be obvious.