Lappeenrannan teknillinen yliopisto
Teknistaloudellinen tiedekunta
Tietotekniikan koulutusohjelma
Opintojakson Ohjelmistotekniikan seminaari seminaarityö
Lauri Naukkarinen
RUBY ON RAILS WEB-SOVELLUSKEHITYKSESSÄ
Työn tarkastaja:
Lappeenranta, 18.4.2011
Professori Kari Smolander
TIIVISTELMÄ
Lappeenrannan teknillinen yliopisto
Teknistaloudellinen tiedekunta
Tietotekniikan koulutusohjelma
Lauri Naukkarinen
Ruby On Rails Web-sovelluskehityksessä
Seminaarityö
2011
25 sivua, 1 kuva, 3 taulukkoa
Työn tarkastaja: Professori Kari Smolander
Hakusanat: Ruby on Rails, Ruby, web-sovelluskehys, web-sovellus, webohjelmistokehitys
Keywords: Ruby on Rails, Ruby, web framework, web application, web development
Tämä työ esittelee Ruby On Rails -sovelluskehyksen. Kyseinen web-sovelluskehys
korostaa ja tavoittelee ketteryyttä, yksinkertaisuutta ja kehittäjäystävällisyyttä. Tämä työ
käsittelee ROR-kehyksen ominaisuudet, käytännöt ja ratkaisut sekä merkittävät
eroavaisuudet muihin sovelluskehyksiin verrattuna. Työ olettaa, että lukija ymmärtää
ohjelmistokehityksen ja web-maailman keskeiset teknologiat, standardit ja
käytännöt.
Työn lopputuloksena tunnistetaan ROR-kehyksen käytön syyt ja seuraukset sekä
suorituskyky-, skaalautuvuus- ja teknologiahaasteet. Työssä myös pohditaan RORkehyksen soveltuvuutta suurten ja laajojen web-sovellusten tarpeisiin. Johtopäätös on, että
ROR soveltuu erityisesti uusien, yksinkertaisten ja pienimuotoisten web-sovellusten
tuottamiseen. ROR sisältää lukuisia ominaisuuksia, jotka edistävät tällaisten sovellusten
vaivatonta ja nopeaa kehitystä.
ii
ABSTRACT
Lappeenranta University of Technology
Faculty of Technology Management
Degree Program in Information Technology
Lauri Naukkarinen
Ruby On Rails In Web-Application Development
Seminar report
2011
25 pages, 1 figure, 3 tables
Examiners: Professor Kari Smolander
Keywords: Ruby on Rails, Ruby, web framework, web application, web development
This report presents Ruby On Rails web application framework. ROR emphasizes and
aims for agility, simplicity, and developer-friendliness. The report covers ROR’s features,
conventions, and solutions as well as its notable differences to other application
frameworks. As a result the reasons for and consequences of using ROR will be recognized
and presented. The report assumes that the reader understands the key technologies,
standards, and conventions of software engineering and the web environment.
Performance, scalability and technology are recognized as challenges in ROR platform and
also ROR’s suitability for the development and running of large applications is discussed.
In conclusion, ROR is very suitable to developing new, simple, and small-scale webapplications. ROR includes many features that work towards making the development of
such applications effortless and fast.
iii
ALKUSANAT
Allekirjoittaneen eli Microsoft .NET FRAMEWORK (ja ASP.NET) -kehittäjän
näkökulmasta Ruby On Rails on epäilemättä tämän hetken kiinnostavin websovelluskehys. Vaikka ei tykkäisikään Ruby-koodista, niin moni asia kehyksessä on vain
tehty todella järkevästi ja toimivuus sekä käytettävyys on aivan huippuluokkaa pienten
sovellusten tarpeisiin. Tämän huomioiden, kenenkään ei pitäisi enää käyttää PHP-koodia,
missään, ikinä.
Työ on tehty Lappeenrannassa kahvikupin välittömässä läheisyydessä.
iv
SISÄLLYSLUETTELO
1
2
3
4
JOHDANTO ................................................................................................................. 3
1.1
Tausta ...................................................................................................................... 3
1.2
Tavoitteet ja rajaukset ............................................................................................. 4
1.3
Työn rakenne ........................................................................................................... 4
RUBY ON RAILS -SOVELLUSKEHYS ................................................................... 5
2.1
ROR ympäristönä .................................................................................................... 5
2.2
Perusperiaatteet ja ROR-näkökulma sovelluskehitykseen ...................................... 7
2.3
Arkkitehtuuri ja keskeiset komponentit .................................................................. 8
RUBY-OHJELMOINTIKIELI ................................................................................. 11
3.1
Ruby, PHP ja Java: erot ja lyhyt vertailu .............................................................. 12
3.2
Tapaus Twitter ja Rubyn suorituskyky ................................................................. 12
ROR-KEHYS JA KILPAILEVAT TUOTTEET VERTAILUSSA....................... 14
4.1
Ketterät Java-pohjaiset sovelluskehykset ja ROR................................................. 14
4.2
Ylläpidettävyys ja muut luonteenpiirteet: ROR, J2EE ja .NET ............................ 15
5
KESKUSTELU JA JOHTOPÄÄTÖKSET ............................................................. 18
6
YHTEENVETO .......................................................................................................... 19
LÄHTEET .......................................................................................................................... 20
1
LYHENNELUETTELO
Ajax
Asynchronous JavaScript and XML
API
Application Programming Interface
ASP.NET
Active Server Pages .NET
CRUD
Create-Read-Update-Delete
DLTK
Dynamic Languages ToolKit
DRY
Don't Repeat Yourself
HTML
HyperText Markup Language
HTTP
HyperText Transfer Protocol
IIS
Internet Information Services
J2EE
Java 2 Platform Enterprise Edition
JVM
Java Virtual Machine
MIT
Massachusetts Institute of Technology
MVC
Model-View-Controller
ORM
Object-Relational Mapping
PHP
PHP: Hypertext Preprocessor
REST
Representational State Transfer
ROR
Ruby On Rails
SOAP
Simple Object Access Protocol
SQL
Structured Query Language
WSDL
Web-service Description Language
XML
Extensible Markup Language
XML-RPC
XML Remote Procedure Call
2
1
JOHDANTO
Web-sovellusten tuottaminen eroaa muusta ohjelmistokehityksestä. Suurimpia eroja ovat
nopea kehitys- ja julkaisusykli, formaalin testauksen puute, asiakkaan vaatima jatkuva
muutos sekä nopea ympäristön ja teknologian muutostahti [1]. Näiden erojen seurauksena
myös vaatimukset ovat usein tuntemattomia tai puutteellisia, joten tarkan suunnittelun
sijaan kehitys tapahtuu iteratiivisesti sovellusta laajentamalla ja korjaamalla. Web-puolella
sovelluksia tuottavat tahot käyttävät
usein prototyyppipohjaista kehitystä sekä talon
sisäisiä käytäntöjä [2]. Kehitystyö ja tuotteen sisältö nähdään käyttäjälähtöisestä
näkökulmasta, jolloin korostuu käytettävyys, ulkoasu ja vuorovaikutuksen laatu ja
sulavuus eikä niinkään sovelluksen sisäisen logiikan tai toimintojen laatu.
Tässä ympäristössä kehittäjät ovat perinteisesti jakaantuneet
kahteen eri leiriin [3].
Ensimmäisessä leirissä web-kehitystä tehdään ketterästi yksinkertaisten menetelmien
avulla. Tavoitteena on julkaista verkkosivu nopeasti ja pienellä vaivalla. Teknologiavalinta
on usein PHP (PHP: HyperText Preprocessor). Samaan aikaan toisessa leirissä suositaan
vankkoja, selkeitä ja perusteellisia menetelmiä, jotka kuitenkin ensimmäisen leirin mielestä
ovat hitaita, työläitä ja tylsiä. Tämän leirin perinteiset teknologiavalinnat ovat usein
Microsoftin tai Oraclen (Java) tuotteita. Tässä leirissä arvostetaan suorituskykyä,
testattavuutta, todistettavuutta ja prosessilähtöisiä kehitysmenetelmiä. Kun kummankin
leirin parhaat puolet yhdistetään, niin ratkaisuna saadaan miellyttävä ja tuottava
menetelmä, jonka avulla voidaan luoda luotettavia, nopeita ja selkeitä web-sovelluksia.
Tätä tavoitetta varten David Heinemeier Hansson loi ROR-sovelluskehyksen (Ruby on
Rails).
1.1 Tausta
ROR julkaistiin vuonna 2004 ja se noudattaa avoimen lähdekoodin MIT-lisenssiä. ROR
syntyi kun Basecamp-projektinhallintasovellukselle räätälöity Ruby-ohjelmointikieleen
pohjautuva
sovelluskehys
ulkoistettiin
omaksi
avoimen
lähdekoodin
web-
sovelluskehykseksi. Hansson laittoi omien sanojensa mukaan Ruby-kielen raiteille ja antoi
sille suunnan sekä tarkoituksen: luoda kehittäjäystävällisiä web-sovelluksia. Websovelluskehyksen yleisenä tehtävänä on edistää ja mahdollistaa web-sovellusten kehitys
3
tarjoamalla valmiit raamit sekä mahdollisimman kattava joukko valmiita ratkaisuja eri osaalueiden toteuttamiseen. Jokainen web-sovelluskehys tarjoaa jonkin kokonaisvaltaisen
arkkitehtuuriratkaisun sekä kokoelman valmiita komponentteja, jotka voivat sisältää mm.
tietokantarajapintatoteutuksen,
malliluokkia
ja
-näkymiä
(templates)
ja
istunnon
hallintatyökalut. Tavoitteena on edistää kehitystyön tuottavuutta ja maksimoida koodin
uudelleenkäytettävyys. ROR on yksi tällainen web-sovelluskehys. [3,4]
1.2 Tavoitteet ja rajaukset
Tämän työn tavoitteena on luoda yleiskatsaus Ruby On Rails sovelluskehitykseen. Työ
keskittyy käsittelemään ROR-kehyksen ominaisuuksia, käytäntöjä ja ratkaisuja sekä
erityisesti eroja muihin sovelluskehyksiin verrattuna. Työ esittelee lyhyesti myös Rubyohjelmointikielen peruspiirteet. Lopputuloksena työ luo kokonaisvaltaisen kuvan RORkehyksen käytön syille ja seurauksille. Tätä kautta työ esittää johtopäätöksiä tilanteista ja
olosuhteista, joissa ROR-kehyksen käyttö on suotuisaa tai suositeltavaa. Työssä mainittuja
web-maailman termejä ja teknologioita avataan ja selitetään hyvin minimaalisesti ja vain
silloin kun se on ROR-kehyksen ymmärtämisen kannalta erityisen oleellista. Pääosin
näiden termien käsittely on tämän työn laajuuden ulkopuolella. Työ olettaa lukijalta laajaa
perustason tietämystä ohjelmoinnista, ohjelmistotuotannosta sekä web-maailmassa
vallitsevista teknologioista, standardeista ja suunnittelumalleista.
1.3 Työn rakenne
Toisessa kappaleessa esitellään ROR-kehyksen sisältö: perusidea, ympäristö, periaatteet,
arkkitehtuuri ja komponentit. Kolmannessa kappaleessa käsitellään hyvin lyhyesti Rubyohjelmointikieli sekä sen käyttöön johtavat syyt ja käytön seuraukset. Kappaleessa
esitellään myös Ruby-maailmassa kuuluisa Twitter-tapaus. Neljäs kappale keskittyy RORkehyksen eroihin muihin sovelluskehyksiin verrattuna. Kappale esittelee ketterän
sovelluskehyksen peruspiirteitä ja vertailee ROR-kehystä kolmeen Java-pohjaiseen
ketterään kehykseen. Kappaleessa tutkitaan myös ROR-sovelluksen ylläpidettävyyttä ja
muokattavuutta. Lopuksi pohditaan työn sisältöä ja esitellään sisällön pohjalta syntyvät
johtopäätökset sekä suositukset.
4
2
RUBY ON RAILS -SOVELLUSKEHYS
ROR on [3] Ruby-ohjelmointikielen ympärille rakennettu web-sovelluskehys, jonka
tavoitteena on olla kehittäjäystävällinen eli helppo oppia ja nopea sekä miellyttävä käyttää.
ROR-kehyksen
päämääränä
on
tarjota
yksinkertaisuutta,
uudelleenkäytettävyyttä,
laajennettavuutta, testattavuutta, tuottavuutta ja ylläpidettävyyttä. Kehys on suunnattu
tietokantakeskeisten sovellusten kehittämiseen, jollaisia ovat mm. verkkokaupat,
verkkoyhteisöt, viestipalvelut ja verkon erilaiset tietopankit. Kehyksen puolestapuhujat
ilmoittavat alustan ihannekäyttötapaukseksi ”uuden yrityksen ensimmäisen websovelluksen tuottamisen,” varsinkin jos sovellus lukee ja tallentaa jonkinlaista transaktioja käyttäjätietoa tietokantaan. Tällaisessa tapauksessa ROR-kehyksen valinta edistää
kehitystyön korkeaa tuottavuutta ja sovelluksen nopeaa kehitys- sekä julkaisutahtia.
2.1 ROR ympäristönä
Kun ROR-ympäristöä verrataan Javan J2EE (Java 2 Platform Enterprise Edition)
vastineeseen, niin eroja ovat lyhyempi koodi ja pienempi konfiguraatiotarve. RORympäristössä saman toiminnon kuvaus vaatii yleisesti vähemmän koodia ja kehityksen
aloitus sekä sivuston julkaisu vähemmän konfiguraatiota. ROR on saumattomasti
yhteentoimiva kokonaisuus toisin kuin esim. J2EE-sovellus, joka koostuu lukuisista
erilaisista komponenteista, jotka tulee valita, koota ja määrittää sovellusta varten. RORsovellus vaatii kehyksen ulkopuolisina komponentteina vain web-palvelimen ja
tietokannan. Kehys sisältää valmiiksi jo suppean WEBrick-palvelimen, mutta sovelluksia
voi
myös
ajaa
kaikenkattavien
ratkaisujen
päällä
esim.
käyttämällä
Apache-
palvelinohjelmistoa. ROR sisältää oletuksena asetukset MySQL-tietokannan käyttämiseen,
mutta kehys sisältää tuen myös mm. PostgreSQL, MS SQL Server, IBM DB2 ja Oracle
-tietokantoihin. [5]
ROR käyttää Model-View-Controller -arkkitehtuuria, joka pyrkii eriyttämään koodin
käyttötarkoituksen mukaisesti. MVC-suunnittelumallin [6] tavoitteena on eriyttää
sovelluksen liiketoimintalogiikka, esitysasu ja sisäinen kontrollilogiikka niin, että
sovelluksen osatoiminnallisuus on keskitettyä, muutoksenkestävää ja uudelleenkäytettävää.
Model sisältää tiedon ja tietoon liittyvät liiketoimintasäännöt, View on näkymä tiedon
5
esittämiseksi ja Controller muuttaa näkymien kautta tapahtuvan käyttäjäinteraktion
sovelluksen toiminnoiksi sekä valitsee vastauksia ilmentävät näkymät. ROR-maailmassa
tämä arkkitehtuuri implementoidaan kolmen keskeisen komponentin kautta, jotka ovat
Active Record, Action View ja Action Controller nimettynä vastaavien suunnittelumallien
mukaisesti. [7,4]
ROR tarjoaa Scaffolding -työkalun, joka generoi sovelluksen luokkia ja näkymiä
automaattisesti. Lopputuloksena syntyy sovelluksen perustoiminnallisuus ja laajennettava
runko, jolla sovelluksen CRUD-toiminnallisuus (Create-Read-Update-Delete) tuotetaan.
CRUD on termi, joka kuvaa web-sovelluksen tiedonhallintaa ja tietokantaoperaatioita.
Toisin sanoen tämä Scaffolding-generoitu perustoiminnallisuus sisältää tietokantarivien
luonnin, luvun, päivityksen ja poistamisen toiminnot (luokat ja metodit) sekä näkymät
(käyttöliittymät). Scaffolding tuottaa MVC-mallin mukaisia rakenteita ja jakaa syntyvän
koodin controller ja model –luokkiin sekä view-näkymämalleihin (templates). ROR tukee
myös Ajax (Asynchronous JavaScript and XML) Scaffolding -mahdollisuutta, jossa
tietokantaoperaatioit rakennetaan tapahtumaan Ajax-teknologian läpi asynkronisesti
JavaScript-koodin ja XML-tiedonsiirron (Extensible Markup Language) avulla. [7,5]
Feng et al. [8] ovat vertailleet ROR-kehitystyökaluja. Yleisesti kehitystyökalut voidaan
jakaa kahteen kokoluokkaan: raskaisiin ja kevyisiin. Käytännössä raskaat ratkaisut vaativat
enemmän järjestelmäresursseja, mutta tarjoavat laajemmat ominaisuudet. Kevyet ratkaisut
ovat enemmänkin tekstieditoreita, joita käytetään yksinkertaisten ja pienten toimintojen
suorittamiseen, ja ne valitaan usein henkilökohtaisten mieltymysten perusteella. Raskaat
työkalut auttavat ohjelmoijaa valitsemaan oikeita rakenteita ja metodeja. ROR-kehykselle
tarkoitettuja raskaita ratkaisuja verratessa lähes tasaväkisiksi selvisivät RadRails, NetBeans
ja Eclipse DLTK (Dynamic Languages Toolkit), jotka kaikki ovat avoimen lähdekoodin
ohjelmistoja. ROR-ohjelmoijalla on siis käytössään monta vaihtoehtoista työkalua ja
voidaan sanoa, että työkalutuki on tällä hetkellä kattavaa. Koska kehitystyökalut muuttuvat
nopeasti, niin vertailun tuloksia voidaan kuitenkin pitää vain hetkellisesti suuntaa antavana.
6
2.2 Perusperiaatteet ja ROR-näkökulma sovelluskehitykseen
ROR-kehys
tarjoaa
uuden
lähestymistavan
web-sovelluskehyksen
sisältöön
ja
toimintatapoihin kolmen periaatteen avulla [7,4]:
1. DRY (Don’t Repeat Yourself)
2. Convention over Configuration.
3. REST (Representational State Transfer) is the best pattern for web applications.
DRY. Ratkaisu on väärä, jos se vaatii saman koodin kirjoittamista moneen kertaan. DRYperiaatteen mukaan kaikki järjestelmän sisältämä tieto on esitetty uniikilla, tarkasti
määritetyllä ja relevantilla tavalla. Tavoitteena on tehdä kaikesta määrittelystä
uudelleenkäytettävää ja eliminoida kaikki turha toisto. DRY-periaate tulee selkeästi esiin
tavassa, jolla ROR yhdistää tietokannan taulut ohjelmakoodiin. Tietokantatauluja vastaavat
luokat ovat Active Record-komponentin ansiosta automaattisesti käytössä ja ne pysyvät
ajantasalla, koska ne ovat suoria tietokannan tietueita mallintavia kopioita ja siten
määritelty vain yhdessä paikassa.
Convention over configuration. ROR välttelee kaikkea konfiguraatiota viimeiseen asti.
ROR-maailmassa pakollinen konfiguraatio rajoittuu tietokantayhteyden määritykseen.
Kaiken muun konfiguraation ja toiminnallisuuden osalta ROR käyttää oletuksia, jotka
jakaantuvat oletukseen siitä mitä tehdään ja oletukseen siitä miten se tehdään. Ideana on
tehdä jokapäiväiset operaatiot mahdollisimman helpoiksi, mutta antaa silti kaikki avaimet
erikoisratkaisujen toteuttamiseen. Näin kehittäjä on vapaa muuttamaan ja korvaamaan
jokaisen sovelluskehyksessä vallitsevan oletuksen. Esimerkiksi ohjelmakoodissa oleva
auto-luokka,
joka
sijaitsee
samannimisessä
tietokantataulussa,
voidaan
periyttää
tarkemmaksi ferrari-luokaksi ja huomata, että sen luokan oliot tallennetaan yhä oletuksena
isäntäluokkansa tietokantatauluun.
REST is the best pattern for web applications. ROR olettaa REST-mallin olevan paras ja
nopein tapa kehittää web-sovelluksia. REST-mallissa [9] kaikilla sovelluksen resursseilla
on oma yksilöllinen osoitteensa. Resursseja käytetään kohdistamalla niihin HTTP-verbien
(HyperText Transfer Protocol) (verbit: get, put, post ja delete) avulla tehtyjä pyyntöjä.
Sovellus muodostaa vastausesityksen pyynnön tyypin ja resurssin tilan perusteella.
7
Esimerkiksi pyyntö ”DELETE /photos/17” osoittaa photos-resurssin arvoon 17 ja pyynnön
toiminnon tulkitaan olevan tämän arvon poistaminen resurssista. Sovellus vastaa tähän
pyyntöön oman toimintalogiikkansa mukaisesti, esim. kertomalla, että arvo on poistettu.
ROR-sovelluskehyksessä kaikki resurssit toimivat REST-mallin mukaisesti.
2.3 Arkkitehtuuri ja keskeiset komponentit
ROR-sovelluksen toiminta noudattaa MVC-suunnittelumallia. Käyttäjä suorittaa toimintoja
käyttäjänäkymän interaktion tuloksena syntyvillä pyynnöillä, jotka ohjataan palvelimelle ja
siellä edelleen Dispatcher-komponentille, joka ohjaa pyynnöt sovelluksen Controllerluokalle. Dispatcher on ROR-implementaatio Front Controller -suunnittelumallista [6].
Action Controller -komponentti määrittää sovelluksen tilan ja muuttujat, ja valitsee näiden
pohjalta oikean käyttäjänäkymän. Controller-luokka ja valittu näkymä suorittavat
sovelluksen toimintoja kutsumalla luokkien metodeja, jotka implementoivat MVCtoimintamallin
liiketoimintalogiikan
prosessit
ja
toiminnot
eli
Model-osuuden
ensimmäisen puolen. Toinen puoli koostuu sovelluksen tietokantaresursseista eli datasta,
johon päästään käsiksi Active Record -komponentin kautta. Käyttäjärajapinta eli näkymä
tarjotaan Action View -komponentissa, joka muodostaa web-sovelluksen käyttöliittymän
HTML-dokumenttina (HyperText Markup Language). Tapahtumasarja on kuvassa 1. [5]
HTTP-pyyntö
Selain
Palvelin
Tietokanta
Välittää pyynnön
Käyttäjänäkymä
Dispatcher
(Front Controller)
Action View
Valitsee
ja alustaa
Kyselyt ja
vastausdata
CRUD
operaatiot
Renderöi
Action Controller
Active Record
Vastaukset
Kuva 1. ROR-arkkitehtuuri ja web-sovelluksen toiminta [5].
8
Action Controller määrittää kuinka sovellus reagoi HTTP-pyyntöihin. Komponentin
tehtävänä on määrittää pyynnön sisältö ja tulkita käyttäjän tarve oikeaksi toiminnoksi
sovellusohjelmassa. Ensimmäisenä pyyntö kutsuu sen kohdeosoitteen resurssille
määritettyä ohjausluokkaa. Tämä luokka suorittaa omat toimintonsa ja sen jälkeen siirtää
pyynnön käsittelyn seuraavalle ohjausluokalle tai aloittaa käyttäjälle lähetettävän
vastausnäkymän luomisen. Toisinsanoen tämä komponentti yhdistää kaiken RORarkkitehtuurin yhdeksi kokonaisuudeksi.
Komponentti tukee myös pyyntöjen esi- ja
jälkisuodatusta, joiden avulla pyyntöön voidaan kohdistaa oheistoimintoja ennen tai
jälkeen toiminnon suorituksen. Suodatuksen avulla voidaan toteuttaa esim. tapahtumalogin
nauhoitusta, sessionhallintaa sekä käyttäjäoikeuksien tarkistamista. [7,4]
Active Record yhdistää sovelluskehyksen ja tietokannan. Komponentti muuntaa CRUDfunktiot SQL-komennoiksi (Structured Query Language), kohdistaa ne valmiiden
lausekkeiden muodossa tietokantaan ja palauttaa tulokset sovelluksen käytettäväksi. Active
Record myös valvoo tietokannan käyttöoikeuksia. ROR-kehyksen ORM-mallissa (ObjectRelational Mapping) Active Record luo tietokannan tauluja vastaavat luokat koodin
käytettäväksi. ORM-malli yhdistää koodin luokkarakenteet tietokantarakenteisiin. Luokan
oliot mallintavat suoraan tietokannan tietuetta ja luokka saa automaattisesti attribuutit
tietueen sarakkeiden ja relaatioliitosten mukaisesti. Isäntäluokasta periytyvät lapsiluokat
Active Record mallintaa Single Table Inheritance -suunnittelumallin mukaisesti
sijaitsemaan oletuksena samassa taulussa. Active Record tarjoaa toimintoja myös
syötekäsittelyyn niin tiedon sisällön kuin tallennusmuodonkin valintaan ja määritykseen.
Virhetilanteissa palaute voidaan siirtää ja esittää suoraan Action View -näkymässä, esim.
”vaadittu syöte ei ollut numeerinen.”
Action View luo HTTP-pyyntöön vastauksena esitettävän visuaalisen käyttäjänäkymän,
jonka
käyttäjä
näkee
HTML-muotoisena
dokumenttina.
ROR-dokumenttimalleja
(templates) on kahta päätyyppiä: RHTML ja RXML. Nimiensä mukaisesti ne tarkoittavat
Ruby-koodin yhdistämistä HTML- ja XML-dokumenttiin. Kolmantena muotona vastaus
voi olla myös RJS eli JavaScript-koodia. ROR suosii vastausdokumenttien määritystä
malleja (templates) rakentamalla ja yhdistelemällä. Mallit sisältävät ulkoasua merkkaavaa
HTML-koodia ja ajonaikana määritettävää dynaamista sisältöä, joka kirjoitetaan Rubykoodina. Mallit on suunniteltu uudelleenkäytettäväksi läpi web-sovelluksen. Tällaisia
9
yleisiä osamalleja (sub-template) ovat esim. verkkosivun sisältöä ympäröivät ylä- ja
alapalkit. Sivustoille vapaasti liitettäviä näkymien osakokonaisuuksia kutsutaan Rubytermistössä nimellä Partials. ROR-kehys sisältää myös valmiita apukomponentteja, jotka
ovat valmiita malleja mm. virheviestien, sisällön- ja syötteentarkastusten ja sivuston
hallintaelementtien tulostamiseen.
Action Web Services komponentti sisältää ROR-kehyksen web-palvelurajapinnan (webservices). Komponentti tukee WSDL-määritystä (Web-Service Description Language),
SOAP-viestejä (Simple Object Access Protocol) ja XML-RPC -protokollaa (XML Remote
Procedure Call) REST-mallin mukaisesti, ja sen avulla on mahdollista määrittää ja
julkaista API-rajapintoja (Application Programming Interface). Web-palvelu on resurssi,
joka tarjoaa toimintoja ”agenttisovellusten” tarpeisiin. Tällaista rajapintaa voi käyttää
esimerkiksi konekielisen datan tuomiseksi sovellusjärjestelmän. ROR tarjoaa kolme eri
tapaa kutsua (dispatch) sovelluksen web-palveluita. Ensimmäinen tapa määrittää palvelut
Controller-luokan julkisina metodeina. Jos yhden Controller-luokan täytyy tukea useampaa
rajapintaa, täytyy kuitenkin käyttää toista tapaa, jossa delegaatti-viittaus osoittaa valittuun
rajapintaluokkaan. Kolmas tapa määrittää palvelut nimiavaruuksien kautta, jolloin
palveluita voidaan kutsua suoraan nimen ja metodin yhdistelmällä. ROR määrittää myös
valmiita asiakasmalleja, joita voidaan käyttää ulkoisten palveluiden kutsumiseen ja
sovellusten väliseen integraatioon. [5]
10
3
RUBY-OHJELMOINTIKIELI
Ruby on skripti- ja oliokieli, joka tukee mm. luokkia, periytymistä sekä luokkametodeja.
Kieli on tulkattava ja aito dynaaminen oliokieli, koodia ei tarvitse kääntää ennen suoritusta
ja kaikki muuttujat ovat olioita, mukaanlukien perinteiset integer, float ja string –tyypit.
Ruby on kuitenkin vahvasti tyypitetty kieli ja tyyppimuunnosten oikeellisuus määritetään
ajon aikana. Ohjelmien poikkeustilanteita varten Ruby sisältää perinteisen ”try-catchfinally” -poikkeusmallin, tosin omilla Ruby-termeillään: ”begin-rescue-ensure.” Kielen
lähdekooditiedostot merkataan ”.rb” -päätteellä. Ruby tukee nopean ja nopeasti koodatun
ratkaisun tuottamista, eikä vahdi hyvien ohjelmointitapojen noudattamista esim. tiukalla
syntaksilla vaan antaa vapauden ja vastuun kehittäjälle. [3,5,10]
Rubyn isä ja luoja on Yukihiro Matsumoto. Kieli
julkaistiin 1995 ja se on saanut
vaikutteita ja ominaisuuksia Perl, Smalltalk, Eiffel, Ada ja Lisp -kielistä [11]. Kielen
puolestapuhujat ovat ylpeitä siitä, että se on kehitetty ihmisen eikä tietokoneen ehdoilla.
Kielen sanotaan olevan helppo ymmärtää ja muutama esimerkki kielen rakenteista voidaan
nähdä taulukossa 1. Suuria lupauksia kielen puolesta antaa
mm. Boeing-yrityksessä
sovelluskehittäjänä toimiva Curt Hibbs [3], joka arvioi Rubyn käyttämisen olevan noin
kuusi kertaa Javaa nopeampaa. Rubyn puolesta julistaessa nostetaan esille ohjelmointiin
käytettyjen työtuntien kustannukset suhteessa laitekustannuksiin. Ruby-kielen ajo on
hitaampaa kuin monen muun kielen, mutta puolestapuhujien mielestä kehityskustannusten
säästö on menetetyn suorituskyvyn veroinen [12].
Taulukko 1. Muutama pätkä Ruby-ohjelmointikoodia.
Koodi
Lopputulos
5.times { print ”hello!” }
Tulostaa ”hello!” viisi kertaa.
exit unless ”restaurant”.include? ”aura”
Ohjelma sammuu, paitsi jos ”aura” löytyy
sanasta ”restaurant”
population = 12_000_000_000
Lukuarvojen
luettavuutta
on
mahdollista
parantaa, population = 12*10^9
$dollar, @dollar, dollar
Globaali-, instanssi- ja lokaalimuuttuja.
11
3.1 Ruby, PHP ja Java: erot ja lyhyt vertailu
Käyttötarkoituksensa takia Rubyä on luonnollista verrata suosittuihin PHP- ja Javaohjelmointikieliin [5]. Vuonna 2006 PHP oli yleisimmin käytetty skriptikieli ja Java yleisin
ohjelmointikieli. Ruby on paljon PHP-kielen kaltainen, mutta vahvemmin oliopohjainen,
sillä Ruby-kielessä ei esiinny yhtään primitiivityyppiä toisin kuin PHP-kielessä. Ruby ei
kuitenkaan tue abstrakteja luokkia tai rajapintoja, toisin kuin PHP. Ruby tukee Mixins ja
module -määrityksiä, joiden avulla voidaan toteuttaa moniperintää muistuttava
toiminnallisuus sekä muokata olioiden metodeja ajon aikana. Kehystasolla ROR on
laajempi kuin mikään PHP-kieleen liitettävä valmis sovelluskehys. Javaan verrattuna Ruby
mielletään yksinkertaiseksi ja ketteräksi kieleksi, vaikka Javaa kuitenkin pidetään
paremmin
skaalautuvana,
turvallisempana,
suorituskyvyltään
nopeampana
sekä
sovelluskehitystyökaluiltaan parempana. Ruby on dynaamisesti tyypitetty ja Java
staattisesti, mikä tarkoittaa, että Rubyssä olioiden tyyppi tulkitaan implisiittisesti ilman
annettua tyyppimäärettä. Java on myös käännettävä ennen ajoa JVM-suorittajan (Java
Virtual Machine) ymmärtämään tavukoodimuotoon. Näissä kolmessa kielessä on myös
tietysti merkittäviä syntaksieroja. Yhtenä suurena erona Ruby ei anna määrittää julkisia
luokkamuuttujia, toisin kuin PHP tai Java, vaan pakottaa käyttämään metodeja.
3.2 Tapaus Twitter ja Rubyn suorituskyky
Twitter
on suosittu ja kasvava kommunikaatiopalvelu 140 merkkiä pitkien viestien
välitykseen ja jakamiseen [13]. Se oli myös suurin kokonaan ROR-kehyksellä toteutettu
verkkopalvelu vuoteen 2008 asti, jolloin Twitter julisti ROR-ympäristön riittämättömäksi
palvelun kasvaneisiin vaatimuksiin. Twitter kävi vaihtamaan palvelun taustajärjestelmiä
JVM-alustalle
ja
uudelleenkirjoittamaan
sovelluksen
taustakoodia
Scala-
ohjelmointikielellä. Twitterin kehittäjien mukaan ROR soveltuu loistavasti käyttäjille
näkyvien verkkosivujen tuottamiseen ja ketterään kehitykseen, mutta suorituskyky
laskenta- ja muisti-intensiivisessä taustaprosessoinnissa ei ole riittävä. [14,15,16]
Twitterin sovelluskehittäjien [14] mukaan ongelmana on Ruby-kieli, joka ei kykene
tarjoamaan tarpeeksi luotettavaa ja suorituskykyistä koodia. Yksi sovelluksen uusista
vaatimuksista on koodin oikeellisuuden todistaminen vahvan staattisen tyypityksen avulla,
12
mutta ongelmina mainitaan myös muistin hallinta ja roskaantuminen sekä heikko tuki
moniajoon ja säiehallintaan. Ruby todetaan kuitenkin hyvin joustavaksi, ominaisuuksiltaan
kattavaksi
ja
erittäin
miellyttäväksi
ohjelmointikieleksi.
Näiden
positiivisten
ominaisuuksien ansiosta Twitter valitsi korvaavaksi kieleksi samoja vahvuuksia sisältävän
Scala-kielen eikä esim. Java- tai C++-kieltä, jotka ovat perinteisempiä valintoja korkean
suorituskyvyn web-sovelluksiin. Scala käännetään Java-tavukoodiksi, joka ajetaan JVMalustan päällä, joten kehityksessä käytetään Scalan joustavuutta ja ajossa Javan
suorituskykyä.
13
4
ROR-KEHYS JA KILPAILEVAT TUOTTEET VERTAILUSSA
On luonnollista verrata ROR-kehystä muihin suosittuihin vastaaviin ratkaisuihin, jotka
myös painottavat ketteryyttä ja yksinkertaisuutta sekä kaikenkattavaa ratkaisua. Lisäksi on
tarpeellista tutkia ROR-kehyksen eroja isojen yritysten keskuudessa suosituimpiin
Microsoft ja Oracle (Java) ratkaisuihin. Tässä osiossa käydään läpi kaksi akateemista
tutkimusta, joista ensimmäinen vertailee ketteriä sovelluskehyksiä ja toinen mittaa RORkehyksen ylläpidettävyyttä verrattuna J2EE- ja ASP.NET-alustaan. Molemmat tutkimukset
ovat ominaisuus- ja luokitusvertailuja, eivätkä ne siten ole suoraan kytköksissä
teollisuuden
käytäntöihin
tai
valintoihin
vaan
ilmentävät
kehyksien
yleisiä
mahdollisuuksia. Eri kehysten markkinaosuuksia mitatessa voidaan kuitenkin huomata,
että ROR on erittäin pieni peluri. Taulukko 2 näyttää eri sovelluskehyksien
markkinaosuudet maailman 10 000 suosituimmalla verkkosivustolla. Taulukkoon on
valittu kolme suosituinta (PHP, ASP.NET ja Flash) sekä vertailukohdiksi myös J2EE ja
ROR. ROR on listassa kahteen kertaan, koska keräysmekaniikka tunnistaa ROR
sovellukset kahdella eri tavalla, josta seuraa myös kaksi eri sovellusryhmää.
Taulukko 2. Sovelluskehysten markkinaosuudet suosituimmilla verkkosivustoilla [17].
Sovelluskehys
Käyttöosuus top 10 000 sivustoilla (prosenttia)
1.1.2010
28.3.2011
PHP
29,48
31,37
ASP.NET
23,91
21,38
ShockWave Flash
15,11
12,47
J2EE
7,66
7,22
Ruby On Rails
1,44
1,91
Ruby On Rails Token
0,06
0,64
4.1 Ketterät Java-pohjaiset sovelluskehykset ja ROR
ROR aloitti uuden web-kehityssuuntauksen, mutta sai nopeasti joukon samankaltaisia
matkijoita. Ilmapiiri oli erityisen otollinen, koska ROR käytti Ruby-ohjelmointikieltä, joka
oli sillä hetkellä suhteellisen tuntematon ratkaisu. Muut suositut ketteryyttä ja
yksinkertaisuutta tavoittelevat ja samalla täyden kokonaisuuden tarjoavat kehysratkaisut
14
ovat pääosin Java-pohjaisia. Javan käytöllä ne pyrkivät hyödyntämään teknologian hyvää
tunnettavuutta ja kypsyysastetta sekä sitä valtavaa kehittäjämassaa, joka hallitsee Javakielen. Ignacio et al. [18] ovat tutkineet ketteriä web-sovelluskehyksiä ja määrittäneet
asteikon, jolla kehyksiä voidaan mitata ja luokitella. Artikkelissa ROR-kehys asetetaan
vasten kolmea ketterää Java-ratkaisua (Grails, Roma ja Trails). Tuloksien mukaan RORkehyksen
vahvuuksia
ovat
käyttäjänäkymät,
käytettävyys,
testattavuus
sekä
verkkorajapinta, mutta toisaalta ainoat merkittävät erot sijaitsevat käytettävyyden ja
testattavuuden osa-alueilla. Java-kehykset ovat vahvimmillaan turvallisuudessa ja
käyttöasteessa. Kaikki neljä kehystä todetaan tasavahvoiksi soveltuvuudessa ja yhtä
heikoiksi uudelleenkäytettävyydessä.
Artikkelissa nämä osa-alueet on määritelty seuraavasti: Soveltuvuus mittaa kehyksen
sopivuutta web-sovelluksen ja palveluiden vaatimuksiin. Käyttäjänäkymä sisältää
näkymien rakentamisen monipuolisuuden ja helppouden mittarit. Turvallisuus sisältää mm.
staattisen tyypityksen, käyttäjäsyötteiden tarkastuksen (mm. tietoturvahyökkäyksiä estäen)
ja käyttäjien autentikaation automaattisuuden ja kattavuuden määrityksen. Käytettävyys
ottaa kantaa koodigenerointimahdollisuuksiin ja dynaamisen tyypityksen mahdollisuuksia.
Testattavuus
mittaa
testitapausten
kattavuutta
ja
luonnin
helppoutta.
Verkkorajapintaratkaisut-alueella määritetään REST-tukea sekä verkkostandardien oikeaa
käyttöä ja oikeellisuuden tarkastusta. Uudelleenkäytettävyys mittaa eri moduulien
siirtokelpoisuutta ja muutettavuutta. Käyttöaste sisältää teknologian yleisyyden ja
kypsyysasteen määrityksen.
4.2 Ylläpidettävyys ja muut luonteenpiirteet: ROR, J2EE ja .NET
Web-sovelluskehysratkaisu valitaan usein kokemusperäisesti ohjelmoinnin helppouden ja
tuottavuuden perusteella. Kehyksen tarjoamaan ylläpidettävyyteen ja muutettavuuteen ei
kiinnitetä varsinaista huomioita, varsinkaan sovelluskehityksen alkuvaiheissa. Kuitenkin
kun otetaan huomioon web-sovellusten elinikä, on ylläpidettävyys tärkeä osa ratkaisun
onnistumista. Ylläpidettävyyteen kuuluvia osa-alueita ovat erityisesti muutettavuus,
testattavuus, ymmärrettävyys ja siirrettävyys. Muutettavuus tarkoittaa sovelluksen kykyä ja
vapautta muuttumiseen, mm. muuttuvien koodirivien määrää, tiedostojen määrää sekä
muutoksen kuluttamaa työaikaa. Ymmärrettävyys tarkoittaa koodin ja ratkaisujen
15
helppolukuisuutta sekä ymmärrettävyyttä, mutta on hyvin subjektiivinen mittari.
Siirrettävyys tarkoittaa tukea sovelluskehyksen ulkoisille liitoksille, esim. verkkopalvelinja tietokantaratkaisuille. [19]
Stella et al. [19] ovat verranneet ROR-alustaa suosituimpiin J2EE- ja .NET-alustoihin.
Vertailussa todettiin,
että ROR
tukee muutettavuutta ja
ymmärrettävyyttä
yli
vertailukumppaneiden. On kuitenkin tärkeä huomata, että vertailu on vain suuntaa antava,
koska otoskoko sekä vertailun laajuus ovat hyvin rajoittuneita: kyseessä on pieni yhden
miehen projekti kolmella eri web-alustalla. Vertailu on kuitenkin mielenkiintoinen
tutkittaessa ROR-kehyksen käytännön eroja ja hyviä puolia, koska siitä käy selkeästi ilmi
eri kehysten erilaiset lähestymistavat ja toteutusratkaisut. Vertailun tuloksia ei kuitenkaan
voida pitää yleistyskelpoisina tai objektiivisina.
Vertailu suoritettiin toteuttamalla pienimuotoinen web-sovellus kaikilla kolmella alustalla
tavoitteena saada identtinen lopputulos kaikissa kolmessa tapauksessa. Myöhemmin tähän
web-sovellukseen kohdistettiin muutoksia ja laajennoksia, jolloin tutkittiin eri alustojen
muutettavuutta, testattavuutta, ymmärrettävyyttä sekä siirrettävyyttä. Vertailun J2EE-alusta
käytti Spring MVC -verkkorajapintaa, Spring-kirjastoa liiketoimintakoodiin ja Hibernatetietokantarajapintaa. Microsoftin .NET-alusta käytti ASP.NET-verkkorajapintaa, .NETkirjastoa liiketoimintakoodin kuvaukseen ja ADO.NET-tietokantarajapintaa. Alustan
ohjelmointikieleksi oli valittu C#. ROR-alustassa vastaavat komponentit ovat Action
Controller, Action View ja Active Record.
Verkkotaso koostuu näkymistä ja pyyntöjen prosessoinnista. Vertailtavista alustoista J2EEja ROR-ratkaisu käyttivät suoraan MVC-suunnittelumallia ja .NET käytti MVPsuunnittelumallia (Model-View-Presenter) tämän tason toteuttamiseen. Erona on, että
.NET-lähestymistapa sekoittaa kaikkea kolmea mallin osa-aluetta enemmän samoihin
tiedostoihin, eikä jako siten ole yhtä selvä kuin kahdessa muussa kehyksessä. Toisaalta
vertailu tunnisti, että tämä .NET-lähestymistapa on intuitiivisempi ja ymmärrettävämpi,
eikä vaadi merkittävää tietämystä HTTP-protokollan toiminnasta (esim. HTTP-verbien
sisältö ja toiminta). Liiketoimintakoodi on eriytetty selkeästi tietokantarajapinnasta J2EEja .NET-ratkaisussa, kun taas ROR-kehys yhdistää liiketoimintakoodin läheisesti
tietokantarajapintaan. J2EE yhdistää liiketoimintakoodin ja tietokantarajapinnan kiinteillä
16
XML-konfiguraatiotiedostoilla kun taas .NET luottaa ohjelmointikoodiin, joka yhdistää
tietokantarakenteet sovelluksen luokkiin. ROR tarjoaa dynaamisesti generoitujen
luokkarakenteiden lisäksi myös mahdollisuuden staattisiin ja manuaalisiin laajennoksiin.
Taulukossa 3 näkyy testattavan sovelluksen vaatimien muutosten tiedosto- ja koodimäärä
jaettuna alusta- ja tasokohtaisesti. Lisäksi taulukosta käy ilmi muutoksiin kulunut
tuntimäärä.
Taulukko 3. Vertailun sovelluksen mitattu laajennos- ja muutostyö [19].
Taso
Muutettuja tiedostoja
Muutettuja
Muutokseen
koodirivejä
tuntimäärä
kulunut
J2EE
.NET
ROR
J2EE
.NET
ROR
J2EE
.NET
ROR
Verkko
15
16
13
296
349
142
8
9
10
Liiketoiminta
3
3
3
114
217
34
3
5
1
Tietokantarajapinta
4
1
29
129
1,5
4
Yhteensä
22
20
439
695
12,5
18
16
176
11
Yleisesti vertailun sovellustoteutuksia tutkiessa löydettiin seuraavia tuloksia: ROR tarjoaa
rivimääräisesti lyhyimmän ratkaisun, J2EE todetaan siirrettävimmäksi ja ROR sekä J2EE
ovat parhaiten testattavissa. J2EE-sovellus vaatii noin 6500 riviä verrattuna .NET 5200
riviä ja ROR 1400 riviä. Modulaarisuus- ja siirrettävyysarviossa J2EE saa tutkimuksessa
arvosanan korkea, ROR arvosanan keskitasoa ja .NET arvosanan matala. Tuloksia
perustellaan näkymien osakokonaisuuksien (Ruby-terminä Partials) tukemisella ja
yhdistämismahdollisuudella J2EE- ja ROR-ratkaisussa. Toisaalta .NET-toteutus on
korkeasti kytkeytynyt, koska näkymien koodi on läheisesti sidoksissa tietokantakoodiin ja
–rakenteisiin, ja alusta tukee vain Microsoftin käyttöjärjestelmiä ja IIS-palvelinta (Internet
Information Services). Testattavuudessa ROR ja J2EE ovat vahvoilla, koska ne tarjoavat
parempaa automaattista ja generoitua testattavuutta. Automaattinen testaus ei kuitenkaan
korvaa lopputuotteen manuaalista testausta käytettävyyden ja toimivuuden osalta.
17
5
KESKUSTELU JA JOHTOPÄÄTÖKSET
ROR tukee vaivatonta kehitystyön aloitusta ja edistää web-sovelluksen nopeaa julkaisua.
Perustoiminnallisuus
voidaan
rakentaa
ROR-kehyksen
oletuksia,
näkymien
osakokonaisuuksia, Active Record -komponenttia ja Scaffolding-työkalua hyödyntäen
hyvin nopeasti sekä erittäin pienellä vaivalla, verrattuna esim. .NET- tai J2EE-alustoihin.
Toisaalta,
jos
sovellus
on
monipuolinen
ja
sisältää
monimutkaisia
liiketoimintavaatimuksia, niin automaattiset perusratkaisut eivät välttämättä ole riittäviä ja
erikoisratkaisujen räätälöinnin ei voida olettaa olevan juurikaan nopeempaa kuin muissa
sovelluskehyksissä. ROR tarjoaa kuitenkin yhtenäisen kehitysympäristön, joka on
toteutettu hyviä web-standardeja ja käytäntöjä hyödyntäen, mikä on itsessään jo merkittävä
vahvuus.
Kappaleen 4.2 mukaan ROR tarjoaa kyllä koodiriveinä mitattuna lyhimmän websovellustoteutuksen, mutta tämä ei kuitenkaan käänny nykyaikaisten kehitystyökalujen
avulla yksiselitteisesti nopeammaksi kehitykseksi tai pienemmäksi virhemääräksi. Rubykoodi sisältää enemmän operaatioita per yksi rivi, joten ymmärrettävyys ei välttämättä ole
Rubyn vahvuus. Lisäksi samassa testitapauksessa muutoksiin kulunut tuntimäärät olivat
suhteellisen tasaisia, varsinkin J2EE ja ROR tapausten välillä ei ollut merkittävää eroa.
Tulokset eivät myöskään välttämättä olisi samansuuntaisia, jos kehitystyötä tekisivät
ympäristönsä läpikotaisin tuntevat ohjelmistokehittäjät. Kun ROR-kehyksen ominaisuuksia
vertaillaan ketteriin Java-kehyksiin (kappaleessa 4.1) niin tulokset ovat suhteellisen
tasaväkisiä, mutta vertailussa ei otettu huomioon esim. suorituskykyä tai kehitystyökaluja.
Tapaus Twitter (kappaleessa 3.2) kuitenkin kiistatta osoittaa ROR-alustan Ruby-kielestä
johtuvat heikkoudet, jotka korostuvat vaativassa ympäristössä, sekä toisaalta kertoo, että
varteenotettavia ja vertailukelpoisia vaihtoehtoja on olemassa.
ROR sopii siis erittäin hyvin pienten ja yksinkertaisten web-sovellusten tuottamiseen.
Suurempiin sovelluksiin ROR sopii vain jos sovelluksen laskentaintensiiviset osat on
mahdollista ulkoistaa tai kehyksen käytöstä syntyvät kehitysaikasäästöt ovat riittäviä
kattamaan lisääntyneen laskentatarpeen tai käyttöviiveen. Toisin sanoen, ROR vaihtaa
kehittäjätunteja lisääntyneeseen rautakapasiteettitarpeeseen. Rautatason suorituskyky on
kuitenkin web-ympäristön luonteesta johtuen hyvin harvojen sovellusten ongelma.
18
6
YHTEENVETO
Ruby On Rails on vuonna 2004 julkaistu avoimeen lähdekoodiin perustuva websovelluskehys, jonka tavoitteena on olla kehittäjäystävällinen ja yksinkertainen sekä tukea
mahdollisimman korkeaa tuottavuutta. Kehys käyttää Ruby-ohjelmointikoodia ja on
suunnattu tietokantakeskeisten sovellusten kehittämiseen. Sovellukset hyödyntävät
verkkokommunikaatiossaan
REST-mallia
ja
sisäisessä
toiminnassaan
MVC-
suunnittelumallia. ROR tukee uudelleenkäyttöä ja tarjoaa runsaasti oletuksia sekä
valmisratkaisuja, joiden avulla pyritään vähentämään yksinkertaisen peruskoodin
kirjoitustarvetta.
ROR tukee vaivatonta kehityksen aloitusta ja nopeaa julkaisutahtia, ja siten se soveltuu
erityisen hyvin pienten sekä yksinkertaisten web-sovellusten tuottamiseen. ROR vähentää
koodirivien määrä ja tehostaa sovelluskehitystä, mutta haittapuolena voidaan mainita
Ruby-kielen käytöstä johtuva laskenut suorituskyky, mikä johtuu Ruby-tulkista ja
staattisen tyypityksen puutteesta. ROR-kehyksen käytön syyt ja seuraukset ovat selvillä,
mutta paljon puhuttu tehostunut sovelluskehitys ei ole helposti mitattavissa tai
määritettävissä. Ei ole myöskään täysin selvää, että soveltuuko ROR suurten websovellusten tuottamiseen ja että säilyvätkö ROR-kehyksen vahvuudet myös isoissa websovelluksissa. Omalla kotikentällään ROR on kuitenkin erittäin kilpailukykyinen ratkaisu.
19
LÄHTEET
[1] Ran, H., Zhuo, W., Jianfeng, X. 2009. Web Quality of Agile Web Development.
Services Science, Management and Engineering 2009. July 2009, Zhangjiajie. pg.
426-429.
[2] Barry, C., Lang, M. 2001. A Survey of Multimedia and Web Development
Techniques and Methodology Usage. IEEE Multimedia. IEEE Computer Society.
Volume 8, Issue 2. April-June 2001. pp. 52-60.
[3] Geer, D. 2006. Will Software Developers Ride Ruby on Rails To Success? Computer.
IEEE Computer Society. February, 2006. Volume 39, Issue 2. pg. 18-20.
[4] Ruby On Rails 2011. Ruby on Rails Guides (Version 3.0.5). Ruby on Rails. Päiväys
tuntematon. Saatavilla: http://guides.rubyonrails.org/ [Viitattu 28.3.2011]
[5] Vohra, D. 2007. Ruby On Rails for PHP and Java Developers. Springer-Verlag Berlin
Heidelberg.
[6] Fowler, M. 2003. Patterns Of Enterprise Application Architecture. Pearson
Educational, Inc.
[7] Bachle, M., Kirchberg, P. 2007. Ruby on Rails. IEEE Software. IEEE Computer
Society. November 2007. Volume 24, Issue 6. pg. 105-108.
[8] Feng, N., Xie, J., Wu, Y. 2009. Comparison of Ruby On Rails Development Tools.
Software Engineering 2009 (WCSE ’09). November 2009, Xiamen. pg. 290-294.
[9] Fielding, R. T. 2000. Architectural Styles and the Design of Network-based Software
Architectures. Doctoral Dissertation. Information and Computer Science. University
of California, Irvine.
[10] Viswanathan, V. 2008. Rapid Web Application Development: A ruby on Rails
Tutorial. IEEE Software. IEEE Computer Society. Volume 25, Issue 6. pg. 98-106.
[11] Ruby 2011. About Ruby. Ruby, A programmers best friend. Päiväys tuntematon.
Saatavilla: http://www.ruby-lang.org/en/about/ [Viitattu 1.4.2011]
[12] Spolsky, J. 2006. Ruby Performance Revisited. Joel on Software. Päivätty 12.9.2006.
Saatavilla: http://www.joelonsoftware.com/items/2006/09/12.html [Viitattu 1.4.2011]
[13] Twitter
2011.
About
Twitter.
Twitter.
http://twitter.com/about [Viitattu 29.3.2011]
20
Päiväys
tuntematon.
Saatavilla:
[14] Venners, B. 2009. Twitter on Scala: A conversation with Steve Jenson, Alex Payne,
and
Robey
Pointer.
Artima.
Päivätty
3.4.2009.
Saatavilla:
http://www.artima.com/scalazine/articles/twitter_on_scala.html [Viitattu 29.3.2011]
[15] Greene, K. 2009. The Secret Behind Twitters Growth. Technology Review. Published
by
MIT.
Päiväys
1.4.2009.
http://www.technologyreview.com/blog/editors/23282/?nlid=1908
Saatavilla:
[Viitattu
29.3.2011]
[16] Metz, C. 2009. Twitter jilts Ruby for Scala. The Register. Päiväys 1.4.2009.
Saatavilla:
http://www.theregister.co.uk/2009/04/01/twitter_on_scala/
[Viitattu
29.3.2011]
[17] Buildwith Trends 2011. Framework Usage Statistics. Buildwith Trends. Päivätty
28.3.2011. Saatavilla: http://trends.builtwith.com/framework [Viitattu 1.4.2011]
[18] Ignacio, J., Diaz-Casillas, L., Iglesias, C. A. 2008. A comparison model for agile web
frameworks. Proceedings of the 2008 Euro American Conference on Telematics and
Information Systems (EATIS ’08). September, 2008, Brazil.
[19] Stella, L.F.F, Jarzabek, S., Wadhwa, B. 2008. A comparative study of maintainability
of web applications on J2EE,.NET and Ruby on Rails. Web Site Evolution, 2008
(WSE 2008). 3-4 October 2008, Beijing. pg. 93-99.
21