Eräs Ruby on Railsin ja muiden samaa filosofiaa noudattavien ohjelmointiympäristöjen perusperiaatteita on "Convention over Configuration". Tämän voisi suomentaa vaikkapa muotoon "Käytäntö ennen konfiguraatiota".

Mitä enemmän olen itse ohjelmoinut Railsilla, sitä selkeämmin tämän filosofian opetus on alkanut iskostua päähän. Rails toimii sitä tehokkaammin, mitä paremmin omaksuu kyseisen ekosysteemin olemassaolevat käytännöt ja noudattaa niitä.

Peruskäytännöt ovat tietenkin itsestäänselviä. MVC-sovelluksen kontrollerit menevät controllers-hakemistoon, näkymät menevät views-hakemistoon, tietomallit models-hakemistoon ja niin edelleen. Jokainen sovellusta myöhemmin tarkasteleva koodaaja ymmärtää heti, missä mikäkin sijaitsee.

Seuraava, hieman haastavampi taso on URL-mäppäysten määrittely. Tämä on muuttunut radikaalisti Ruby on Railsin alkuajoista. Vanhana käytäntönä oli noudattaa URL-rakennetta "/:controller/:action/:id", esimerkiksi "/images/show/123". Sittemmin otettiin käyttöön REST-maailmasta tutumpi rakenne "/images/123", jossa URLin sijaan HTTP-metodi määrittelee actionin.

Uusi tapa edellyttää, että reitityksessä määritellään jokainen resurssi yhdellä rivillä tähän tapaan:

resources :articles
resources :images

Tässä yhteydessä Rails tekee myös oletuksen, että ArticlesController ja ImagesController sisältävät tietyn nimiset metodit: index, show, new, edit, create, update ja destroy. Kuinka ollakaan, "rails generate scaffold" -komennon automaattisesti luomat kontrollerit toteuttavat juurikin nämä metodit. Näin ollen käytäntöä noudattaessaan ohjelmoijan tarvitsee vain lisätä kontrollereihin pientä lisälogiikkaa, jos halutaan esimerkiksi tarkistaa sisäänkirjautuneen käyttäjän käyttöoikeuksia tai muuta vastaavaa.

Joskus käytäntöihin sitoutuminen on huonokin asia. Tämän huomasin käytännössä, kun yritin muuttaa olemassaolevan Rails-sovelluksen käyttämään MongoDB:tä. Lukemattomat Gem-paketit olettavat, että sovelluksen tietomalli on täysin ActiveRecord-pohjainen (eli taustalla on SQL-tietokanta). Esimerkiksi Paperclip, joka lisää tietomalleihin tiedostoliitetuen, tai Authlogic, joka automatisoi sisäänkirjautumista, eivät toimi kovin hyvin MongoDB:n kanssa. Ne saattaa saada toimimaan tarpeeksi virittelemällä, mutta käytäntöjen ideana on juuri se, että virittelyä ei tarvita vaan kaikki vain toimii saman tien.

Tehokkaassa Rails-kehityksessä näyttääkin olevan avainasemassa se, että seuraa Gem-pakettien kehitystä ja osaa tunnistaa, mitkä ovat tällä hetkellä yleisesti hyväksyttyjä käytäntöjä. Jos esimerkiksi MongoDB kerää lisää suosiota, yhä useammat Gemit alkavat tukea sitä ja jossain vaiheessa se voi jopa korvata MySQL:n, Postgresin ja SQLiten "oletustietokantana". Tähän näyttää kuitenkin menevän vielä aikaa.

PS. Henkilökohtaisesti olen kehittänyt Ruby on Railsilla ehkä kymmenkunta erilaista pientä web-sovellusta, joten olen edelleen vasta tutustumis- ja oppimisvaiheessa. Heroku on aika mainio tapa pystyttää nopeasti pieniä, kokeellisia sovelluksia omaan käyttöön, ilmaiseksi.