En tant que développeur, je travaille sur les applications Ruby on Rails depuis la version 0.8 et j'ai vécu le battage médiatique et la myriade de RubyGems apparues au cours des années suivantes.
Comme toute communauté de développement de logiciels qui arrive à maturité, bon nombre de ces bibliothèques n'ont pas été largement adoptées et personne ne les soutient aujourd'hui, tandis que d'autres ont vécu pour devenir la perle de facto dédiée à un usage spécifique.
Dans certains cas, nous pouvons toujours opter pour l'une ou l'autre gemme, mais il existe des champions pour la plupart des fonctionnalités.
L'image ci-dessous montre comment la communauté a contribué avec de nouvelles bibliothèques et de nouvelles idées au cours des 10 dernières années.
Nous pouvons constater la croissance initiale, le pic en 2015 et le déclin (c'est-à-dire la maturité ?) jusqu'à aujourd'hui. Je pense que 2018 sera très similaire à 2009 et, si la tendance se poursuit, le nombre de nouvelles pierres précieuses diminuera également dans les années à venir, jusqu'à ce qu'il se stabilise.
De nombreuses questions peuvent être soulevées à ce sujet. Rails a-t-il atteint son plein potentiel en 2015 ? L'adoption de la plateforme est-elle en déclin ? Ou est-ce un signe de maturité et Rails est désormais prêt pour une adoption massive par les entreprises ?
Je ne pense pas que nous puissions parvenir à une conclusion objective avec ces seules données. Au lieu de cela, J'aimerais suivre une approche différente et me concentrer sur quelque chose qui pourrait avoir un impact important sur le travail que nous faisons aujourd'hui..
Nous pouvons dire qu'à mesure que les chiffres diminuent, il est difficile de trouver quelque chose de nouveau qui puisse avoir un impact positif sur le travail que nous faisons aujourd'hui. Mais laisse-moi te prouver que tu as tort.
Si vous avez déjà travaillé avec Ruby on Rails, vous avez probablement utilisé sera paginé ou Kaminari pour paginer les pages d'index de votre application. Si vous utilisez Rails pour la première fois, vous serez bientôt à la recherche d'un joyau de pagination.
Récolte est une nouvelle bibliothèque de pagination pour Ruby on Rails. Il a été développé dans un souci de performance, sans oublier sa facilité d'utilisation sur une application Ruby on Rails nouvelle ou existante.
Je sais ce que tu penses :
«Super, un autre joyau de pagination est exactement ce dont nous avons besoin... non !«.
Je suis d'accord avec toi là-dessus. Je ne pense pas que la fragmentation soit une bonne chose pour l'open source. De plus, certaines des améliorations apportées par cette gemme ont été proposées pour être implémentées à Kaminari, mais ont été rejetées, probablement parce que les améliorations nécessiteraient de nombreuses modifications au cœur de la gemme.
Je crois fermement que nous devons parfois prendre du recul et nous demander si ce qui existe est vraiment le mieux que nous puissions faire.... et en ce qui concerne la pagination, ce n'est pas le cas. Laisse-moi te montrer pourquoi.
Je pense que l'image va de soi.
Si votre application dessert des centaines ou des milliers d'utilisateurs simultanément, il est facile de deviner l'impact d'une fonctionnalité aussi simple sur vos ressources. Un test de 20 pages montre une forte augmentation de la mémoire dans Kaminari, alors que will_paginate fonctionne bien. Mais Payy peut faire mieux, et encore une fois, considérez l'impact que cela a lorsque vous essayez de servir des milliers d'utilisateurs.
Examinons de plus près, en comparant cette fois l'empreinte mémoire de chaque gemme :
Pagy utilise beaucoup moins de mémoire que Kaminari pour le même travail. Et oui, will_paginate utilise moins de mémoire que Kaminari, mais c'est quand même 7 fois plus que Pagy. Et veuillez noter que la dernière version de will_paginate date d'il y a presque un an, le dépôt git a quelques dizaines de pull requests en attente et le dernier commit remonte à juillet 2017.
Si je devais démarrer un nouveau projet, je ne considérerais pas celui-ci comme une option.
À ce stade, vous devriez vous demander :
«Ok, je suis accro. Comment est-ce possible ? Pourquoi l'empreinte mémoire de Pagy est-elle si faible par rapport aux autres options ?«.
Je suis content que tu l'aies demandé. Laisse-moi te montrer ça.
Ouaip. La première fois que je l'ai vu, je me suis aussi demandé :
«Pourquoi diable Kaminari crée-t-il plus de 6 000 objets ?«
Et oui, will_paginate est mieux, mais 3 000 objets pour paginer 20 pages, c'est le moins qu'on puisse dire. Payy le fait avec moins de 400...
Qu'y a-t-il de si différent à Pagy ? Laisse-moi te dire.
Un avantage collatéral énorme découlant des faits ci-dessus est que le code est vraiment facile à comprendre.
J'ai commencé à développer des applications Rails à l'aide de will_paginate, car c'était le meilleur outil pour ce travail à l'époque. J'ai ensuite sauté dans le wagon Kaminari, quelques mois après son lancement (malheureusement, il y a si longtemps que je ne me souviens pas en détail pourquoi). J'utilise Kaminari jusqu'à quelques semaines après le lancement de Pagy.
Ce qui m'a vraiment surpris lorsque j'ai découvert Pagy pour la première fois, c'est que je suis passé de will_paginate à Kaminari sans tenir compte des performances, alors que ce dernier est beaucoup plus lent que le premier. Maintenant que je suis au courant, je suis inquiet.
Je me demande combien de joyaux que nous utilisons nuisent réellement aux performances des applications que nous concevons et proposons.
Passer de will_paginate ou Kaminari à Pagy est très simple et ne nécessite que quelques lignes de code. Je te le promets mon prochain article sera un guide pratique si les gens s'intéressent suffisamment à ce sujet.
À titre d'avertissement, les images et les performances utilisées ci-dessus sont issues de tests de référence effectués par l'auteur de Pagy. Le code source peut être trouvé ici. L'image concernant l'adoption de RubyGem a été construite à partir des données de RubyGems.
À Imaginary Cloud nous travaillons avec un large éventail de technologies, y compris Ruby on Rails. Si vous avez besoin d'aide avec cette technologie ou des technologies similaires dans le cadre de votre projet de développement logiciel, nous avons une équipe d'experts qui vous attend ! Envoyez-nous un message ici!
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
