I summarized the basic idea written by DHH, the creator of Rails
https://rubyonrails.org/doctrine/#optimize-for-programmer-happiness https://postd.cc/rails-doctrine/
The reason DHH created Rails is "to make me smile"
It's not logical but rather morbid, but I made it to make myself happy
The Rails community has come together for happiness, and Rails has been shaped by happiness optimization.
Rails' early productivity motto was "Stop wasting personality and speed up your work in critical situations without having to struggle with mediocre decisions." Whether the database primary key is id, postId, posts_id, Discussing pid is to avoid unnecessary contemplation and increase productivity by shifting from waste setting to convention.
In addition, the conventions lower the hurdles for beginners. There are many Rails conventions that beginners don't need to know, and they have the benefits of ignorance. You can create great applications without knowing all of them. It's impossible if the framework you can do is just a thick textbook
It's easy to think that you can make everything with existing templates, but usually 5% or 1% is worth having your own elements.
It's hard to know when to deviate from the rules Most of the urges to deviate are unthinking and the cost of getting off the rails is underestimated.
--Comment
I didn't really care about it, but the name Ruby on Rails probably means "Ruby in line with the rules (Rail)" https://jp.quora.com/Ruby-Rails-no-namae- no-yurai-wo-oshie-te-kuda-sai
For programming, the benefits of leaving it to others are similar to what you get from convention over configuration, but at a higher level. Whereas CoC thinks about how best to use individual frameworks, Random thinks about which frameworks to use and how to combine them. This goes against the sublime programming tradition of presenting available tools as individual choices, but that tradition has given individual programmers the privilege (and burden) of deciding "use the best tools for the job". The word "is indisputably rudimentary," but choosing the "best tool" requires a foundation on which you can confidently judge the "best," which is more difficult than you might think.
So at Rails, we decided to reduce the programmer's personal privilege of choosing each tool in the box by one for a toolbox that is good for everyone. As a result, we were able to obtain many profits.
Experience can be shared when most people are using Rails with the same defaults. Having a common base makes it much easier to teach and help others. It fosters a stronger sense of community.
As a full-stack framework, Rails has a lot of dynamic parts, and it's just as important how they work together, as much as how they work alone. Software glitches are not caused by each component, but by their interaction. From multiple configured components, everyone can work together to mitigate common defects, and if they fail in the same state, the number of defects can be reduced.
While Rails is an "automatic" stack, it can also be replaced by other frameworks and libraries. However, it is not essential. This means that you can later develop a clear and personal palette that suits the occasional differences. It's quite possible that even an experienced and skilled programmer doesn't like everything in the menu (if anyone is happy with it, it's not yet stuck in Rails). They diligently exchange for something else, and then go to another stack that everyone supervises and shares and enjoys.
I didn't know anything other than "Rails is made up of many different ideas" ...
We don't write code just to be understood by computers and other programmers, we write code to get the warm light of beauty. Beautiful code is a value in itself and should be energetically pursued. That doesn't mean that beautiful code always outperforms others, but it should always be a priority.
class Project < ApplicationRecord
belongs_to :account
has_many :participants, class_name: 'Person'
validates :name, presence: true
end
It looks like a DSL, but it's really just a class definition that calls three class methods that take symbols and options. There is nothing flashy. But it's certainly pretty and simple. You can gain enormous amounts of power and flexibility from these few declarations.
Part of the beauty comes from the fact that these calls respect "convention over configuration". When calling belongs_to: account, the foreign key is called account_id and assumes it is in the Projects table. If you need to specify a Person class name for a participants association role, you only need to define that class name. From there you can get foreign keys and other settings.
class CreateAccounts < ActiveRecord::Migration
def change
create_table :accounts do |t|
t.integer :queenbee_id
t.timestamps
end
end
end
This is the essence of the power of the framework. Programmers declare classes according to certain conventions (for example, a subclass of ActiveRecord :: Migration that implements #change). The framework then goes through it all and recognizes that this is the method to call.
This allows programmers to write very little code. For migrations, you can not only call rails db: migrate to upgrade your DB to add a new table, but you can also drop this table with rails db: rollback. This is very different from a programmer using a library to stitch workflows together to achieve these things.
Ruby has a lot of sharp knives in its features. It's not a coincidence, it's a design. The most famous is the monkey patch. The knives offered by Rails aren't as sharp as those offered by Ruby, but they're still sharp enough. I believe that every programmer has a way to become a fully capable Ruby and Rails programmer, if not a right. And competent means having the knowledge to know when, how, and when to use different and sometimes dangerous tools in a drawer, depending on the situation.
Rails can be used in many contexts, but the first is to create an integrated system. A magnificent monolith! The entire system that addresses the entire problem. In other words, Rails is involved in everything from front-end JavaScript to DB. This is a very wide range, but not unrealistically wide for a single person to understand. Rails specifically aims to allow generalist individuals to create these complete systems. It is an integrated system that focuses on empowering individuals. Ease of use and comprehension as a single integrated system, giving you the power of individually tuned and distributed applications
--Comment
I don't think I agree with microservices so much
When a system has existed for more than 10 years like Rails, it tends to become fixed naturally. Of course, for those who have relied on past behavior, any change can be a problem. But if it's too conservative, you can't see what's on the other side. For evolution and growth, we need to break and change the status quo. Evolution will allow Rails to survive and prosper for decades to come.
Rails versions are up, but we should take the lead in contributing to the evolution of Ruby by quickly adopting new versions of Ruby.
Progress often depends, after all, on the people and their willingness to drive change. That's why groups like Rails Core and Rails Committers don't have indefinite seats. Both groups are for those who are actively working on the advancement of the framework. Similarly, it is very important to continue to welcome and encourage new members of the community. We need fresh blood and fresh ideas to make better progress.
Rails has a lot of controversial ideas, so if you always ask you to follow every idea completely, Rails will quickly become isolated as a group of ideological hermits. So it doesn't! We need to disagree. I need a dialect. We need ideology and diversity of people. There is the best commonality in the crucible of this idea. The continued success of RSpec, a test DSL that I have often expressed serious dissatisfaction with, is perfect proof. I wonder why this shouldn't be the case, I can scream until my face turns blue, but RSpec can still bloom and thrive. That ’s much more important.
The same is true for the advent of Rails as an API. My personal focus and commitment is on the integrated system, including views, but for anyone who wants to pre-distribute clients and servers, Rails definitely has room to work.
Having a big tent doesn't mean trying to be universal for everyone. It means welcoming everyone and allowing them to bring their own drinks. With the participation of others, we don't have to lose our soul and values, and we may learn how to mix new delicious drinks. This cannot be done for free. It takes effort to welcome you. Especially if your goal is not just to attract more people who are similar to existing members of the community. Lowering the barriers to entry is always a serious task. I don't know when the next person, who just started by fixing a misspelled document, will implement the next great feature. But you may be motivated by smiling and thanking for any small contributions.
Recommended Posts