At the early days, Rails community accepted few principles unconditionally because they sound like axioms. People use principles and acronyms to compress meanings. By doing so, there's a risk for them to be misunderstood. And I think this is exactly what's happened to with some people in Rails community. So let's try to decompress them, and see what might be wrong with our understanding.

1. PRINCIPLES.
MISUNDERSTOOD.
APPLIED.IVAN NEMYTCHENKO, 2015 //OMSK

2. ▸ phyzfack
▸ 3 years in webdev companies
▸ freelance on rails
▸ company of 4
▸ company of 15
▸ back to development

3. PRINCIPLES

4. ▸ 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

5. DRY
"DO NOT REPEAT YOURSELF"

6. JUST AVOID
DUPLICATION, RIGHT?

8. PRICE

9. PRICE:
MORE RELATIONS

10. DRY PRINCIPLE AT THE
EARLY STAGES

12. Duplication is much cheaper
than wrong abstraction
— Sandi Metz

13. KISS
"KEEP IT SIMPLE, STUPID"

14. RAILS IS SIMPLE,
RIGHT?

15. RAILS WORLD IS SO COOL,
THAT WE DON'T EVEN HAVE WHOLE CLASS OF PROBLEMS,
WHICH MILLIONS OF JAVA PROGRAMMERS
STRUGGLING EVERY DAY!

16. ACTIVERECORD, ANYBODY?

17. ▸ input data coercion
▸ setting default values
▸ input data validations
▸ interaction with the database
▸ handling nested structures
▸ callbacks(before_save, etc...)

18. BUT WHY SHOULD I
CARE?

19. Polymorphic STI model which belongs to another
polymorphic model through another model, which also
has some valuable JSON data stored in Postgres using
hstore

20. WHAT ARE YOU GONNA DO?
▸ reorganize your associations & app
▸ become Rails contributor

21. IT IS GOING TO BE PAINFUL

22. PAINFUL BECAUSE OF THE
COMPLEXITY

23. RAILS IS NOT SIMPLE, IT IS
CONVENIENT.

24. CONVENTION OVER
CONFIGURATION

25. IMPLICIT VS EXPLICIT

26. METAPROGRAMMING

27. PRICE

28. PRICE:
FLEXIBILITY

29. FAT MODEL,
SKINNY CONTROLLER

30. RIGHT PROBLEM
IDENTIFIED

31. BUT IT IS PART OF THE
PROBLEM

32. YOU SHOULD HAVE NO FAT CLASSES AT ALL

33. PROPER SOLUTION
REQUIRES THINKING
OUT OF MVC BOX

34. RAILS IS NOT YOUR
APPLICATION

35. IT JUST DOESN'T MAKE SENSE.
HERE'S MY RAILS APPLICATION.
HERE'S app FOLDER. WHAT'S
WRONG?

38. Many developers are trying to fit
business logic into MVC design pattern

39. But MVC is only for how we're going to serve stuff to the
web

40. P.S. GOOGLE FOR:
▸ Clean architecture
▸ Hexagonal architecture

43. YAGNI
"YOU AREN'T GONNA NEED IT"

44. WHAT IF IN YOUR APPLICATION
DON'T NEED PERSISTANCE YET?

45. WHAT IF IN YOUR APPLICATION
DON'T NEED WEB FRAMEWORK YET?

46. PREFER COMPOSITION
OVER INHERITANCE

49. Question everything generally
thought to be obvious.
— Dieter Rams

50. STOP BEING RAILS
DEVELOPER