Ruby on Rails agreement. Part 2

Configuration agreement

One of the early Rails slogans was: “You're not a beautiful and unique snowflake.” The motto said that by abandoning individuality, it is possible to bypass the solution of trivial problems and make more rapid progress in areas that are really significant.

Who cares in which format your primary keys are described in the database? Is this really important when it comes to id, postId, posts_id or pid? Is this solution worthy of constant discussion? Not.

Part of the Rails mission is to swing a machete in the thick and constantly growing jungle of repetitive solutions faced by developers creating information systems for the web. There are thousands of such decisions that just need to be made once, and if someone else can do it for you, all the better.
')
Not only is the transfer of the configuration to the agreement free us from discussion, it also provides a lush field for the growth of deeper abstractions. If we have the ability to use the dependency of the Person class on the people table, then we can use the same conversion to display the association, declared as has_many: people, to search for the Person class. The strength of good deals is that they bring dividends in a wide range of uses.

But in addition to increasing development speed for experts, the agreement also reduces the entry threshold for beginners. In Rails, there are a lot of agreements that a newbie doesn't even need to be aware of, but he can simply benefit from his ignorance. You can create great applications without knowing why it works that way.

It is extremely difficult when your framework is just a thick tutorial, and your new application is a blank sheet of paper. It takes tremendous effort to trite to figure out where to start. Half the effort is a quest to find the right thread to pull.

The same thing happens when you understand how everything works together. When there is an obvious next step for each change, we can reuse many parts of the application that are the same or very similar to them. A place for everything and everything in its place. Restrictions liberate even the most capable minds.

As in everything, the strength of the agreement is not devoid of pitfalls. When using Rails you do everything so simply to do so much, it is easy to be mislead that every aspect of an application can be formed using only templates. But in most applications, there are special elements that are unique. This may be 5% or 1% of the entire application, but such things are found.

The hardest part is understanding when to deviate from the agreement course. When are the reasons serious enough to justify this decision? I argue that most of the prerequisites for being beautiful and a unique snowflake are not well considered and the cost of avoiding using Rails is underestimated. This is enough for you to thoroughly study them all.

The menu is Omakase

What decision do you make when you do not know what to choose from the menu in the restaurant? Well, it is likely that if you allow the chef to make a choice for you, he may pleasantly surprise you before you understand what “good” is. This is Omakase. A way to eat well, which does not require expert knowledge from you and besides allowing you not to rely on blind luck when choosing.

For programming, the benefits of this practice are the ability to allow someone else to collect your stack. This is similar to the benefits we get from the Configuration Agreement, but at a higher level. While the Configuration Agreement is concerned with optimizing the use of individual structures, Omakase is concerned with the question of which structures exist and how they interrelate with each other.

This is at odds with the tradition, which pushes the programmer to make individual decisions when choosing available tools.

You probably heard and, most likely, nodded at the moment when someone told you "use the best tool in the work." It sounds so elementary that it cannot even be discussed, but the ability to choose the “best tool” depends on the foundation, which allows you to determine “better” with full confidence. It is much more difficult than it seems.

This is a problem like dinner in a restaurant. How to choose from eight dishes, then the choice of a library or framework should not be a work alone. The goal in both cases is to consider the whole evening or the system.

Thus, in RoR we decided to reduce the choice, replace the individual choice of a programmer of individual tools with something more: The best set of tools for everyone. Dividends are legion:

1. Security is in numbers: when most people use Rails in the same way by default, we have a general experience. This is something that facilitates learning and help for beginners. This lays the foundation for communication. We all watched the same show last night at 7, so we can talk about it the next day. This contributes to a stronger sense of community.
   
   
2. People improve the same basic toolkit. In Rails, as a full-stack framework, there are many moving parts, and how they work together is just as important as what they do in isolation. Most software problems come not from individual components, but from their interaction. When we all work to alleviate common problems from components that are tuned and fail with errors for various reasons, we have fewer problems.
   
   
3. Substitutions are still possible, but not required: although Rails is an omakase stack, it still allows you to replace certain frameworks or libraries with alternatives. You just don't need it. This means that you can put off these solutions until you have developed a clear personal palette of “best solutions”, instead of a random set of tools.

Because even the most educated and experienced programmers who come and stay in Rails are unlikely to object to all menu issues (If they were, they probably wouldn't be tied to Rails). So, they carefully select alternatives and then enjoy the rest of the mentorship by sharing the stack with the community.

• Part 1
• Part 2
• Part 3
• Part 4