The Rails Doctrine
Optimize for Programmer Happiness (1)
Rails is built on top of Ruby. Therefore, as Ruby was built with programmer happiness as priority, Rails inherits this principle too.
Ruby went to a great length to present a programming language that seems simple, clear, and beautiful to our mind's eye.
Optimize for Programmer Happiness (2)
Likewise, Rails also went to a great length to do the same. For instance, The Principle of The Bigger Smile: this means that Rails APIs are designed to make programmer (specifically the one that creates it) smile more and broader.
In action, you can see it in the way Rails creates an Inflector class. It is a class that understands enough English language to know that when you create a model class named "Person", Rails will know that the plural form of it is "people" and therefore can map your "Person" class to "PeopleController" class.
Convention over Configuration
Rails flourishes by making you give up vain individuality like "what should I name the primary key column for my Person class? Should it be 'id', 'person_id', or 'pid'?" and follow its convention instead.
Rails is full of such a convention: all models should be named in singular form (Person), all controllers should be named in plural form (PeopleController), primary key should be named as just "id" while foreign key should be named like "person_id", etc.
The Menu is Omakase (1)
How do you know what to order in a restaurant when you don’t know what’s good? Well, if you let the chef choose, you can probably assume a good meal, even before you know what “good” is.
That is omakase. A way to eat well that requires you neither be an expert in the cuisine nor blessed with blind luck at picking in the dark.
The Menu is Omakase (2)
For programming, the benefits of this practice, letting others assemble your stack, is similar to those we derive from Convention over Configuration, but at a higher level.
Where Convention over Configuration is occupied with how we best use individual frameworks, omakase is concerned with which frameworks, and how they fit together.
No One Paradigm
Rails isn’t ideologically a single, perfect cut of cloth. It’s a composite of many different ideas and even paradigms. Many that would usually be seen in conflict, if contrasted alone and one by one.
Exalt Beautiful Code
Take a look at this piece of code:
class Project < ApplicationRecord
belongs_to :account
has_many :participants, class_name: 'Person'
validates_presence_of :name
endBeautiful code is not just about aesthetically pleasing block of codes, it is also about simplicity and being easy to understand.
Even if you don't understand Ruby language, you can almost read that code like it is written in plain English.
Provide Sharp Knives (1)
Do you know we can do this in Ruby?
class Fixnum
def +(other)
42
end
endWhat we did, replacing existing methods of core Ruby class, is considered a dangerous practice. A sharp knife. Ruby gives a lot of these sharp knives.
Provide Sharp Knives (2)
Rails also provides you with these knives. In some programming languages and framework, this practice may be condemned as one can use a sharp knife to hurt oneself.
Ruby and Rails, on the other hand, is an environment for chefs and those who wish to become chefs. You might start out doing the dishes, but you can work your way up to running the kitchen. Don’t let anyone tell you that you can’t be trusted with the best tool in the trade as part of that journey.
Value Integrated System
Rails was developed to build a full stack app: it does everything from how the front-end is served with CSS and Javascript, how the logic of app is implemented with ActiveRecord, to how the database is migrated from one version to another.
However of course, as we will later learn, Rails can be used as a back-end only app that provides APIs for different front-end apps.
Progress over Stability
Rails has been around for more than a decade. For a framework to survive that long, it is inevitable that changes are made to progress. Occasionally this involves developing changes that break how things used to work.
This is all easy to understand in theory, but much harder to swallow in practice. Especially when it’s your application that breaks from a backwards-incompatible change in a major version of Rails.
It’s at those times we need to remember this value, that we cherish progress over stability, to give us the strength to debug the busted, figure it out, and move with the times.
Push Up a Big Tent
As the principle "No Single Paradigm" stated, Rails accepts people from different paradigm and ideology. Rather than trying to make everyone agree on everything, Rails welcome disagreement, dialects, and diversity of thought.
The creator of Rails (DHH) hates RSpec. Yet it continues to flourish and widely used by communities of Rails developers worldwide.
Rails was meant to be an integrated system. Yet it is not rare to see Rails developed as a back-end only app serving APIs to other front-end apps.
[Go-Jek x BNCC] - The Rails Doctrine
By qblfrb
