Computer Vision & CG with MDX: New side track - Ruby on Rails (Swedish report)

Well, it seems like I'm finding new tracks all the time at the moment. Today, I was asked to make a report about Ruby on Rails to accompany my CV to send to a company who needs a project manager/developer/tester. Since I'm a nice guy, I decided to share the report here (it was very quickly made, so don't take this post as an absolute truth). The report is in Swedish, and I haven't found any translation for it. If you don't know Swedish, I can recommend the links at the bottom, which are in English (and probably some of the easiest to find) and places where I found the information.

Ruby on Rails (RoR)

RoR har som filosofi att använda så lite kod som möjligt i sina applikationer, och att definitioner enbart ska behöva göras en gång (”Don’t repeat yourself” eller DRY). Detta gör i slutändan att applikationer som utvecklas med Ruby behöver mindre kod, om man följer konventionerna. En sida sammanfattar Ruby som en kombination av Smalltalk’s konceptuella elegans, Pythons enkelhet i användning och inlärning och Perls praktiska nyttovärde. Det är mycket vanligt att använda Agile programming vid utveckling i Ruby on Rails.

Referenser till webbsidor finns på slutet, för mer läsning – då texten refererar till en av dessa görs det med en siffra mellan klamrar (t.ex. [2]).

Teknisk sammanfattning

RoR använder sig av metaprogrammering, vilket ger möjligheten att skapa ett domänspecifikt språk, vilket många programmerare finner mer produktivt än traditionella frameworks.

Fördelar

En given fördel är att man kan få önskade resultat med minimal mängd kod. Enligt vissa källor är RoR cirka tio gånger snabbare än Java vid utveckling till webben, utan sänkning av kvalitet.
Språket är väldigt enkelt att lära sig, och det finns ett antal böcker i ämnet. På Amazon finns minst två böcker i ämnet som ges högsta betyg av reviewers.

Nackdelar

Alla system har sina för- och nackdelar, så även RoR. Ofta när väldigt mycket funktionalitet ska uppnås med väldigt mycket kod så ger det försämringar på andra områden. Motsatsen skulle man kunna säga är C/C++, där mängder av kod måste skrivas även för relativt enkla funktioner, men då ger ett snabbare och mer effektivt slutresultat.

RoR har några prestandaproblem som verkar följa med oavsett typ av applikation. En rapport [1] inkluderar vanliga fel och problem i testade applikationer med RoR:

Val av långsam session container.
Även saker som borde kunna utföras enbart vid applikationens start följer med på en ”per request” basis.
Repetitioner av identiska beräkningar under request processing.
Läser för ofta och för mycket från databasen.
Förlitar sig för mycket på ineffektiva hjälpmetoder.

Vissa av dessa går att arbeta runt, medan andra antagligen kommer att förbättras till nästa release av RoR. Något som gör RoR långsamt är Route igenkänning och Route generering. Hämtning av ett flertal ActiveRecord-objekt är ganska långsamt, pga hur dessa objekt representeras i RoR (se i nästa sektion, ”Tips för optimering”).

Ännu en nackdel är att den officiella dokumentationen är bristfällig, och det verkar finnas svårigheter att hitta bland dokumentationen – men å andra sidan har ett antal böcker kommit ut den senaste tiden, vilket ofta kan uppväga brister från officiella kanaler.

Tips för optimering

RoR kommer med flera valmöjligheter, och det rekommenderas att man testar prestanda på applikationer med olika inställningar – detta kan göras med Railsbench [2]. Några tips för optimering:

RoR innehåller flera olika session containers, där de flesta verkar använda PStore (sparar session information i separat fil) eller ActiveRecordStore (sparar i databas). Alternativ som tycks vara bättre är istället SQLSessionStore och MemCacheStore (se mer i [1]).
Beräkningar i cache – om man behöver utföra samma beräkningar flera gånger under samma request så är det mer effektivt att lägga datan i cache (se [1, Caching Computations])
Lägg beräkningar vid applikationens start som bara behöver utföras en gång – ett ganska enkelt tips, men flera programmerare låter vissa beräkningar utföras vid varje request som bara behöver utföras då applikationen startas.
Optimera queries – det finns ett antal tekniker för att optimera databas-queries, så att hämtningar från databas delas upp så enbart det som behövs hämtas (se [1, Optimizing Queries])
Undvik långsamma helpers – ett flertal helpers i RoR är relativt långsamma, vilket gör det viktigt att optimera användningen av dessa (se [1, Avoiding Slow Helpers])

Slutsatser

Ruby on Rails ser ut att vara ett bra verktyg, om man vill använda så lite kod som möjligt för att utföra så mycket som möjligt. Det är dock viktigt att man undviker de värsta fallgroparna, och testar applikationer för att kunna optimera prestanda. Nackdelarna som räknats upp är mestadels vanliga fallgropar, och kan oftast undvikas genom att lära sig rätt metoder från början. Fördelarna överväger därför, med snabb och effektiv programmering.