Long story short, Rails now has a nicely written Doctrine that delineates the principles that motivate tradeoffs the framework makes. Any Rails developer can benefit from understanding this and coding with the framework as much as possible.
Short story long: I’ve been trying to mentally track this for a while via something I call DHHology. It’s where I follow @dhh and try to piece togther blog posts, tweets, code snippets haphazardly shared, and keynotes to build a mental model for what working with the grain of Rails looks like when you get past a small app.
It’s a lot like Kremlinology, “the study and analysis of the politics and policies of Russia”.
During the Cold War, lack of reliable information about the country forced Western analysts to "read between the lines" and to use the tiniest tidbits, such as the removal of portraits, the rearranging of chairs, positions at the reviewing stand for parades in Red Square, the choice of capital or small initial letters in phrases such as "First Secretary", the arrangement of articles on the pages of the party newspaper Pravda and other indirect signs to try to understand what was happening in internal Soviet politics.
It’s a bit of a stretch, but I think the same kind of “between the lines” thinking helps to understand Rails. Of course, sometimes I’m wrong, but so were the Kremlinologists. On the other hand, there was that one time I got DHH and Gary Bernhardt to kind of agree on Twitter, so that’s nice!
