Nous avons résumé les principes de base écrits par le créateur de Rails, DHH.
https://rubyonrails.org/doctrine/#optimize-for-programmer-happiness https://postd.cc/rails-doctrine/
La raison pour laquelle DHH a créé Rails est "pour me faire sourire"
Ce n'est pas logique mais plutôt morbide, mais je l'ai fait pour me rendre heureux
La communauté Rails s'est réunie pour le bonheur, et Rails a été façonnée en optimisant le bonheur.
La première devise de la productivité de Rails était "Si vous arrêtez de gaspiller votre personnalité, vous pouvez travailler plus rapidement dans des situations importantes sans avoir à vous battre avec des décisions médiocres." Que la clé primaire de la base de données soit id, postId, posts_id, Discuter du pid, c'est éviter toute réflexion inutile et augmenter la productivité en passant de la définition des déchets aux conventions.
De plus, les conventions abaissent la barre pour les débutants. Il existe de nombreuses conventions Rails que les débutants n'ont pas besoin de connaître, et ils ont les avantages de leur ignorance. Vous pouvez créer de superbes applications sans les connaître toutes. C'est impossible si le cadre que vous pouvez faire n'est qu'un manuel épais
Il est facile de penser que vous pouvez tout faire avec des modèles existants, mais généralement 5% ou 1% vaut la peine d'avoir vos propres éléments.
Il est difficile de savoir quand s'écarter des règles La plupart des envies de déroger sont sous-estimées et le coût de déraillement est sous-estimé.
--Commentaire
Je m'en fichais vraiment, mais le nom Ruby on Rails signifie probablement "Ruby conforme aux règles (Rail)" https://jp.quora.com/Ruby-Rails-no-namae- no-yurai-wo-oshie-te-kuda-sai
Pour la programmation, les avantages de le laisser à d'autres sont similaires à ce que vous obtenez des conventions plutôt que des paramètres, mais à un niveau supérieur. Alors que CoC réfléchit à la meilleure façon d'utiliser les cadres individuels, Random réfléchit aux cadres à utiliser et à la manière de les combiner. Cela va à l'encontre de la sublime tradition de programmation consistant à présenter les outils disponibles comme des choix individuels, mais cette tradition a donné aux programmeurs individuels le privilège (et le fardeau) de décider "d'utiliser les meilleurs outils pour le travail". Le mot «est indiscutablement rudimentaire», mais choisir le «meilleur outil» nécessite une base sur laquelle vous pouvez juger en toute confiance le «meilleur», ce qui est plus difficile que vous ne le pensez.
Nous avons donc décidé chez Rails de réduire le privilège personnel du programmeur de choisir chaque outil de la boîte par un pour une boîte à outils qui convient à tous. En conséquence, nous avons pu obtenir de nombreux avantages.
L'expérience peut être partagée lorsque la plupart des gens utilisent Rails avec les mêmes valeurs par défaut. Avoir une base commune facilite beaucoup l'enseignement et l'aide aux autres. Cela favorise un plus fort sentiment de communauté.
En tant que framework full-stack, Rails comporte de nombreuses parties dynamiques, et la manière dont elles fonctionnent ensemble est tout aussi importante que la manière dont elles fonctionnent seules. Les problèmes logiciels surviennent non pas par chaque composant, mais par leur interaction. Vous pouvez réduire le nombre de défauts si vous travaillez ensemble pour atténuer les défauts courants de plusieurs composants configurés et échouez dans la même situation.
Bien que Rails soit une pile «aléatoire», il peut également être remplacé par d'autres frameworks et bibliothèques. Cependant, ce n'est pas indispensable. Cela signifie que vous pouvez par la suite développer une palette claire et personnelle qui convient aux différences occasionnelles. Il suffit que même les programmeurs expérimentés et expérimentés n'aiment pas tout dans le menu (si quelqu'un est satisfait, ce n'est pas encore coincé dans Rails). Ils échangent diligemment contre autre chose, puis passent à une autre pile que tout le monde supervise, partage et apprécie.
Je ne savais rien d'autre que "Rails est fait de beaucoup d'idées différentes" ...
Nous n'écrivons pas de code uniquement pour être compris par les ordinateurs et autres programmeurs, nous écrivons du code pour obtenir la lumière chaude de la beauté. Un beau code est une valeur en soi et doit être poursuivi énergiquement. Cela ne signifie pas que le beau code surpasse toujours les autres, mais cela devrait toujours être une priorité.
class Project < ApplicationRecord
belongs_to :account
has_many :participants, class_name: 'Person'
validates :name, presence: true
end
Cela ressemble à un DSL, mais ce n'est en réalité qu'une définition de classe qui appelle trois méthodes de classe prenant des symboles et des options. Il n'y a rien de flashy. Mais c'est certainement joli et simple. Ces quelques déclarations peuvent gagner énormément de puissance et de flexibilité.
Une partie de la beauté vient du fait que ces appels respectent «les conventions plutôt que les paramètres». Lors de l'appel de makes_to: account, la clé externe est appelée account_id et suppose qu'elle se trouve dans la table Projects. Si vous devez spécifier un nom de classe Person pour un rôle d'association de participants, il vous suffit de définir ce nom de classe. De là, vous pouvez obtenir des clés externes et d'autres paramètres.
class CreateAccounts < ActiveRecord::Migration
def change
create_table :accounts do |t|
t.integer :queenbee_id
t.timestamps
end
end
end
C'est l'essence même de la puissance du cadre. Le programmeur déclare la classe selon certaines conventions (par exemple, une sous-classe d'ActiveRecord :: Migration qui implémente #change). Le framework passe ensuite en revue tout cela et reconnaît que c'est la méthode à appeler.
Cela laisse au programmeur très peu de code à écrire. Pour les migrations, vous pouvez non seulement appeler rails db: migrate pour mettre à niveau votre base de données et ajouter une nouvelle table, mais vous pouvez également supprimer cette table avec rails db: rollback. C'est très différent d'un programmeur utilisant une bibliothèque pour assembler des flux de travail pour réaliser ces choses.
Ruby a beaucoup de couteaux tranchants dans ses caractéristiques. Ce n'est pas une coïncidence, c'est un design. Le plus célèbre est le patch de singe. Les couteaux proposés par Rails ne sont pas aussi tranchants que ceux proposés par Ruby, mais ils sont toujours assez tranchants. Je crois que chaque programmeur a un moyen de devenir un programmeur Ruby and Rails pleinement compétent, sinon un droit. Et compétent signifie avoir les connaissances nécessaires pour savoir quand, comment et quand utiliser des outils différents et parfois dangereux dans un tiroir, selon la situation.
Les rails peuvent être utilisés dans de nombreux contextes, mais le premier est de créer un système intégré. Un magnifique monolithe! L'ensemble du système qui répond à l'ensemble du problème. En d'autres termes, Rails est impliqué dans tout, du JavaScript frontal à la base de données. C'est une gamme très large, mais pas irréaliste pour une seule personne à comprendre. Rails vise spécifiquement à permettre aux individus généralistes de créer ces systèmes complets. C'est un système intégré qui met l'accent sur l'autonomisation des individus. Facilité d'utilisation et de compréhension en tant que système intégré unique, vous donnant la puissance d'applications réglées et distribuées individuellement
--Commentaire
Je ne pense pas être tellement d'accord avec les micro-services.
Lorsqu'un système comme Rails existe depuis plus de 10 ans, il a tendance à se fixer naturellement. Bien sûr, pour ceux qui se sont appuyés sur des comportements passés, tout changement peut être un problème. Mais si c'est trop conservateur, vous ne pouvez pas voir ce qu'il y a de l'autre côté. Le statu quo doit être brisé et changé pour l'évolution et la croissance. L'évolution permettra à Rails de survivre et de prospérer pendant des décennies à venir.
Les versions de Rails sont en place, mais nous devrions prendre les devants en contribuant à l'évolution de Ruby en adoptant rapidement de nouvelles versions de Ruby.
Le progrès dépend souvent de la personne et de sa volonté de conduire le changement. C'est pourquoi des groupes comme Rails Core et Rails Committers n'ont pas de sièges indéfinis. Les deux groupes s'adressent à ceux qui travaillent activement à l'avancement du cadre. De même, il est si important de continuer à accueillir et à encourager les nouveaux membres de la communauté. Nous avons besoin de sang frais et d’idées nouvelles pour progresser.
Rails a beaucoup d'idées controversées, donc si vous vous demandez toujours de suivre complètement chaque idée, Rails deviendra rapidement isolé en tant que groupe de cachettes idéologiques. Donc ce n'est pas le cas! Nous devons être en désaccord. J'ai besoin d'un dialecte. Nous avons besoin de la diversité des idées et des personnes. Il y a le meilleur point commun dans le pot de cette idée. Le succès continu de RSpec, un test DSL dont j'ai souvent exprimé un mécontentement sérieux, en est la preuve parfaite. Je me demande pourquoi cela ne devrait pas être le cas, je peux crier jusqu'à ce que mon visage devienne bleu, mais RSpec peut toujours fleurir et prospérer. C ’est bien plus important.
La même chose est vraie pour l'avènement de Rails en tant qu'API. Mon objectif et mon engagement personnels portent sur le système intégré, qui comprend des vues, mais il ne fait aucun doute que Rails peut fonctionner pour quiconque souhaite pré-distribuer des clients et des serveurs.
Avoir une grande tente ne veut pas dire essayer d'être universel pour tout le monde. Cela signifie accueillir tout le monde et leur permettre d'apporter leurs propres boissons. Avec la participation des autres, nous n'avons pas à perdre notre âme et nos valeurs, et nous pouvons apprendre à préparer de nouvelles boissons délicieuses. Cela ne peut pas être fait gratuitement. Il faut des efforts pour vous accueillir. Surtout si votre objectif n'est pas seulement d'attirer plus de personnes qui ressemblent aux membres existants de la communauté. Abaisser les barrières à l'entrée est toujours une tâche sérieuse. Je ne sais pas quand la prochaine personne, qui vient de commencer par corriger un document mal orthographié, mettra en œuvre la prochaine grande fonctionnalité. Mais vous pouvez être motivé en souriant et en remerciant pour toute petite contribution.
Recommended Posts