Case: Turku City Data
Tässä blogissa sukellamme funktionaalisen ohjelmoinnin saloihin ja erityisesti Elixir-nimiseen ohjelmointikieleen. Funktionaalinen ohjelmointi on nyt kovassa nosteessa, joten tarkastellaan teknologiaa, johon Kari tutustui asiakasprojektin kautta.
Asiakas ja nykyisin myös Qalmarin kumppani, Turku City Data, tilasi työkalun jolla simuloidaan kaupungin liikennevirtoja. Alkuun lähdettiin POC-tyyppisellä toteutuksella, jolla testattiin idean toimivuus sekä tavoiteltiin laajennettavaa rakennetta, jotta myöhemmin simulaatioon voidaan tuoda uudenlaisia toimijoita sekä ottaa kaupunkiympäristöä paremmin huomioon.
Kokemuksesi funktionaalisesta ohjelmoinnista?
Funktionaalisen ohjelmoinnin perusasiat olivat minulle tuttuja jo ennen projektin aloittamista. Olen omien harrasteprojektieni kautta tutustunut Haskell-kieleen. Elixir sen sijaan oli minulle uusi tuttavuus. Entuudestaan tuttuja juttuja olivat esimerkiksi Elixiristäkin löytyvät: pattern mathing sekä muuttujien immutabiliteetti. Pääsin siis hyvin nopeasti vauhtiin tutustumalla muutamiin tutoriaaleihin sekä artikkeleihin. Mieleeni jäi yksi erinomaisen hyvä artikkeli, jonka kirjoitti Jaakko Hannikainen Solitalta.
Elixirhän on siitä mielenkiintoinen ohjelmointikieli, että se toimii Erlang OTP -virtuaalikoneen päällä jossa ”Everything is a process”, eli prosessien luonti on suositeltavaa ja edullista. Sen takia se soveltuikin erinomaisesti kyseessä olevaan projektiin, jossa simuloidaan itsenäisten agenttien vuorovaikutuksia toisiinsa sekä ympäristöön.
Agenttipohjainen simulointi?
Agentti on yksittäinen toimija, joka on vuorovaikutuksessa toisiin toimijoihin sekä ympäristöönsä. Simulaatiossa on yhtäaikaisesti satoja tai jopa satoja tuhansia agentteja, jotka sitten vuorovaikuttavat toisiinsa ja simulaatioympäristöön. Se mitä agentti mallintaa, riippuu tietysti siitä mitä ollaan simuloimassa.
Kyseisessä projektissa mallinnettiin ensin toimija ja sille säännöt miten se vaikuttaa ympäristöönsä. Lisäksi mietittiin miten toimijat vaikuttavat toisiinsa. Tässä tapauksessa toimijoilla ei ollut suoraan vuorovaikutusta keskenään, vaan ne vaikuttivat toisiinsa lähinnä ympäristön välityksellä, joka toisaalta aiheutti vuorovaikutuksen takaisin toimijoille. Ympäristön mallintaminen tuntuu useimmiten olevan se vaikein asia sillä varsinkin fyysisessä maailmassa jossa elämme, on muuttujia lähes loputtomasti. Sen takia simulaatioon tehdään usein tiettyjä oletuksia ja pyritään yksinkertaistamaan olosuhteita.
Esimerkkinä tällaisesta simulaatiosta voisi ajatella vaikka sitä lähikulmilla toimivaa pientä markettia: Agentteina tässä simulaatiossa toimivat asiakkaat, joilla jokaisella on se oma kauppalista, josta ostokset löytyvät. Simulaatiossa agentit eli asiakkaat kulkevat kärryineen keräilemässä ostoksia kaupan käytävillä. Käytävät sekä kaupan muut tilat, kuten kassat, kuvaavat siten ympäristöä. Riippuen siitä, montako asiakasta on ollut tavoittelemassa makaroneja tai vastaavia kuivatuotteita samalta käytävältä samaan aikaan, on tämä saattanut aiheuttaa jonoja ja siten hidastaa ostoksien tekemistä. Lopuksi agentti jonottaa kassalle maksamaan ostoksensa ja tämän jälkeen simulaatio päättyy kyseisen agentin osalta. Samanaikaisesti agentteja on saattanut olla ostoksilla, kaupan koosta riippuen, kymmenen tai jopa tuhat agenttia. Simulaation lopputuloksena voidaan esittää optimointeja esimerkiksi tuotteiden sijoitteluun ja käytävien leveyksiin, tai kassojen määrään.
Minkälaisia vaatimuksia asiakkaalla oli toteutuksen suhteen?
Koska kyseessä oli asiakkaan ydintekemiseen liittyvä simulaattori, oli vaatimuksena simulaattorin laajennettavuus uudentyyppisillä toimijoilla. Ensimmäisessä vaiheessa oli kuitenkin tavoitteena todistaa ABM-simuloinnin vahvuudet asiakkaan liiketoiminnassa. Tämän takia lähdettiin liikkeelle proof of concept -ajatuksella ja tehtiin vielä rankkoja rajauksia, kuitenkaan vaarantamatta simulaatiotuloksen oikeellisuutta. Toisaalta sovittiin yhdessä, että mahdollisuuksien mukaan otetaan huomioon jatkokehitystarpeita ja suunitellaan ohjelmiston arkkitehtuuri sen mukaisesti, että sitä olisi helppo laajentaa esim. uudentyyppisillä toimijoilla.
Tekniset vaatimukset olivat lähinnä Elixir, sekä tietty tietokantaympäristö, joka asiakkaalla oli jo käytössä. Tietokantaa varten Elixiristä löytyi valmis kirjasto.
Retrospektiivi
Ennen projektin alkua tutustuin Elixiriin muutaman viikon ajan. Juuri ennen lomille lähtöä saatiin asiakkaan kanssa sovittua vielä yksityiskohdat speksien osalta ja sain tarvittavat tietokannat käyttööni, jotta voin lomilta palatessani heti aloittaa tehokkaan työskentelyn. Projekti luovutettiin ajallaan lähdekoodeineen sekä dokumentaatioineen asiakkaalle.
Asiakkaalle rakennettiin myös lyhyt roadmap, jossa projisoitiin mahdollista jatkokehitystä. Nyt esimerkiksi simulaation visualisointi jäi taka-alalle, mutta sitä silmällä pitäen simulaattorin rakenne ottaa huomioon mahdollisen visualisointikerroksen lisäämisen myöhemmin. Lisäksi toimijoiden simulointia varten mietittiin muutamia uusia toiminnallisuuksia, joiden avulla simulaatiosta saisi monikäyttöisempää.
Kaiken kaikkiaan projekti oli todella mielenkiintoinen ja sitä oli hauska tehdä. Opin jotain uutta funktionaalisesta ohjelmoinnista ja ennen kaikkea Elixiristä. Vaikka simulaattoreita olen ennenkin tehnyt, tämä konsepti oli minulle uusi ja sen kanssa oli mielenkiintoista työskennellä. Työn edetessä koin monia ahaa-elämyksiä jatkokehitysideoiden suhteen ja ne syntyivätkin kuin itsestään. Ja mikä parasta: asiakas oli tyytyväinen projektiin.
