Ruby on Rails Nachteile und Vorbehalte [geschlossen]


25

Dies ist kein Eröffnungsgambit für RoR-Bashing - ehrlich!

Ich lerne Ruby und das Rails-Framework. Auf den ersten Blick scheint es ziemlich cool zu sein und eine wunderbare Erfahrung im Vergleich zu PHP. (Tatsächlich erinnert es mich an glücklichere Tage mit C # und .NET.)

Ich habe jedoch keine Erfahrung mit diesem Framework oder dieser Sprache und bin neugierig - was sind die aktuellen Nachteile oder Dinge, die Sie zu Beginn gerne gewusst hätten?

(Vielleicht sollte dies ein Community-Wiki gemacht werden?)


Ich habe Rails einmal ausprobiert und habe angehalten, als mir klar wurde, dass ein Entwurf von Entitäten, die als erste Datenbank dienen, nicht einfach möglich ist.
Falcon

5
avdi.org/devblog/2011/08/22/your-code-is-my-hell ist lesenswert. Ich würde hinzufügen, dass es bei jeder dynamisch getippten Sprache äußerst wichtig ist, dass mindestens 80% der Tests abgedeckt sind, da sonst ein Refactoring nahezu unmöglich ist.
Eric Wilson

Wenn Sie Ihre Frage spezifischer und ausgewogener gestalten (z. B. "Umstieg von PHP auf Ruby on Rails - Vor- und Nachteile"), müssen Sie sich nicht mehr dem Bashing und dem Wunsch nach Community-Wiki widersetzen.
Thomas Langston

2
@Thomas Aber das ist nicht meine Frage! Die Vor- und Nachteile von PHP sind bekannt. Die Profis von RoR sind ziemlich leicht zu finden. Allerdings sind die Nachteile von RoR als Neuling nicht leicht zu entdecken, und ich vermute, dass sie nur mit langjähriger Erfahrung entdeckt werden können. Dabei ist es das Ziel, aus den Erfahrungen anderer zu lernen. Viele der CWs, die ich gelesen habe, sind von Natur aus sehr spezifisch.
Matty

Antworten:


32

Dies ist aus Erfahrung gelernt, weiter zu lernen und eine relativ einfache Anwendung in Rails zu schreiben.

1) Lernkurve

Rails ist täuschend einfach. Die Tutorials, Videos und Bücher zeigen, wie schnell Sie eine funktionierende (wenn auch hässliche) Anwendung erstellen können, aber diese kratzen wirklich nur die Oberfläche. Sie verlassen sich in der Regel stark auf die Codegenerierung und das "Scaffolding", was zwar ein gutes Werkzeug beim Lernen ist, dessen Nützlichkeit jedoch schnell überlebt.

Machen Sie keinen Fehler, Rails ist schwer zu meistern. Sobald Sie die Grundlagen überwunden haben (dazu später mehr), stoßen Sie kopfüber auf eine Mauer, wenn Sie mehr tun müssen als nur die extrem vereinfachte "Demo-App" -Funktionalität, die Sie ankündigen. Sie können mit Grundkenntnissen in Ruby auskommen, während Sie lernen, aber Sie müssen Ruby schnell erlernen, oder Sie bleiben hoch und trocken (und nicht die gute Art von DRY), wenn Sie die Einschränkungen von Rails überschreiten müssen.

Rails ist, wie ich es liebevoll nenne, Malen durch Zahlenprogrammierung . Wenn Sie sich zu 100% an die Konventionen halten (dh innerhalb der Linien bleiben und die Farben verwenden, die Sie verwenden sollen), können Sie schnell und einfach anständige Anwendungen erstellen. Wenn Sie jedoch abweichen müssen, kann Rails von Ihrem besten Freund zu Ihrem schlimmsten Feind werden.

2) Wenn alles, was Sie haben, ein Hammer ist ...

Rails kann sehr gut vereinfachte CRUD-Anwendungen ausführen. Das Problem tritt auf, wenn Ihre App mehr als nur Lesen / Schreiben aus einer Datenbank ausführen muss. Nun, die letzte Rails-Version, die ich verwendet habe, war 2.3.4, also haben sich die Dinge seitdem möglicherweise geändert, aber ich hatte große Probleme, als sich die Geschäftsanforderungen änderten, sodass in die Anwendung ein kleines Workflow-System eingebaut und integriert werden musste eine ältere PHP-Anwendung. Die Rails-Konvention "One Form, One Model" eignet sich gut für einfache Apps und Dateneingabeanwendungen, jedoch nicht für Anwendungen, bei denen Verarbeitungslogik erforderlich ist, Workflows vorhanden sind oder bei denen der Benutzer keine typischen Daten eingibt ein paar Textfelder, drücke "Submit". Es kann getan werden, aber es ist keineswegs "einfach", oder vielmehr war es nicht

Rails spielt auch nicht gerne gut mit anderen Anwendungen, die nicht die bevorzugten Methoden für den Datenzugriff verwenden. Wenn Sie mit einer Anwendung kommunizieren müssen, die keine API im "Web 2.0" -Stil hat, müssen Sie Rails umgehen, anstatt damit zu arbeiten. Ich spreche hier wieder aus Erfahrung, denn das ist mir passiert.

3) Es ist neu

Schließlich ist Rails in vielen Bereichen immer noch das "neue Kind auf dem Block". Dies spielt keine Rolle für den persönlichen Gebrauch oder für Szenarien wie "Ich denke, es ist cool und möchte es lernen", sondern für jemanden, der Rails bei meiner täglichen Arbeit bevorzugt, wenn Sie sich nicht an einem Ort befinden, an dem Rails ist Weit verbreitet, kann es sehr schwierig sein, eine Vollzeitstelle als Rails-Entwickler zu finden. Es ist immer noch weitgehend die Domäne von "angesagten, neuen Startups" und in den meisten Ballungsräumen kein Hauptakteur. Ihr Kilometerstand kann in dieser Hinsicht variieren, aber ich weiß, dass meine Gebietsschienen (Tampa) im Wesentlichen nicht vorhanden sind.

4) Feuer und Bewegung

Die Schienen ändern sich ständig. Dies ist sowohl eine gute als auch eine schlechte Sache. Es ist gut, weil sich die Community weiterentwickelt und neue Konzepte annimmt. Es ist schlecht, weil sich die Community weiterentwickelt und neue Konzepte annimmt. Es kann für einen Rails-Neuling sehr überwältigend sein, denn normalerweise werden Sie feststellen, wenn Sie auf ein Problem stoßen und sich umsehen, dass entweder Leute das eine oder andere Juwel empfehlen, um es zu beheben, oder Sie sagen, dass dieser Weg sowieso schlecht ist, und Sie sollten es nicht. Wenn Sie es nicht verwenden, haben Sie hier eine bessere Möglichkeit ... und am Ende haben Sie eine Wäscheliste mit zusätzlichen Tools, die Sie zusammen mit Rails lernen können, um mit den Rails-Erkenntnissen Schritt zu halten. Dinge wie Git, BDD/RSpec, Cucumber,Haml/Sassund ein Füllhorn an anderen Dingen schwebt herum und wird als der "richtige Weg, Dinge zu tun" in Rails-Land gedrängt, und wenn man aus Erfahrung spricht, könnte man überfordert sein, ein Dutzend oder mehr Technologien zusätzlich zu Rails zu lernen. weil sich die Verwendung des Standard Rails-Toolkits "falsch" anfühlt.

Dies wird jetzt durch Rails 3.1 noch verstärkt, wodurch Sass und CoffeeScript zum Standard werden. Ein absoluter Rails-Neuling muss also nicht nur Ruby und Rails lernen, sondern auch Sass (wohl einfach, wenn Sie CSS kennen) und CoffeeScript (nicht verrückt schwierig, aber sicher) unterschiedlich genug von rohen JavaScript) auf ein absolutes Minimum zu beginnen, und es kann davon ausgegangen werden Git. Auch ohne RSpec und Freunde und das Dutzend oder mehr Juwelen, mit denen Sie normalerweise enden, müssen Sie vier verschiedene Dinge lernen, bevor Sie ernsthaft mit dem Schreiben von Rails-Anwendungen beginnen können. Vergleichen Sie dies mit einer Sprache wie C # oder Java oder sogar PHP, in der sich Ihre HTML- / CSS- / JavaScript- / SQL-Kenntnisse nicht ändern werden und Sie nur die Sprache selbst und möglicherweise die Framework-Nuancen lernen müssen.


3
WRT Rails 3.1 Sass & CoffeeScript sind Standardeinstellungen, die leicht deaktiviert werden können. Tatsächlich funktioniert "normales" CSS nur, da Rails 3.1 die SCSS-Syntax von SASS verwendet. Du könntest sie benutzen, aber du bist keinem Zwang ausgesetzt. WRT Git Ich denke, Linus erklärt es besser, warum Sie wirklich ein DVCS wie Git verwenden sollten, unabhängig davon, welches Framework Sie verwenden. youtube.com/watch?v=4XpnKHJAok8
Shreyas Satish

Oh, ich bin damit einverstanden, nur zu sagen, dass der Rails-Standard normalerweise sehr hochgelobt ist, so dass ein Neuling sich gezwungen fühlt, ihn zu verwenden (ich weiß, dass ich mich so gefühlt habe)
Wayne Molina,

3
+1 für # 4 ... wenn du Rails für ein Jahr verlässt, wenn du zurückkommst, fliegen alle in Raumschiffen herum und du bist in deinem Ruderboot und denkst wtf? Die Rails 2-Syntax war vor der Veröffentlichung von Rails 3 veraltet.
Jimworm

-1 Guter Rails-Bashing-Pfosten, aber Sie schlagen nicht einmal eine Alternative vor. "Verschachtelte Formen" sind ein schwieriges Problem, und Rails löst es wahrscheinlich besser als jeder andere.
Scottschulthess

13

Dokumentation.

Während Rails-Handbücher eine hervorragende Lernressource darstellen, ist die Navigation in der Rails-Bibliothek (und allgemein in Ruby) nicht einfach. Angenommen, Sie möchten mehr über die belongs_toMethode erfahren . Obwohl es für ActiveRecord::BaseUnterklassen (eigene Modelle) verwendet wird, ist es nicht in Dokumenten dokumentiert ActiveRecord::Base, sondern in einem Mixin , das von der Klasse importiert wird. Im Wesentlichen können Sie keine umfassende Liste aller Methoden anzeigen, die Sie an einem Objekt an einem Ort verwenden können (außer wenn Sie irbdas Objekt selbst starten und überprüfen).

Bei einer hochdynamischen Sprache wie Ruby ist es nicht einfach festzustellen, woher eine von Ihnen verwendete Methode stammt. Dies kann ein Problem sein, insbesondere für Programmierer, die versuchen, sich einen Überblick über einen neuen Technologie-Stack zu verschaffen.


Das ist ein Mörder für mich; Wenn ich einen Teil unseres Ruby / Rails-Codes debuggen muss, habe ich immer viel zu viel Zeit darauf verwendet, herauszufinden, wo eine bestimmte Methode definiert wurde. und selbst dann muss ich immer die Idee im Hinterkopf behalten, dass die Methodendefinition möglicherweise anderswo neu definiert wurde, nur weil ich sie sehen kann.
Joev

9

Ruby on Rails hat eine signifikante Lernkurve. Zuerst musst du die Kuriositäten der Sprache lernen, dann das Framework, dann die Rails-Methode und dann die vielen häufig verwendeten Gems.

Wenn Sie diese Dinge jedoch gelernt haben, kommt es unglaublich natürlich. Tatsächlich fühlen sich andere Frameworks wie eine Bürde an.

Rails ist sehr TDD / BDD-orientiert. Wenn Sie es nicht sind, müssen Sie zwei weitere Dinge lernen, bevor Sie ein kompetenter Rails-Programmierer werden. Sie haben keinen Compiler und keine IDEs, die Sie sichern könnten. Daher ist die Testabdeckung in hohem Maße Ihr Fallback.

Viele Befürworter von TDD, auch ich, würden dies als eine der Stärken von RoR und dessen Fluch ansehen. Sobald Sie mit dem Schreiben von TDD beginnen, stellen Sie fest, dass die durch die Testabdeckung gebotene Sicherheit besser ist als die durch einen Compiler gebotene Sicherheit. Dann wird das Schreiben von Code NUR, um einen Compiler zufrieden zu stellen, belastend.

TDD fühlt sich in RoR nicht als zusätzliche Aufgabe an, sondern als der einzige Weg, um zu arbeiten.

Rails hat ein schwerwiegendes Leistungsproblem: Jede Anfrage befindet sich in der Warteschlange hinter der derzeit aktiven, anstatt sie wie die meisten Frameworks zu verteilen oder zuzulassen, dass blockierende Ereignisse andere Anfragen freigeben, wie dies bei Node.js und Twister der Fall ist. Das bedeutet, Sie müssen Code eingeben, um die Antwortzeiten zu verkürzen. In den meisten Fällen ist dies jedoch recht einfach.

Rails ist auch sehr darauf ausgelegt, Content-Systeme sehr gut zu handhaben, was fairerweise viel mit dem Internet zu tun hat. Etwas komplizierter zu machen, wie ein Web-Spiel oder ein E-Commerce-System, bedeutet, neue Juwelen zu lernen. Man lernt schnell, dass alle Edelsteine ​​da draußen sind, aber je dunkler die Sache ist, die man machen möchte, desto schwieriger wird es, eine gute Dokumentation zu finden.


Zu den Leistungsproblemen - Ich erinnere mich an die Lektüre, dass viele davon mit Version 1.9 des Interpreters weitgehend gelöst wurden, aber ich könnte völlig falsch liegen. Gibt es Möglichkeiten, diese Leistungsbeschränkung zu überwinden?
Matty

1
@Matty: Wie ich hinzugefügt habe, Code, um die Antwortzeiten so schnell wie möglich zu gestalten. Alles, was einem Backend-Prozess überlassen werden kann, tun Sie dies. Aber dann solltest du das mit jedem Framework machen - es ist einfach nicht so. Auch jRuby hat einen anderen Thread, hat aber seine eigenen Probleme und meine Antwort war schon lang genug.
pdr

7

Nach meiner persönlichen Erfahrung liegt der Hauptschmerz in der Kompatibilität .

Wann:

  • Es sind xSchienenprojekte im Einsatz.
  • Jedes Projekt verwendet yEdelsteine.
  • während es nVersionen von Schienen gibt,
  • Plus- mVersionen von Edelsteinen installiert,
  • mit severalVersionen von Rubin,
  • auf einer einzigen Linux-Box als Produktionsmaschine.
  • Der Programmierer arbeitet an einem anderen OS X-Entwicklungsnotizbuch.

Als Freiberufler, die nicht den Luxus zu aktualisieren hat / die meisten Dinge aktualisieren, wird eine Menge Gesicht Kompatibilitätsprobleme von oben Variablen ... während rails, gemsund rubyändern sich ständig / weiterentwickelt.


7
Alles, was Sie erwähnt haben, wird mit RVM (oder rbenv ) und Bundler behoben . Sie können dann für jedes Projekt spezifische Versionen von Ruby und isolierte Gruppen von Edelsteinen verwenden.
Ashley Williams

Diese Antwort ist (jetzt) ​​völlig irrelevant. RVM zur Verwaltung der Ruby-Versionierung, Bundler zur Verwaltung der Gem-Versionierung; Capistrano kümmert sich um die Bereitstellung auf dem Produktionsserver und Figaro kümmert sich um Anwendungsgeheimnisse / Umgebungsvariablen. Ich entwickle meine Anwendung auf [Cloud9] (c9.io) (einer Web-IDE), und mein Bereitstellungsprozess ist buchstäblich bundle exec cap production deploy. Capistrano kümmert sich um die Versionierung der Anwendung auf dem Server. Wie jedes andere Framework, das herauskommt (zB Node.js), sind Tools geschrieben, um Ihre Probleme zu lösen .
Chris Cirefice

5

Geschwindigkeit ist definitiv ein Problem. Rubys extreme Flexibilität bringt einen deutlichen Leistungseinbruch mit sich.

Horizontales Skalieren ist eine nicht offensichtliche Aufgabe, mit Ausnahme von Technologien, die speziell für diese Aufgabe entwickelt wurden und in der Regel die Einfachheit einer guten Skalierung in Kauf nehmen.
Wenn Sie mit Technologie A 100-mal so viele Anforderungen pro Computer verarbeiten können wie mit Technologie B, ist die Verwendung von Technologie A eine Überlegung wert, wenn Sie Grund zur Annahme haben, dass Sie Ihre Daten für einen Zeitraum von einem einzelnen Server aus bereitstellen können, der Ihnen das Hinzufügen von Daten ermöglicht Parallelisierung danach.
Im Jahr 2009 wurde stackoverflow noch von einem Webserver aus bedient . Dies ist natürlich keine Option mehr. Aber ich nehme an, es war gut, dass sie mit einer Technologie angefangen haben, mit der sich viele Benutzer auf einer einzelnen Instanz skalieren lassen, bevor sie sich um die Skalierung kümmern mussten.

Im Vergleich dazu ist RoR sehr langsam. Der Zeitaufwand für die Bearbeitung einfacher Anforderungen ist erheblich und daher ist die Bearbeitung vieler Clients problematisch (dies ist alles in Bezug auf schnellere Alternativen zu sehen).

Der vagen Orientierung halber hier einige Zahlen, die verschiedene andere für die Webentwicklung geeignete Sprachen mit Ruby vergleichen:

  • Gehen
  • Clojure
  • JavaScript V8 ( node.js )
  • JRuby (eine nicht zu vergessende Alternative - abhängig von Ihrem Problembereich kann JRuby eine bessere oder schlechtere Wahl sein, um etwas Geschwindigkeit aus einer Rails-App herauszuholen)
  • Scala
  • Java
  • C #

Beachten Sie, dass dies nicht bedeutet, dass Framework X für Java genau 200-mal schneller ist als RoR. Der in diesen Benchmarks gemessene Geschwindigkeitsunterschied hat jedoch einen wichtigen Einfluss auf die Gesamtleistung Ihrer App.


4
Diese Antwort spricht nur von "Geschwindigkeit" zur Laufzeit. Ruby (und Rails) sind auf Entwicklungsgeschwindigkeit optimiert.
Nicolai Reuschling

5
Dies ist kein guter Vergleich. Die meiste Zeit in einer Webanforderung wird für E / A aus der Datenbank verwendet. Die Verknüpfung mit CPU-intensiven Benchmarks ist irreführend.
Ryeguy

3
@pdr: Viele Problem Gezwitscher war sie Rubin verwendet haben für alles , auch ihre Back - End - Prozesse , die waren CPU - intensiv. Bereiche wie diese sind statisch typisierte Sprachen. Dafür benutzen sie jetzt Scala. Ich bin der festen Überzeugung, dass die Verwendung von RoR in Bezug auf die Entwicklungszeit viel schneller ist als C # oder Java. Ich würde es für die meisten Webanwendungen verwenden und dann C # oder Scala für alle CPU-intensiven Hintergrundjobs verwenden.
Ryeguy

3
+1 für gültige Punkte. Trotzdem können Sie viel tun, um Rails-Anwendungen zu optimieren. Rack bietet sich als erweiterbares System an, das viel Flexibilität beim Aufrufen von Inhalten bietet. Nicht zu vergessen, Ruby 1.9 ist schneller, JRuby ist schneller. Ich persönlich bin ein großer Fan von JRuby. Es ist ein wundervoller Gewinn, in die Kraft der JVM
einzumischen

2
@Nicolai Reuschling: Welchen Wert hat es, dass Ruby oder RoR "auf Entwicklungsgeschwindigkeit optimiert" werden? Können Sie überprüfbare , quantitative Daten bereitstellen , wie Ruby tatsächlich eine höhere Entwicklungsgeschwindigkeit als Alternativen bietet (z. B. Lift)? Alles andere ist nur ein nichtiger Anspruch. Diese Frage betraf auch die Nachteile von RoR . Eine hohe Entwicklungsgeschwindigkeit ist ein Vorteil und daher von dieser Frage ausgeschlossen. Eine schlechte Laufzeitleistung liegt im Rahmen dieser Frage, da dies ein Nachteil ist.
back2dos

3

Rails hat ein schwerwiegendes Leistungsproblem: Jede Anfrage befindet sich in der Warteschlange hinter der derzeit aktiven, anstatt sie wie die meisten Frameworks zu verteilen oder zuzulassen, dass blockierende Ereignisse andere Anfragen freigeben, wie dies bei Node.js und Twister der Fall ist. Das bedeutet, Sie müssen Code eingeben, um die Antwortzeiten zu verkürzen. In den meisten Fällen ist dies jedoch recht einfach.

Ich denke, das ist sehr falsch. Sie können Rails im Multithread-Modus ausführen. Wenn Sie im Multithread-Modus arbeiten, sollten Sie nur E / A-Bibliotheken verwenden, die die GIL-Datei freigeben (z. B. 'mysql2' gem), da sie sonst irgendwie sinnlos wird.

Wenn Sie jRuby verwenden, können Sie einfach einen Single-Rails-Prozess im Multithread-Modus ausführen und die gesamte verfügbare CPU-Leistung nutzen. Wenn Sie sich jedoch in MRT (Ruby 1.8.x oder 1.9.x) befinden, müssen Sie mehrere Prozesse ausführen, um die CPUs voll auszunutzen, was auch bei node.js der Fall ist.


Hier eine Klärungsfrage: Gibt es eine einfache Möglichkeit, herauszufinden, welche IO-Bibliotheken die GIL freigeben?
Matty

Ich denke , der beste Weg , um das herauszufinden Benchmark ist es gist.github.com/35d4769d8c8c0dfafc56
Pratik Naik


Gut zu hören von einem der Core-Entwickler! Diese Informationen sind in keiner Dokumentation aufgeführt, oder? Es ist ein wenig mühsam (obwohl eine interessante Aktivität), Bibliotheken zu testen, um dies herauszufinden.
Matty

3
  • Rails hat viele Feinheiten, die die Komplexität vor Ihnen verbergen. (ActiveRecord-Verknüpfungen, der gesamte Validierungs- / Speicherlebenszyklus, die Interpretation von Anforderungsdaten basierend auf bereitgestellten Headern) Wenn Sie gerade erst anfangen, ist dies fantastisch. Wenn Sie wachsen, werden Sie feststellen, dass Sie beginnen, Ihre App an die Art und Weise anzupassen, wie Sie mit den Dingen umgehen. Manchmal ist dies gut, manchmal ist es harmlos, und manchmal widerspricht es tatsächlich der Intuition, die Sie zu tun versuchen. Nicht alle Datenbanktabellen sollten als Objekte modelliert werden. Möglicherweise muss ein Validierungsschritt an einer anderen Stelle durchgeführt werden. Viele Rails-Programmierer meiden es, das Framework nicht zu bekämpfen (was normalerweise sinnvoll ist), aber der langfristige Effekt davon liegt bei Ihnen wird die Gewohnheiten von Rails an Orte mitnehmen, an denen sie nicht unbedingt erforderlich sind.

  • Die Community hat die Angewohnheit, Software zu schreiben, die als "Magie" bezeichnet wird - Libs zwischenspeichern, die auf magische Weise funktionieren! Evented I / O, das Sie magisch schneller macht! Magie Magie! In der Regel wird hier eine sehr attraktive API für eine fehlende technische Lösung bereitgestellt, und Sie werden von den sehr hübschen Beispielen getäuscht, dass das Ding das tut, was Sie beabsichtigen, und erst später feststellen, dass es eine unvollständige Lösung abdeckt. Der Zyklus ist ziemlich konstant, und Sie lernen, damit zu rollen, aber Sie sollten sich auf jeden Fall mit der Idee vertraut machen, sehr viel Code zu lesen, von dem Sie abhängen (eine gute Sache!). Rails Community Magic-Lösungen sind bei weitem nicht so magisch, wie es die README-Datei vermuten lässt.

  • Fazit: Je öfter Sie Rails verwenden, desto mehr sollten Sie dessen Quelle lesen. Je besser Sie die internen Rahmenbedingungen verstehen, desto glücklicher werden Sie langfristig sein. Nicht wirklich Rails-spezifisch, aber ich erzähle Ihnen nur aus Erfahrung hier. Methodennamen versprechen manchmal etwas, das Sie nicht wirklich bekommen.

  • Frachtkultismus ist ein Problem mit Rails, aber das trifft wahrscheinlich auf alle Framework / Lang-Communities zu. Es scheint (für mich) in Rails ausgeprägter zu sein und verleiht dem Rails-Code daher tendenziell einen seltsamen generativen Look. Wenn Sie an verschiedenen Rails-Projekten arbeiten, werden Sie bestimmte Tendenzen bemerken, die tendenziell den Zeitraum verraten, in dem sie erstellt wurden . Wie Sie aus dieser Aussage ersehen können, tendiert die Community dazu, neue Lösungen schnell zu übernehmen und alte zu verwerfen. Sie sollten sich wirklich über Ihre Ruby-Nachrichten auf dem Laufenden halten, nur um einen Teil des Codes zu verstehen, den Sie täglich erleben werden.

  • Generell denke ich, dass das Problem der Datengleichzeitigkeit von der Community in der Regel nicht gut angesprochen wird. Wenn Sie eine App erweitern und den Punkt erreichen, an dem Sie Daten speichern, physisch entfernte Änderungen rückgängig machen und den Zugriff auf Daten sperren müssen, werden die Lösungen ein bisschen mehr Handarbeit, wodurch einige der gut aussehenden Rails-Dinge, die Sie tun, mit den technischen Notwendigkeiten der Genauigkeit durcheinander gebracht werden. Rails löst nicht jedes Problem, das Sie mit einer Web-App haben, und obwohl die Macher diese Botschaft mit Sicherheit nicht predigen, ist es leicht zu glauben, dass sie impliziert ist.


2

Je nachdem, wie Sie es sehen, kann die Geschwindigkeit, mit der sich Rails ändert, ein Nachteil für Sie sein oder auch nicht. Die Dinge ändern sich von Jahr zu Jahr ein wenig radikal.

Wenn Sie sich in der aktiven Entwicklung befinden, sind Sie jedoch immer am Puls der Zeit.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.