Kun aloitin Pulmattomalla kesällä 2023, en ollut kuullutkaan Ruby on Railssista (RoR). Kuitenkin hyvin nopeasti töitä tekemällä ja minulle kustannettua alkeiskurssia tutkimalla pääsin sisään RoR:n ihmeelliseen maailmaan ja huomasin ilokseni, että vaikka RoR ei ole enää nykyään niin suosittu, kuin mitä se oli noin 15 vuotta sitten, se on silti yllättävän helppo ja erittäin looginen ohjelmistokehys.
Mitä ”ohjelmistokehys” sitten tarkoittaa? Ohjelmistokehys on eräänlainen runko ohjelmistolle, jonka avulla pystytään rakentamaan erilaisia monimutkaisiakin ratkaisuja hyvinkin pienellä vaivalla. Muita tunnettuja ohjelmistokehyksiä ovat esimerkiksi Pythonin Django, Microsoftin .NET Framework sekä Javan Jade (Java Agent DEvelopment framework).
Ruby sai alkunsa 90-luvun alussa, kun japanilainen Yukihiro Matsumoto totesi, ettei sopivaa olio-ohjelmointikieltä ole olemassa, ja alkoi siksi väsäämään itse omaa ohjelmointikieltään. Ensimmäinen versio Rubysta, versio 0.95, ilmestyi vuonna 1995, ja uusia päivityksiä tulee edelleen: viimeisin versio 4.0.2 tuli maaliskuun 16. päivä tänä vuonna.
Yukihiron filosofia kieltä luodessa oli luoda ohjelmointikieli, joka on tehokas, mutta ennen kaikkea hauska ja ihmisen kannalta helppo kirjoittaa. Hän totesi eräässä haastattelussa vuonna 2003:
“Often people, especially computer engineers, focus on the machines. They think, ‘By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something.’ They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.”
Ihmisläheisyys on ollut Rubyn kehityksessä siis keskiössä.
Mikä tekee Railsista niin erityisen? Ruby on Rails syntyi, kun tanskalaisen David Heinemeier Hansson palkattiin kehittämään projektinhallintajärjestelmä. Tähän Hansson käytti Rubya kehittääkseen ensin kehyksen, jonka avulla luoda pyydetty järjestelmä. Järjestelmän valmistuttua Hansson julkaisi ohjelmistokehyksensä koodin ja noin vuoden kuluttua avasi koodin yleisesti muokattavaksi avoimen koodin ohjelmistokehykseksi.
Mikä sitten tekee RoR:llä työskentelemisestä niin mukavaa? Ruby itsessään on, filosofiansa mukaisesti, helppoa ja hauskaa kirjoittaa. RoR on rakennettu siten, että siinä pystyy tekemään monimutkaisiakin asioita todella pienellä määrällä koodia. Myös konfiguraation vähäinen määrä on erinomainen asia.
Ruby on Rails -kehyksessä hyödynnetään Convention over Configuration (CoC) -mallia. Käytännössä malli perustuu ajatukseen, että ohjelmiston tulisi noudattaa yhteisiä, sovittuja tapoja (konventioita). Kun seuraa yleistä mallia ja kaikki toimii, kuin rasvattu. Hyvä esimerkki tästä on nimeämiskäytäntö: kutsutaanko käyttäjän ID:tä nimityksellä UserId, user_id, uid vai onko käytössä jokin muu? Ruby on Railssissa on tietty konventio, jonka mukaan lähes kaikki tapahtuu.
Toinen tärkeä malli on Model-View-Controller (MVC).MVC on helppo implementoida ja lukea, ja mallin seuraaminen tekee ohjelmistosta loogista lukea ja tulkita. Model-View-Controller mallissa siis:
- Model (malli) yhdistää tietokannan muuhun projektiin automaattisesti
- View (näkymä) määrittää, mitä käyttäjä näkee. Yleensä sekoitus HTML-, CSS-, Ruby- sekä JavaScript-koodia
- Controller (ohjain) vastaa käyttäjän pyyntöihin, eli siis reagoi siihen, mitä käyttäjä tekee ja toimii siis mallin ja käyttäjän välissä
Koen, että Ruby on Railssin yksinkertaiset mutta lyhyet koodipätkät ovat kauniita tehokkuudessaan.
Nappaan tähän koodipätkän Hanssonin omasta The Rails Doctrine –”manifestistaan”:
class Project < ApplicationRecord
belongs_to :account
has_many :participants, class_name: ’Person’
validates_presence_of :name
end
Yksinkertaista! Upeaa! Mitä tässä siis tapahtuu? Tässä siis määritellään Projekti-luokka Project, joka toimii siis tässä modelina:
- Se kuuluu (belongs_to) tilille (account). RoR huomaa automattisesti, että tällainen relaatio on määritetty, eli jos projektilla on account_id-attribuutti, voidaan tilin tietoja saada suoraan projektista kutsumalla project.account. Jos määritelmää ei olisi, kutsu olisi raskaampi ja pidempi Account.find(project.account_id)
- Sillä on monta (has_many) osallistujaa (participant). Tämä tarkoittaa sitä, että osallistujilla on project_id attribuutti ja osallistujat saa suoraan projektista kutsumallla project.participants. Määritelmä asettaa luokasta Person (henkilö) henkilöitä nimelle participants. Eli käytännössä kutsulla project.participants saamme listan henkilöitä, joilla on relaatio tiliin sen sijaan, että pitäisi tehdä raskaampi ja vaikeammin luettava Person.where(project_id: project.id)
- Lisäksi projektia luodessa varmistetaan, että nimi (name) on olemassa (validates_presence_of). Jos nimi ei ole olemassa projektia luodessa, tulee virheilmoitus: ”Nimeä ei olemassa!”
Eli kunhan seuraa konventioita, lyhyellä ja tehokkaalla määritelmällä saamme paljon aikaiseksi. Rails tekee taustalla paljon, mikä tekee RoR:llä ohjelmoinnista tehokasta ja nopeaa.
Ensimmäinen kokemukseni ohjelmistokehyksistä oli Pythonin Djangolla edellisessä työpaikassa, jossa kehitimme laskutus- ja tilinpitojärjestelmää sekä firmansisäistä myyntijärjestelmää. Python on kielenä hajuttomampi ja mauttomampi, kuin Ruby. Se toimii, mutta on hieman vaikeammin luettavaa muun muassa siksi, että eri kooditasot erotetaan toisistaan sisennyksillä, kun taas Rubyssa on selkeä Start – End -erottelut (esimerkiksi yllä koodiesimerkissä class – end, eli luokan määrittely alkaa kohdassa class… ja määrittely loppuu kohdassa end). Toisaalta Pythonissa on laajemmat kirjastot, mutta Ruby on Rails voittaa siinäkin siksi, että RoR:n kirjastot ovat tarkemmin nimenomaan nettikehitystä kehyksen avulla tekemistä varten. Toki Pythonilla on oma paikkansa. Sanoisin, että tällä hetkellä data-analytiikan ja tekoälyjen kannalta Python on ohjelmistokielten aatelia. Toki tässä jää Django-ohjelmistokehys kokonaan pois laskuista, ja ohjelmistokehysten kuningas on, ainakin mielestäni, Ruby on Rails.
Suurin osa meidän projekteistamme tällä hetkellä on nimenomaan räätälöityjä nettisivuratkaisuja tai internetin välityksellä toimivia sovelluksia, joihin Ruby on Rails sopii, kuin nenä päähän. Miksi se sitten ei ole nykyään enää niin suosittu? Noh. Ensinnäkin RoR on edelleen laaja-alaisesti käytössä monessa eri paikassa ja monella eri alalla. Esimerkiksi Fiverr, AirBnB, Twitch sekä GitHub käyttävät applikaatioissaan Ruby on Railssia. Lisäksi uusia päivityksiä julkaistaan edelleen ja kirjastoja sekä päivitetään että luodaan uusia jatkuvasti. Eli vaikka se ei ole yhtä suosittu kuin ennen, RoR ei suinkaan ole kuolemassa pois. Kuitenkin käyttäjämäärissä on näkyvissä selkeää laskua, mikä selittyy osin sillä, että RoR:n rinnalle on tullut paljon uusia vaihtoehtoja. Vaikka uudet vaihtoehdot eivät ole välttämättä parempia, uutuuden viehätys ajaa käyttämään uusinta uutta.
RoR oli ensimmäisiä ohjelmistokehyksiä, joka oli hyvin kaikenkattava ja on edelleen yksi kattavimmista kehyksistä. Tämä johtuu osin myös siitä, että koska Ruby on Railssilla on vankka historia, kirjastot ovat laajoja ja hyvin tarkennettuja. Eräs asia, joka ajoi devaajia pois RoR:n parista oli RoR:n kehitys mikropalveluita kohti. Mikropalvelut, eli sovellusohjelman jakaminen pienempiin osiin, eivät olleet asia, joka sopisi hirveän hyvin Ruby on Railssiin. Myös harhakuvat siitä, että RoR olisi merkittävästi hitaampi, kuin muut ohjelmistokehykset. Tämä kuitenkaan ei pidä paikkaansa ja juontaa juurensa toisaalta siitä, että aloittelijan on todella helppo tehdä tietokantahauista niin kutsuttuja 1 + n -hakuja ja toisaalta siitä, että devaajia siirtyi Javasta, joka on käännettävä (complied) kieli, Rubyyn, joka on tulkittava (interpreted) kieli. Nyrkkisääntönä käännettävät kielet ovat nopeampia ajaa, kuin tulkittavat. 1 + n -haut ovat hakuja, joissa yhden haun sijaan tehdään yhden haun lisäksi haussa haettujen olioiden verran hakuja. Eli aikaisemman esimerkin pohjalta, jos haemme yhtä tiliä, jolla on 100 projektia, voisimme hakea kaikki kerralla yhdellä haulla tai sitten tehdä 1 + n -haun, jossa ensin haemme tilin ja sen jälkeen yksi kerrallaan projektit. Ja usein olioita on paljon enemmän, kuin 100.
Olen nauttinut Ruby on Railssin parissa työskentelystä jopa tilanteissa, joissa RoR:n front vaihdetaan Reactiin (mikä yhdessä projektissa on tapahtunut). Se on helppoa, sillä se miksi eri asioita laitetaan tiettyihin paikkoihin, on loogista.Se on hauskaa,sillä sitä on helppo lukea ja tyydyttävää kirjoittaa.Se on myös tehokasta, koska sillä saa aikaan nopeasti paljon verrattuna muihin kehyksiin. Suosittelen Ruby on Railssia kaikille vähintään kokeilumielessä, mutta riippumatta siitä, mistä lähtökohdista ryhtyy RoR-kehitykseen, täytyy muistaa, että projektista tulee tehdä Ruby on Rails -projektin näköinen.
Convention over Configuration!
– Leo
