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
© Copyright 2024