Som utvecklare har jag arbetat med Ruby on Rails-applikationer sedan version 0.8 och jag har levt igenom hypen och den myriad av RubyGems som dök upp under de följande åren.
Som med alla mjukvaruutvecklingssamhällen som mognar, många av dessa bibliotek hade inte betydande adoption och ingen stöder dem idag, medan andra har levt för att bli de facto-pärlan för en specifik användning.
I vissa fall kan vi fortfarande välja en eller annan pärla, men det finns mästare för de flesta funktioner.
Bilden nedan visar hur samhället bidrog med nya bibliotek och idéer under de senaste 10 åren.
Vi kan se den initiala tillväxten, toppen 2015 och nedgången (dvs. mognad?) fram till idag. Jag misstänker att 2018 kommer att vara mycket lik 2009 och om trenden fortsätter, Antalet nya ädelstenar kommer också att minska under de kommande åren tills det stabiliseras.
Många frågor kan ställas kring detta. Uppnådde Rails sin fulla potential 2015? Är antagandet av plattformen på nedgång? Eller är detta ett tecken på mognad och Rails är nu redo för massupptagande av företag?
Jag tror inte att vi objektivt kan nå någon slutsats med enbart dessa uppgifter. Istället, Jag skulle vilja följa ett annat förhållningssätt och fokusera på något som kan ha stor inverkan på det arbete vi gör idag.
Vi kan säga att när siffrorna minskar är det svårt att hitta något nytt som kommer att ha en bra inverkan på det arbete vi gör idag. Men låt mig bevisa att du har fel.
Om du har arbetat med Ruby on Rails tidigare, då använde du förmodligen vilja_paginera eller Kaminari för att paginera indexsidorna för din ansökan. Om du är ny på Rails, du letar efter en pagineringspärla ganska snart.
Pagy är ett nytt pagineringsbibliotek för Ruby on Rails. Det utvecklades med prestanda i åtanke, utan att bortse från att det är lätt att använda på en ny eller befintlig Ruby on Rails-applikation.
Jag vet vad du tänker:
”Bra, en annan pagineringspärla är precis vad vi behöver... inte!”.
Jag är med dig på det här. Jag tror inte att fragmentering är bra för öppen källkod. Dessutom föreslogs några av de förbättringar som denna pärla medför implementeras i Kaminari, men avvisades, förmodligen för att förbättringarna skulle kräva många förändringar i pärlens kärna.
Jag är fast övertygad om att ibland behöver vi ta ett steg tillbaka och fråga om det som finns där ute verkligen är det bästa vi kan göra... och när det gäller paginering är det inte. Låt mig visa dig varför.
Jag tror att bilden är självförklarande.
Om din applikation betjänar hundratals eller tusentals användare samtidigt är det lätt att gissa vilken inverkan en så enkel funktion har på dina resurser. Ett test med 20 sidor visar en stor minnesökning i Kaminari, medan will_paginate klarar sig ok. Men Pagy kan göra bättre, och återigen, överväga vilken inverkan detta har när du försöker betjäna tusentals användare.
Låt oss ta en djupare titt, den här gången jämföra minnesfotavtrycket för varje pärla:
Pagy använder mycket mindre minne än Kaminari för samma jobb. Och ja, will_paginate använder mindre minne än Kaminari, men det är fortfarande 7x mer än Pagy. Och tänk på att den senaste utgåvan av will_paginate var för nästan ett år sedan, git repo har några dussintals pull-förfrågningar som väntar och det senaste åtagandet går tillbaka till juli 2017.
Om jag var tvungen att starta ett nytt projekt skulle jag inte betrakta det här som ett alternativ.
Vid den här tiden borde du fråga:
”Okej, jag är fast. Hur är detta möjligt? Varför är minnesavtrycket för Pagy så lågt jämfört med de andra alternativen?”.
Jag är glad att du frågade. Låt mig visa dig detta.
Japp. Första gången jag såg den undrade jag också:
”Varför i helvete skapar Kaminari mer än 6k objekt?”
Och ja, will_paginate är bättre, men 3k objekt att paginera 20 sidor verkar överdrivet, minst sagt. Pagy gör det med mindre än 400...
Vad är så annorlunda i Pagy? Låt mig berätta för dig.
En stor säkerhetsfördel som kommer från ovanstående fakta är att koden är riktigt lätt att förstå.
Jag har börjat utveckla Rails-appar med will_paginate, eftersom det var det bästa verktyget för jobbet vid den tiden. Jag hoppade sedan till Kaminari-vagnen, några månader efter att den lanserades (tyvärr var det så länge sedan att jag inte minns i detalj varför). Jag har använt Kaminari tills ett par veckor efter att Pagy lanserades.
Det som verkligen förvånade mig när jag först blev medveten om Pagy var att jag flyttade från will_paginate till Kaminari utan att ta hänsyn till prestanda, medan den senare är mycket långsammare än den förra. Och nu när jag är medveten är jag orolig.
Jag undrar hur många pärlor vi har använt som verkligen skadar prestandan för de appar som vi designar och levererar.
Att flytta från will_paginate eller Kaminari till Pagy är väldigt enkelt och kräver bara några rader kod. Jag lovar att mitt nästa inlägg kommer att vara en guide om människor visar tillräckligt intresse för detta ämne.
Som en ansvarsfriskrivning är bilderna och prestandan som används ovan från benchmarktester utförda av Pagys författare. Källkoden kan hittas här. Bilden angående RubyGems adoption byggdes med hjälp av data från RubyGems.
Vid Imaginärt moln vi arbetar med en bred teknisk stack, inklusive Ruby on Rails. Om du behöver hjälp med denna teknik eller liknande i ditt mjukvaruutvecklingsprojekt har vi ett team av experter som väntar på dig! Skicka oss en rad här!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
