Als Entwickler arbeite ich seit Version 0.8 mit Ruby on Rails-Anwendungen und habe den Hype und die unzähligen RubyGems erlebt, die in den folgenden Jahren auftauchten.
Wie bei jeder Softwareentwickler-Community, die reift, hatten viele dieser Bibliotheken keine nennenswerte Akzeptanz und niemand unterstützt sie heute, während andere zu einem echten Juwel für einen bestimmten Zweck geworden sind.
In einigen Fällen können wir uns immer noch für den einen oder anderen Edelstein entscheiden, aber für die meisten Funktionen gibt es Champions.
Das Bild unten zeigt wie die Community in den letzten 10 Jahren mit neuen Bibliotheken und Ideen dazu beigetragen hat.
Wir können das anfängliche Wachstum, den Höhepunkt im Jahr 2015 und den Rückgang (d. h. die Reife?) bis heute. Ich vermute, dass 2018 2009 sehr ähnlich sein wird, und wenn sich der Trend fortsetzt Die Anzahl der neuen Edelsteine wird in den kommenden Jahren ebenfalls abnehmen, bis sie sich stabilisiert.
In diesem Zusammenhang können viele Fragen aufgeworfen werden. Hat Rails 2015 sein volles Potenzial ausgeschöpft? Ist die Akzeptanz der Plattform rückläufig? Oder ist das ein Zeichen von Reife und Rails ist jetzt bereit für die Masseneinführung in Unternehmen?
Ich glaube nicht, dass wir allein mit diesen Daten objektiv zu einer Schlussfolgerung kommen können. Stattdessen Ich möchte einen anderen Ansatz verfolgen und mich auf etwas konzentrieren, das einen großen Einfluss auf unsere heutige Arbeit haben könnte..
Wir können sagen, dass es angesichts sinkender Zahlen schwierig ist, etwas Neues zu finden, das sich positiv auf die Arbeit auswirkt, die wir heute leisten. Aber lass mich beweisen, dass du falsch liegst.
Wenn Sie in der Vergangenheit mit Ruby on Rails gearbeitet haben, dann haben Sie wahrscheinlich will_paginieren oder Kaminari um die Indexseiten Ihrer Anwendung zu paginieren. Wenn Sie Rails noch nicht kennen, werden Sie schon bald nach einem Juwel zur Paginierung suchen.
Bezahlen ist eine neue Paginierungsbibliothek für Ruby on Rails. Es wurde mit Blick auf Leistung entwickelt, ohne die Benutzerfreundlichkeit in einer neuen oder bestehenden Ruby on Rails-Anwendung zu vernachlässigen.
Ich weiß, was du denkst:
„Toll, ein weiteres Paginierungsjuwel ist genau das, was wir brauchen... nicht!„.
Ich stimme dir dabei zu. Ich denke nicht, dass Fragmentierung eine gute Sache für Open Source ist. Außerdem wurde vorgeschlagen, einige der Verbesserungen, die dieser Edelstein mit sich bringt, in Kaminari umzusetzen, wurden aber abgelehnt, wahrscheinlich weil die Verbesserungen viele Änderungen am Kern des Edelsteins erfordern würden.
Ich bin fest davon überzeugt, dass manchmal müssen wir einen Schritt zurücktreten und uns fragen, ob das, was da draußen ist, wirklich das Beste ist, was wir tun können... und was die Paginierung angeht, ist es das nicht. Lass mich dir zeigen warum.
Ich glaube, dass das Bild selbsterklärend ist.
Wenn Ihre Anwendung Hunderte oder Tausende von Benutzern gleichzeitig bedient, ist es leicht zu erraten, welche Auswirkungen eine so einfache Funktion auf Ihre Ressourcen hat. Ein Test mit 20 Seiten zeigt einen starken Speicherzuwachs in Kaminari, während will_paginate gut abschneidet. Aber Pagy kann es besser machen. Denken Sie auch hier an die Auswirkungen, die dies hat, wenn Sie versuchen, Tausende von Benutzern zu bedienen.
Schauen wir uns das genauer an und vergleichen dieses Mal den Speicherbedarf jedes Edelsteins:
Pagy verwendet für den gleichen Job weit weniger Speicher als Kaminari. Und ja, will_paginate benötigt weniger Speicher als Kaminari, aber es ist immer noch 7-mal mehr als Pagy. Und bitte bedenke, dass die letzte Veröffentlichung von will_paginate fast ein Jahr her ist, das Git-Repo hat ein paar Dutzend ausstehende Pull-Requests und der letzte Commit stammt aus dem Juli 2017.
Wenn ich ein neues Projekt starten müsste, würde ich dieses nicht als Option in Betracht ziehen.
Zu diesem Zeitpunkt sollten Sie sich fragen:
„Ok, ich bin süchtig. Wie ist das möglich? Warum ist der Speicherbedarf von Pagy im Vergleich zu den anderen Optionen so gering?„.
Ich freue mich, dass du gefragt hast. Lass mich dir das zeigen.
Jep. Als ich es das erste Mal sah, habe ich mich auch gefragt:
„Warum zur Hölle kreiert Kaminari mehr als 6.000 Objekte?„
Und ja, will_paginate ist besser, aber 3.000 Objekte, um 20 Seiten zu paginieren, scheinen gelinde gesagt übertrieben. Pagy macht das mit weniger als 400...
Was ist so anders an Pagy? Lass es mich dir sagen.
Ein großer Kollateralvorteil, der sich aus den oben genannten Fakten ergibt, ist, dass der Code wirklich leicht zu verstehen ist.
Ich habe angefangen, Rails-Apps mit will_paginate zu entwickeln, da es zu der Zeit das beste Tool für diesen Job war. Ich bin dann zum Kaminari-Wagen gesprungen, ein paar Monate nach seiner Markteinführung (leider ist es so lange her, dass ich mich nicht mehr genau erinnern kann, warum). Ich benutze Kaminari bis ein paar Wochen nach dem Start von Pagy.
Was mich wirklich überrascht hat, als ich zum ersten Mal auf Pagy aufmerksam wurde, war, dass ich von will_paginate zu Kaminari gewechselt bin, ohne die Leistung zu berücksichtigen, während letzteres viel langsamer ist als das erstere. Und jetzt, wo ich mir dessen bewusst bin, mache ich mir Sorgen.
Ich frage mich, wie viele Juwelen wir verwendet haben, die die Leistung der Apps, die wir entwerfen und bereitstellen, wirklich beeinträchtigt haben.
Der Wechsel von will_paginate oder Kaminari zu Pagy ist wirklich einfach und erfordert nur ein paar Codezeilen. Das verspreche ich Mein nächster Beitrag wird eine Anleitung sein, wenn die Leute genug Interesse an diesem Thema zeigen.
Als Haftungsausschluss gilt, dass die oben verwendeten Bilder und Leistungen aus Benchmark-Tests stammen, die vom Autor von Pagy durchgeführt wurden. Der Quellcode kann gefunden werden hier. Das Bild zur Einführung von RubyGem wurde anhand von Daten von RubyGems erstellt.
Bei Imaginary Cloud wir arbeiten mit einem breiten Tech-Stack, einschließlich Ruby on Rails. Wenn Sie in Ihrem Softwareentwicklungsprojekt Hilfe mit dieser oder ähnlichen Technologien benötigen, wartet ein Expertenteam auf Sie! Schreiben Sie uns eine Nachricht hier!
Fanden Sie diesen Artikel hilfreich? Diese könnten dir auch gefallen!
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
