Fasst die Grundidee des Erstellers von Rails, DHH, zusammen
https://rubyonrails.org/doctrine/#optimize-for-programmer-happiness https://postd.cc/rails-doctrine/
Der Grund, warum DHH Rails kreiert hat, ist "mich zum Lächeln zu bringen"
Es ist nicht logisch, sondern eher krankhaft, aber ich habe es geschafft, mich glücklich zu machen
Die Rails-Community hat sich zum Glück zusammengeschlossen, und Rails wurde durch die Optimierung des Glücks geprägt.
Das frühe Motto für die Rails-Produktivität lautete: "Wenn Sie aufhören, Persönlichkeit zu verschwenden, können Sie in wichtigen Situationen schneller arbeiten, ohne mit mittelmäßigen Entscheidungen zu kämpfen." Ob der Primärschlüssel der Datenbank id, postId, posts_id, ist Die Diskussion über PID besteht darin, unnötige Überlegungen zu vermeiden und die Produktivität zu steigern, indem von der Abfallentsorgung zur Konvention übergegangen wird.
Darüber hinaus verringern die Konventionen die Hürden für Anfänger: Es gibt viele Rails-Konventionen, die Anfänger nicht kennen müssen, und sie haben die Vorteile ihrer Unwissenheit. Es ist unmöglich, wenn das Framework, das Sie erstellen können, nur ein dickes Lehrbuch ist
Es ist leicht zu glauben, dass Sie alles mit vorhandenen Vorlagen erstellen können, aber normalerweise sind 5% oder 1% es wert, eigene Elemente zu haben.
Es ist schwer zu wissen, wann man von den Regeln abweicht. Die meisten Abweichungen sind undenkbar und die Kosten für das Absteigen von den Schienen werden unterschätzt.
--Kommentar
Es war mir eigentlich egal, aber der Name Ruby on Rails bedeutet wahrscheinlich "Ruby in Übereinstimmung mit den Regeln (Rail)" https://jp.quora.com/Ruby-Rails-no-namae- no-yurai-wo-oshie-te-kuda-sai
Für die Programmierung sind die Vorteile, die es anderen überlassen, ähnlich wie bei Konventionen und nicht bei Einstellungen, jedoch auf einer höheren Ebene. Während CoC darüber nachdenkt, wie einzelne Frameworks am besten verwendet werden können, überlegt Random, welche Frameworks verwendet werden sollen und wie sie kombiniert werden sollen. Dies widerspricht der erhabenen Programmiertradition, verfügbare Tools als individuelle Auswahlmöglichkeiten darzustellen, aber diese Tradition hat einzelnen Programmierern das Privileg (und die Last) gegeben, zu entscheiden, "die besten Tools für den Job zu verwenden". Das Wort "ist unbestreitbar rudimentär", aber die Auswahl des "besten Werkzeugs" erfordert eine Grundlage, auf der Sie sicher das "Beste" beurteilen können, was schwieriger ist, als Sie vielleicht denken.
Deshalb haben wir uns bei Rails entschlossen, das persönliche Privileg des Programmierers, jedes Werkzeug in der Box auszuwählen, um eins für eine Toolbox zu reduzieren, die für alle gut ist. Dadurch konnten wir viele Vorteile erzielen.
Erfahrungen können ausgetauscht werden, wenn die meisten Benutzer Rails mit denselben Standardeinstellungen verwenden. Eine gemeinsame Basis macht es viel einfacher, andere zu unterrichten und ihnen zu helfen. Es fördert ein stärkeres Gemeinschaftsgefühl.
Als Full-Stack-Framework verfügt Rails über viele dynamische Teile, und es ist genauso wichtig, wie sie zusammenarbeiten, wie wie sie alleine arbeiten. Softwareprobleme werden nicht durch jede Komponente verursacht, sondern durch ihre Interaktion. Sie können die Anzahl der Fehler reduzieren, wenn Sie zusammenarbeiten, um häufige Fehler mehrerer konfigurierter Komponenten zu verringern und in derselben Situation fehlzuschlagen.
Während Rails ein "zufälliger" Stapel ist, kann er auch durch andere Frameworks und Bibliotheken ersetzt werden. Es ist jedoch nicht wesentlich. Dies bedeutet, dass Sie später eine klare und persönliche Palette entwickeln können, die den gelegentlichen Unterschieden entspricht. Es ist genug, dass selbst erfahrene und erfahrene Programmierer nicht alles im Menü mögen (wenn jemand damit zufrieden ist, steckt es noch nicht in Rails). Sie tauschen fleißig etwas anderes aus und gehen dann zu einem anderen Stapel, den jeder überwacht, teilt und genießt.
Ich wusste nichts anderes als "Rails besteht aus vielen verschiedenen Ideen" ...
Wir schreiben keinen Code, nur um von Computern und anderen Programmierern verstanden zu werden, wir schreiben Code, um das warme Licht der Schönheit zu erhalten. Schöner Code ist ein Wert für sich und sollte energisch verfolgt werden. Das bedeutet nicht, dass schöner Code immer andere übertrifft, aber er sollte immer Priorität haben.
class Project < ApplicationRecord
belongs_to :account
has_many :participants, class_name: 'Person'
validates :name, presence: true
end
Es sieht aus wie ein DSL, ist aber eigentlich nur eine Klassendefinition, die drei Klassenmethoden aufruft, die Symbole und Optionen verwenden. Es ist nichts auffällig. Aber es ist sicherlich hübsch und einfach. Aus diesen wenigen Erklärungen kann eine enorme Menge an Kraft und Flexibilität gewonnen werden.
Ein Teil der Schönheit kommt von der Tatsache, dass diese Aufrufe "Konventionen statt Einstellungen" respektieren. Beim Aufruf von Gehört_zu: Konto heißt der externe Schlüssel Konto_ID und nimmt an, dass er sich in der Tabelle Projekte befindet. Wenn Sie einen Personenklassennamen für eine Teilnehmerzuordnungsrolle angeben müssen, müssen Sie nur diesen Klassennamen definieren. Von dort können Sie externe Schlüssel und andere Einstellungen erhalten.
class CreateAccounts < ActiveRecord::Migration
def change
create_table :accounts do |t|
t.integer :queenbee_id
t.timestamps
end
end
end
Dies ist die Essenz der Kraft des Frameworks. Der Programmierer deklariert die Klasse gemäß bestimmten Konventionen (z. B. einer Unterklasse von ActiveRecord :: Migration, die #change implementiert). Das Framework durchläuft dann alles und erkennt, dass dies die Methode ist, die es aufruft.
Dadurch bleibt dem Programmierer nur sehr wenig Code zum Schreiben. Bei Migrationen können Sie nicht nur Rails db: migrate aufrufen, um Ihre Datenbank zu aktualisieren und eine neue Tabelle hinzuzufügen, sondern Sie können diese Tabelle auch mit Rails db: rollback löschen. Dies unterscheidet sich stark von einem Programmierer, der eine Bibliothek verwendet, um Workflows zusammenzufügen, um diese Ziele zu erreichen.
Ruby hat viele scharfe Messer in seinen Eigenschaften. Es ist kein Zufall, es ist ein Design. Das bekannteste ist das Affenfeld. Die von Rails angebotenen Messer sind nicht so scharf wie die von Ruby, aber sie sind immer noch scharf genug. Ich glaube, dass jeder Programmierer die Möglichkeit hat, ein voll kompetenter Ruby and Rails-Programmierer zu werden, wenn nicht sogar ein Recht. Und kompetent bedeutet, das Wissen zu haben, wann, wie und wann je nach Situation unterschiedliche und manchmal gefährliche Werkzeuge in einer Schublade verwendet werden müssen.
Schienen können in vielen Kontexten verwendet werden, aber die erste besteht darin, ein integriertes System zu erstellen. Ein prächtiger Monolith! Das gesamte System, das das gesamte Problem behandelt. Mit anderen Worten, Rails ist an allem beteiligt, vom Front-End-JavaScript bis zur Datenbank. Dies ist ein sehr breiter Bereich, der jedoch für eine einzelne Person nicht unrealistisch ist. Rails zielt speziell darauf ab, Generalisten die Erstellung dieser vollständigen Systeme zu ermöglichen. Es ist ein integriertes System, das sich darauf konzentriert, Einzelpersonen zu befähigen. Benutzerfreundlichkeit und Verständnis als ein einziges integriertes System, das Ihnen die Leistung individuell abgestimmter und verteilter Anwendungen bietet
--Kommentar
Ich glaube nicht, dass ich den Mikrodiensten so sehr zustimme.
Wenn ein System wie Rails seit mehr als 10 Jahren existiert, wird es auf natürliche Weise repariert. Natürlich kann jede Änderung für diejenigen, die sich auf frühere Verhaltensweisen verlassen haben, ein Problem sein. Aber wenn es zu konservativ ist, kann man nicht sehen, was auf der anderen Seite ist. Der Status Quo muss gebrochen und für Evolution und Wachstum geändert werden. Die Evolution wird es Rails ermöglichen, über Jahrzehnte hinweg zu überleben und zu gedeihen.
Rails-Versionen sind verfügbar, aber wir sollten die Führung übernehmen, um zur Entwicklung von Ruby beizutragen, indem wir schnell neue Versionen von Ruby einführen.
Fortschritt hängt oft von der Person und ihrer Bereitschaft ab, Veränderungen voranzutreiben. Deshalb haben Gruppen wie Rails Core und Rails Committers keine unbefristeten Plätze. Beide Gruppen richten sich an diejenigen, die aktiv an der Weiterentwicklung des Frameworks arbeiten. Ebenso ist es sehr wichtig, weiterhin neue Mitglieder der Gemeinschaft willkommen zu heißen und zu ermutigen. Wir brauchen frisches Blut und frische Ideen, um bessere Fortschritte zu erzielen.
Rails hat viele kontroverse Ideen. Wenn Sie also immer aufgefordert werden, jeder Idee vollständig zu folgen, wird Rails schnell als Gruppe ideologischer Verstecke isoliert. Also nicht! Wir müssen nicht zustimmen. Ich brauche einen Dialekt. Wir brauchen die Vielfalt der Ideen und Menschen. Es gibt die beste Gemeinsamkeit im Topf dieser Idee. Der anhaltende Erfolg von RSpec, einem Test-DSL, mit dem ich oft ernsthafte Unzufriedenheit zum Ausdruck gebracht habe, ist ein perfekter Beweis. Ich frage mich, warum das nicht der Fall sein sollte. Ich kann schreien, bis mein Gesicht blau wird, aber RSpec kann immer noch blühen und gedeihen. Das ist viel wichtiger.
Gleiches gilt für das Aufkommen von Rails als API. Mein persönlicher Fokus und mein Engagement liegen auf dem integrierten System, das Ansichten enthält, aber es besteht kein Zweifel daran, dass Rails für jeden geeignet ist, der Clients und Server vorverteilen möchte.
Ein großes Zelt zu haben bedeutet nicht, für alle universell zu sein. Es bedeutet, alle willkommen zu heißen und ihnen zu erlauben, ihre eigenen Getränke mitzubringen. Mit der Teilnahme anderer müssen wir nicht unsere Seele und Werte verlieren, und wir können lernen, wie man neue köstliche Getränke mischt. Dies kann nicht kostenlos durchgeführt werden. Es braucht Mühe, Sie willkommen zu heißen. Vor allem, wenn Ihr Ziel nicht nur darin besteht, mehr Menschen anzuziehen, die den bestehenden Mitgliedern der Community ähnlich sind. Der Abbau von Eintrittsbarrieren ist immer eine ernste Aufgabe. Ich weiß nicht, wann die nächste Person, die gerade mit der Korrektur eines falsch geschriebenen Dokuments begonnen hat, die nächste großartige Funktion implementieren wird. Aber Sie können motiviert sein, indem Sie lächeln und sich für kleine Beiträge bedanken.
Recommended Posts