Som udvikler har jeg arbejdet med Ruby on Rails-applikationer siden version 0.8, og jeg har levet igennem hypen og det utal af RubyGems, der dukkede op i de følgende år.
Som med ethvert softwareudviklingssamfund, der modnes, havde mange af disse biblioteker ikke betydelig adoption, og ingen støtter dem i dag, mens andre har levet for at blive de facto-perlen til en bestemt brug.
I nogle tilfælde kan vi stadig vælge en eller anden perle, men der er mestre for de fleste funktioner.
Billedet nedenfor viser hvordan samfundet bidrog med nye biblioteker og ideer i de sidste 10 år.
Vi kan se den indledende vækst, toppen i 2015 og faldet (dvs. modenhed?) indtil i dag. Jeg formoder, at 2018 vil være meget lig 2009, og hvis tendensen fortsætter, Antallet af nye ædelstene vil også falde i de kommende år, indtil det stabiliserer sig.
Der kan rejses mange spørgsmål omkring dette. Opnåede Rails sit fulde potentiale i 2015? Er vedtagelsen af platformen i tilbagegang? Eller er dette et tegn på modenhed, og Rails er nu klar til masseadoption af virksomheder?
Jeg tror ikke, vi objektivt kan nå nogen konklusion med disse data alene. I stedet, Jeg vil gerne følge en anden tilgang og fokusere på noget, der kan have stor indflydelse på det arbejde, vi udfører i dag.
Vi kan sige, at når antallet falder, er det svært at finde noget nyt, der vil have en god indflydelse på det arbejde, vi udfører i dag. Men lad mig bevise, at du tager fejl.
Hvis du tidligere har arbejdet med Ruby on Rails, har du sandsynligvis brugt vil paginere eller Kaminari at paginere indekssiderne i din ansøgning. Hvis du er ny på Rails, vil du snart være på udkig efter en pagineringsperle.
Pagy er et nyt pagineringsbibliotek til Ruby on Rails. Det blev udviklet med ydeevne i tankerne, uden at se bort fra at være let at bruge på en ny eller eksisterende Ruby on Rails-applikation.
Jeg ved, hvad du tænker:
„Fantastisk, en anden pagineringsperle er præcis, hvad vi har brug for... ikke!„.
Jeg er med dig om dette. Jeg tror ikke, at fragmentering er en god ting for open source. Plus, nogle af de forbedringer, som denne perle bringer, blev foreslået at blive implementeret i Kaminari, men blev afvist, sandsynligvis fordi forbedringerne ville kræve mange ændringer i perlens kerne.
Jeg er overbevist om, at nogle gange har vi brug for at tage et skridt tilbage og stille spørgsmålstegn ved, om det, der er derude, virkelig er det bedste, vi kan gøre... og hvad angår paginering, er det ikke. Lad mig vise dig hvorfor.
Jeg tror, at billedet er selvforklarende.
Hvis din applikation betjener hundreder eller tusinder af brugere samtidigt, er det let at gætte, hvilken indflydelse en sådan simpel funktion har på dine ressourcer. En test med 20 sider viser en stor hukommelsesforøgelse i Kaminari, mens will_paginate klarer sig ok. Men Pagy kan gøre det bedre, og igen, overvej den indvirkning, dette har, når du prøver at betjene tusinder af brugere.
Lad os tage et dybere kig, denne gang sammenligne hukommelsesfodaftrykket for hver perle:
Pagy bruger langt mindre hukommelse end Kaminari til det samme job. Og ja, will_paginate bruger mindre hukommelse end Kaminari, men det er stadig 7 gange mere end Pagy. Og vær opmærksom på, at den sidste udgivelse af will_paginate var for næsten et år siden, git repo har et par snesevis af pull-anmodninger, der venter og den sidste forpligtelse går tilbage til juli 2017.
Hvis jeg skulle starte et nyt projekt, ville jeg ikke betragte dette som en mulighed.
På dette tidspunkt bør du spørge:
„Okay, jeg er tiltrukket. Hvordan er dette muligt? Hvorfor er Pagys hukommelsesfodaftryk så lavt sammenlignet med de andre muligheder?„.
Jeg er glad for, at du spurgte. Lad mig vise dig det her.
Jep. Første gang jeg så det, spekulerede jeg også på:
„Hvorfor fanden skaber Kaminari mere end 6k objekter?„
Og ja, will_paginate er bedre, men 3k objekter til paginering af 20 sider virker mildt sagt overdrevne. Pagy gør det med mindre end 400...
Hvad er så anderledes i Pagy? Lad mig fortælle dig det.
En stor sikkerhedsfordel, der kommer fra ovenstående fakta, er, at koden er virkelig let at forstå.
Jeg er begyndt at udvikle Rails-apps ved hjælp af will_paginate, da det var det bedste værktøj til jobbet på det tidspunkt. Jeg sprang derefter til Kaminari-vognen et par måneder efter, at den blev lanceret (desværre var det så længe siden, at jeg ikke husker detaljeret hvorfor). Jeg har brugt Kaminari indtil et par uger efter, at Pagy blev lanceret.
Hvad der virkelig overraskede mig, da jeg først blev opmærksom på Pagy, var, at jeg flyttede fra will_paginate til Kaminari uden at tage højde for ydeevnen, mens sidstnævnte er meget langsommere end førstnævnte. Og nu hvor jeg er klar over det, er jeg bekymret.
Jeg spekulerer på, hvor mange perler vi har brugt, der virkelig skader ydeevnen for de apps, vi designer og leverer.
At flytte fra will_paginate eller Kaminari til Pagy er virkelig let, og kræver kun et par linjer kode. Det lover jeg mit næste indlæg vil være en vejledning, hvis folk viser tilstrækkelig interesse for dette emne.
Som en ansvarsfraskrivelse er billederne og ydeevnen, der bruges ovenfor, fra benchmark-tests udført af Pagys forfatter. Kildekoden kan findes her. Billedet vedrørende RubyGem-adoption blev bygget ved hjælp af data fra RubyGems.
Ved Imaginær sky vi arbejder med en bred teknisk stak, inklusive Ruby on Rails. Hvis du har brug for hjælp til denne teknologi eller lignende i dit softwareudviklingsprojekt, har vi et team af eksperter, der venter på dig! Send os en linje her!
Fandt du denne artikel nyttig? Du kan måske også lide disse!
CEO @ Imaginary Cloud og medforfatter af bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i denne rækkefølge).
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
