Ruby on Rails Dokumentation [Video]
(youtube.com)- Der Ausgangspunkt von Rails entstand, als David Heinemeier Hansson bei der Entwicklung von Basecamp bei 37signals die benötigten Werkzeuge selbst in Ruby baute
- Die Zusammenarbeit von Jason Fried und David begann 2001 mit einer PHP-Frage im 37signals-Blog und führte zur Entwicklung des Basecamp-Backends sowie zur Extraktion von Rails
- Rails wollte das Gefühl schneller Webentwicklung aus PHP mit der Strenge objektorientierten Designs nach Java-Art in Ruby verbinden; von Sommer 2003 bis zum Basecamp-Launch im Februar 2004 entstand die Kernform
- Die frühe Verbreitung wurde von dem realen Produkt Basecamp, der 15-Minuten-Demo, Vergleichen mit Java und dem Ruf von 37signals getragen; frühe Mitwirkende wie Jamis Buck, Jeremy Kemper und Tobias Lütke sowie das Rails core team formierten sich
- Nachdem Rails als Open Source unter der MIT-Lizenz veröffentlicht wurde, hielt es mit großen Beispielen wie Shopify und GitHub sowie einer 20 Jahre langen Community an der Richtung fest, dass auch kleine Teams große Webanwendungen bauen können
Begegnung von 37signals und David Heinemeier Hansson
- 1999 oder 2000 betrieb Jason Fried die Webdesign-Firma 37signals und baute ein Side-Project namens Single File, eine Online-Buchdatenbank, in PHP
- Er hatte sich PHP aus Büchern beigebracht und war schon weit gekommen, stieß aber auf Hürden; da es damals keine Antwortplattformen wie StackOverflow gab, bat er online um Hilfe
- David Heinemeier Hansson, der in der Webbranche im dänischen Kopenhagen arbeitete, las regelmäßig den 37signals-Blog Signal vs. Noise und antwortete 2001 auf Jasons Programmierfrage
- Davids Antwort war sehr ausführlich, und Jason hatte den Eindruck, dass es nicht nur ein Kommentar war, sondern echte Hilfsbereitschaft
- Danach sah sich David Jasons gesamten Code an und sagte sinngemäß: „Das ist nicht besonders gut, lass uns neu anfangen“ — an diesem Punkt begann die Zusammenarbeit der beiden
- Eine Zeit lang arbeiteten sie remote, bevor sie sich zum ersten Mal persönlich in der Nähe des Hancock Building in Chicago trafen; Jason erinnert sich daran, dass Davids weiße Kleidung sehr auffällig war
Beim Bau von Basecamp wurde Rails geboren
- 37signals verwaltete Client-Projekte per E-Mail und hatte das Gefühl, dass es schwierig war, Dateiversionen, offene Aufgaben und den Stand der Release-Vorbereitung nachzuverfolgen; deshalb beschloss man 2003, ein internes Projektmanagement-Tool zu bauen
- David war damals Student an einer Business School in Kopenhagen und konnte nur etwa 10 Stunden pro Woche arbeiten; als Gegenleistung für die Entwicklung des Basecamp-Backends wollte er lieber ein Apple-Notebook und Ausrüstung als Geld
- Über Texte von Martin Fowler und Dave Thomas kam David mit Ruby in Kontakt und fühlte sich von einer Sprache aus Japan angezogen, deren Code sich wie Pseudocode lesen ließ
- Für frühere Arbeiten bei 37signals war PHP verwendet worden, doch David entschied sich, das Basecamp-Backend in Ruby zu bauen, und Jason vertraute dieser Entscheidung
- David fand in Rails eine Kombination aus zwei Dingen
- der Unmittelbarkeit, mit der man wie in PHP schnell etwas ins Web bringen konnte
- der intellektuellen Strenge objektorientierten Designs und von Mustern, wie man sie aus Java kannte
- Damals gab es in Ruby noch nicht viele Bibliotheken oder Frameworks, die Webentwicklung und Datenbankzugriff unterstützten, also baute David die Werkzeuge, die er für Basecamp brauchte, selbst
- Von Sommer 2003 bis zur Veröffentlichung von Basecamp im Februar 2004 entstand der Kern von Rails; nach dem Basecamp-Launch wurden Code und Dokumentation noch etwa sechs Monate lang verfeinert, bevor Rails 2004 veröffentlicht wurde
Frühe Veröffentlichung, provokantes Marketing und die Bildung des Core-Teams
- Bei den Vorbereitungen zur Veröffentlichung von Rails hielt David nicht nur den Code, sondern auch die Qualität der Dokumentation für wichtig und war der Meinung, dass die erste Version gut genug sein müsse
- Als Rails Aufmerksamkeit zu bekommen begann, wollte David die Richtung des Frameworks entschlossen verteidigen und sagte zu Anforderungen, die er nicht wollte, auch „Nein“
- Auf einer frühen Rails-Konferenz verwendete David als Reaktion auf unfaire Forderungen und Drohungen mit Misserfolg eine Folie mit „F()c% You“ und machte damit deutlich, dass Open Source keine kommerzielle Beziehung ist und Nutzer die Richtung nicht vorgeben können
- Gleichzeitig wuchs Rails, indem es gute Arbeit von Tausenden Mitwirkenden aufnahm; David lehnte also weder Feedback noch Beiträge grundsätzlich ab
- Auf der International Ruby Conference 2004 stellte David Rails vor und konzentrierte sich weniger auf Code-Demos als auf die Gründe für Rails und das Ziel, Programmierern eine bessere Erfahrung zu geben
- Im ersten etwa einjährigen Zeitraum commitete nur David direkt in den Code; Patches wurden per E-Mail und Wiki entgegengenommen
- Später erhielten Personen mit vielen Beiträgen Zugang zur Codebasis, und so entstand das Rails core team; Jamis Buck, Jeremy Kemper, Marcel Molina, Scott Barron, Sam Stephenson und Michael Koziarski gehörten zu den frühen Committern
- 37signals stellte einige Mitglieder des Rails core team und einige Rails-Mitwirkende ein; Jamis Buck wurde in der Wachstumsphase von Basecamp zum ersten von 37signals eingestellten Programmierer
Ein reales Produkt und das Ökosystem sorgten für die Verbreitung
- Für die frühe Aufmerksamkeit von Rails spielten der Ruf von 37signals und das reale Erfolgsprodukt Basecamp eine große Rolle
- David war der Ansicht, dass ein Tool auf Basis einer weniger bekannten Sprache wie Ruby keine leise Einführung, sondern einen lauten Aufschlag brauche, und erstellte provokante Materialien, die Java-Implementierungen mit Rails-Implementierungen verglichen
- Zur Verbreitung von Rails trugen die 15-Minuten-Demo, zahlende Basecamp-Kunden und Wachstum sowie tatsächlich laufender Code gemeinsam bei
- Tobias Lütke nutzte Rails sehr früh, als er in Kanada ein Unternehmen gründen wollte und einen Online-Snowboard-Shop baute; dieses Projekt, Snowdevil, führte später zu Shopify
- Tobias erinnert sich, dass er dank Rails das System allein bauen konnte und produktiver war als andere Teams, die damals Online-Shops aufbauten
- Shopify ist ein von Rails geprägtes Unternehmen, verwendet auch heute noch die neueste Rails-Version, hat den Großteil seiner Codebasis in Ruby und dieselbe grundlegende Ordnerstruktur wie eine gewöhnliche Rails-App
- Kritik, Rails „skaliere nicht“, gab es von Anfang an, doch Basecamp unterstützte echte Nutzer, und schon bevor Beispiele wie Shopify und GitHub auftauchten, wurde entgegnet, dass Rails von Beginn an skalierbar gewesen sei
- Shopify wird als großer Dienst beschrieben, der etwa 10 % des weltweiten E-Commerce ausmacht; es gibt auch die Einschätzung, man wisse nicht, welche Größenordnung Rails nicht bewältigen könne
Releases, die Merb-Fusion und eine Richtung über 20 Jahre hinweg
- Für die Veröffentlichung von Rails war es von Anfang an selbstverständlich, auf Open Source zu setzen; David meinte, dass die Grundlage, die Webarbeit möglich gemacht hatte, aus Open-Source-Werkzeugen bestand, weshalb auch sein eigener Werkzeugkasten geteilt werden sollte
- Es gab zwar auch Überlegungen, Rails zu monetarisieren oder als Wettbewerbsvorteil exklusiv zu halten, doch David hielt Open Source unter der MIT-Lizenz für wichtig und entschied sich, Rails sehr erfolgreich zu machen
- Ein von Jamis Buck für das Deployment von Basecamp gebautes Werkzeug etablierte sich später unter dem Namen Capistrano
- Der Verlauf wichtiger Rails-Releases sieht wie folgt aus
- Rails 1.0 war ein wichtiger Ausgangspunkt
- Rails 1.2 wird als stabiles frühes Release bewertet, das ein reifes Web-Framework erkennen ließ
- Rails 2.0 brachte im Dezember 2007 cookie-basierte Sessions und named scopes
- Rails 2.3 wurde im März 2009 als Release beschrieben, das modernen Webentwicklern die nötigen Werkzeuge für kleine bis große Apps bot
- Zur Zeit von Rails 2.3 kam jQuery auf, und Rails wollte Raum schaffen, um die Energie der JavaScript-Welt aufzunehmen
- Später trat das Ruby-Web-Framework Merb als schnellerer, leichterer Konkurrent auf, der bewusst weniger tat, und die Rails-Entwickler sahen darin Dinge, von denen sie lernen konnten
- Rails 3.0 führte zur Fusion mit Merb, was eine große Neugestaltung erforderte, um das Innere von Rails konfigurierbar, neu kombinierbar und modular zu machen
- Die Rails-Community legt ihren Fokus darauf, dass auch Menschen ohne formale Ausbildung in Informatik oder Programmierung Webanwendungen bauen und eine Karriere aufbauen können
- Rails wollte die Einstiegshürde senken und danach einen Weg eröffnen, in Unternehmen oder Branchen zu einem Programmierer auf hohem Niveau zu werden
- Wie es heute auf der Rails-Website heißt, ist Rails ein Framework, mit dem man „von Hello World bis zum IPO“ als kleines Team gehen kann, und sowohl die Community als auch die Qualität der Codebasis werden heute als besser denn je bewertet
1 Kommentare
Hacker-News-Meinungen
Ich habe diese Dokumentation wirklich gern gesehen, und durch Tobys persönliche Geschichte bei Shopify kam die Perspektive eines Ein-Personen-Frameworks gut zur Geltung.
Auch „From Hello World to IPO“ war gut, und besonders beeindruckt hat mich die Aussage, dass die Struktur fast gleich ist, egal ob man die größte Rails-App oder eine neue Rails-App öffnet.
In der heutigen Umgebung, in der APIs und Frontend-Stacks miteinander verflochten sind, ist diese Konsistenz nicht immer garantiert.
Die neuesten Entwicklungen in Rails machen ein solides Fundament noch robuster, und neben Kamal laufen auch Arbeiten wie Solid Cache und Solid Queue, die Infrastruktur einfacher machen.
Im Frontend ist Turbo Morphing aktiv, bei mobilen Apps sind es Turbo Native und Strada.
Ich habe bereits auf 7.1 aktualisiert und betreibe eine mit Turbo Native gebaute mobile App; außerdem freue ich mich darauf, den Redis-Cache durch Solid Cache zu ersetzen, um alles einfacher zu machen und länger cachen zu können.
Es ist schön zu sehen, dass die Rails-Community weiterhin aktiv ist und ehemalige wie aktuelle Core-Team-Mitglieder eng mit dem Framework verbunden sind.
Ich habe Rails nie benutzt, aber was ich am Node.js-Ökosystem wirklich hasse, ist das Fehlen klarer Konventionen.
Selbst bei Verwendung desselben Frameworks ist die Struktur immer anders und chaotisch; die Ausnahme ist vielleicht Next.js, aber das ist eher im Frontend zu Hause.
Rund um Ruby und Rails entstehen auch viele Entwicklungstools, daher hoffe ich auf weitere gute Veränderungen in Rails 8.0 und Ruby 3.4.
Dass er sich als Gründer von Shopify herausstellt und ein Vermögen von 5,5 Milliarden Dollar hat, fand ich amüsant.
Entwickler neigen wirklich dazu, diesen Aspekt von RoR zu unterschätzen.
Das erleichtert nicht nur das Onboarding, sondern reduziert auch Bikeshedding erheblich.
MVC ist vielleicht nicht für alles die beste Lösung, aber in den meisten Fällen gut genug.
Das muss ich mir heute später ansehen.
Ich habe mit mehreren Frameworks wie Laravel, ExpressJS, MeteorJS, Django und Flask gearbeitet, und jedes hatte seine Vor- und Nachteile, aber beim Folgen von Tutorials oder beim Ausprobieren meines eigenen Wegs habe ich immer irgendwann aufgegeben.
Vor drei Tagen habe ich mit Rails angefangen und konnte übers Wochenende schnell ein MVP bauen, das ich einem Kollegen zeigen kann.
Rails ließ mich darauf konzentrieren, was die App tun soll, statt darauf, wie die App implementiert werden soll, und jetzt verstehe ich endlich, warum die Leute es so mögen.
In Rails ist man wirklich produktiv.
Seit Langem ist mein größter Kritikpunkt, dass es zu wenig Dokumentation oder viele widersprüchliche Informationen gibt, wenn man von den Konventionen abweicht.
Den „gesegneten Weg“ zu finden und zu verstehen, kann sehr schwierig sein; glücklicherweise ist ChatGPT ziemlich gut darin, hierfür einen Ausgangspunkt zu liefern.
Es war eine wirklich hervorragende Dokumentation.
Ich habe Rails in den letzten Jahren genutzt, und für kleine Teams ist es sehr produktiv, um Produkte zu bauen und Business Logic nach gut etablierten Mustern umzusetzen.
Wenn man neugierig ist, wie eine echte Rails-App strukturiert ist, empfehle ich, sich die Jumpstart-Codebase anzusehen. Sie ist eine gute Ressource, um zu lernen, wie man die Struktur aufbaut.
https://jumpstartrails.com/
Als Alternative ist Bullet Train ebenfalls ziemlich gut, fügt aber viele maßgeschneiderte Libraries hinzu, die man schwerlich als „Rails Way“ bezeichnen kann.
https://bullettrain.co/
Ich finde, diese Rails-Doku und die Elixir-Doku konnten vieles nicht einfangen.
Sie sind so kurz, dass sie gerade erst die Entstehungsgeschichte anreißen und dann enden; sie hören auf, bevor sie die wirklich spannenden Punkte erreichen.
Statt der Community oder Außenstehenden zu zeigen, wie großartig diese Technologien sind, wirkten sie eher so, als würden sie das Ego der Mitwirkenden stärken.
Ich wünschte, man hätte jeweils eine 90-minütige Dokumentation über Elixir und Rails gemacht und wäre über gegenseitiges Lob hinaus zwischen jahrelanger harter Arbeit, unterschiedlichen Einsatzweisen in verschiedenen Unternehmen und Ähnlichem hin- und hergesprungen.
Anders gesagt: Wenn man das Format von Indie Game: The Movie übernehmen würde, wäre es viel fesselnder; ich hoffe, es gibt mehr gute Dokumentationen über Software.
Es gab viele kleine historische Puzzlestücke, die man anderswo kaum findet: wie ungewöhnlich Davids Ansatz war, wie sich das Rails-Team über Toby und andere formierte, wie es mit anderen Frameworks zusammenkam und so weiter.
Länger wäre auch gut gewesen, aber schon dass sie das überhaupt geschaffen haben, ist großartig.
Ich habe sie gesehen, denke aber, dass sie nicht ausreichend gezeigt hat, was Rails geleistet hat.
Ruby on Rails hat den Paradigmenwechsel weg von dateizentrierten Ansätzen wie PHP, JSP und WebForms hin zum Bau von Webanwendungen mit Routes und MVC-Pattern vollzogen, und heute hat fast jedes ordentliche Web-Framework diesen Ansatz.
Die Dokumentation hat diesen Punkt nicht angesprochen, war aber trotzdem unterhaltsam.
Allerdings ist es mir fast unangenehm, Struts und Rails im selben Satz zu nennen, weil Rails sehr viel mehr geleistet hat.
Die legendären Figuren der frühen Rails-Zeit haben den Weg für die moderne Entwicklung von Web-Apps geebnet.
Man kann sogar sagen, dass es in der Webentwicklung ein Vor und Nach Rails gibt.
Wenn man die Kommentare liest, klingt es so, als würde Rails wieder etwas beliebter werden und sich von dem Ruf lösen, nur ein langweiliges, aber solides Framework zu sein.
Rails erinnert mich an mein früheres Ich, als ich interessantere und rauere Dinge gebaut habe, und an eine andere Zeit, die damals zu meinem Weg passte.
Was ich an Rails wirklich hoch schätze, ist die starke Vision und dass es nicht zu noch einem aufgeblähten Framework für den Bau „enterprise-tauglicher“ Anwendungen geworden ist.
Obwohl es ein 20 Jahre altes Framework ist, scheut es sich nicht, sich mutig mit der Zeit zu verändern, und wirkt im Vergleich zu anderem immer noch wie Punk.
Als ich an meine eigene Geschichte zurückdachte, wie ich vor 20 Jahren mit Rails anfing, wurde mir warm ums Herz.
https://twitter.com/buger/status/1723040883325460818
Von 2015 bis 2019 habe ich an einer sehr großen produktiven Rails-App gearbeitet, und dadurch habe ich Rails lieben gelernt, Ruby aber nicht mehr gemocht.
Wenn es ein Rails in TypeScript oder Go gäbe, fiele mir kein Grund ein, für Web-App-Backends etwas anderes zu verwenden.
Die Rails Console ist eines der besten Produktivitätswerkzeuge, die mir je begegnet sind.
Bei TypeScript könnte es vielleicht über das bestehende Node-REPL gehen, aber der Hauptgrund, warum die Rails-Konsole so nützlich ist, liegt letztlich in Ruby selbst.
Die Honeypot-Dokumentationen sind wirklich gut und sehr zu empfehlen.