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.

Mer läsning

Wikipedia [3] har en del information, officiell API-beskrivning finns på [4] och installation finns på [5]

Referenser

[1] http://www.infoq.com/articles/Rails-Performance

[2] http://railsbench.rubyforge.org/

[3] http://en.wikipedia.org/wiki/Ruby_on_Rails

[4] http://api.rubyonrails.org/

[5] http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html

New side project - Ajax CV

I've decided on creating a new small side project, which should work well with my job search while hopefully also teaching me something new. A simplified description is that the site should show my CV accompanied by a calendar with the usual year, month, day interface selection. I'll also decide of information should be saved in a database, or an xml file (I'd usually just make it in mysql, but I I'd like to improve my understanding of xml).

To refresh my memory of Ajax, I'll start by going through the developerWorks 'Mastering AJAX' series, occasionally sidetracked by tutorials on for example drag-and-drop interfaces and form accessibility with unobtrusive javascript. Using this, entries in the calendar will be easy to move from different days or times, and both time and date as well as different types of entries (of course depending on labels) can be easily searched. If anything is unclear in a CV then, this calendar should be simple to search for example to find the projects on certain dates, or the length in time of certain projects.

I'll be updating here, while working on the project, and can hopefully give more tips related to this type of development :-)

Meanwhile, I am of course continuing the development of 'Pho2Model' - which I'm also trying to think of a new name for (there's a similar application with a very similar name). I'm almost done implementing a solution which should make the triangulation much more robust. If this doesn't work well enough, I have limited time to implement a method I have seen in several similar applications, meaning there will be three tested methods. At least I know which conclusions to draw from each part already, even though the testing is far from done (I'm 95% certain I won't be proven wrong by further testing).