Studio 4 portfolio

Erno Kyttänen, 7.5.2009

Johdanto

Tämä on Teknillisen korkeakoulun informaatioverkostojen T-111.2211 Studio 4 -kurssin portfolioni. Tavoitteena kurssilla oli tietokonegrafiikan peruskäsitteiden ymmärtäminen. Opittavia asioita olivat muun muassa tietokonetaide, piirtotoiminnot, animaatiot, informaation visualisointi, ohjelmien rakenteet, käyttöliittymät, vuorovaikutustekniikat ja kolmiulotteinen grafiikka. Kurssilla jokainen osallistui viiden harjoitustyön tekemiseen, joista ensimmäinen oli yksilötyö, yksi essee ja kolme muuta ohjelmoitavia ryhmätöitä. Ryhmätyöt sisälsivät graafisten sovellusten luomista ohjelmoimalla ongelmalähtöisen ryhmäoppimisen muodossa. Ohjelmointitehtävät toteutettiin 4-5 hengen voimin. Yhden harjoitustyön tekemiseen oli varattu aina kolme viikkoa aikaa. Ryhmäni nimi oli Karthago ja siihen kuuluivat itseni lisäksi Laura Kainulainen, Pyry Kröger, Anu Tarvainen, Otto Teinonen ja Sofi Weckman.

Seuraavassa esittelen kevään 2009 kurssilla syntyneet harjoitustyöt ja lopuksi vedän yhteen näkemykseni kurssista kokonaisuutena. Linkit harjoitustöihin, lähdekoodeihin ja kaikkiin muihin portfolion osioihin löytyvät yläreunan linkeistä. Oikean reunan linkkilistasta löytyy puolestaan muutamia linkkejä kurssiin kiinteästi liittyville WWW-sivuille.

Piirto-ohjelma

Harjoitus 0: Piirto-ohjelma

Kuvaus

Ensimmäinen ohjelmointiharjoitus oli yksilötyönä ohjelmoitava piirto-ohjelma, jonka tavoitteena oli opettaa käyttämään Processing-ympäristön perustoimintoja. Edellisestä ohjelmointikokemuksestani oli ehtinyt vierähtää jo muutama vuosi, joten oli mukavaa päästä jälleen ohjelmoimaan. Työ oli käytännössä yhden päivän projekti, joka venyi tosin useampaan tuntiin, sillä lähdekoodia syntyi lopulta noin 800 riviä. En laatinut etukäteen minkäänlaista suunnitelmaa sovellukselle, vaan ryhdyin suoraan ohjelmoimaan yhden toiminnon kerrallaan. Jonkinlainen suunnitelma olisi voinut olla hyvä, vaikka sovellus olikin melko yksinkertainen. Liian tarkan suunnitelman takia olisi kuitenkin saattanut käydä niin, että sovellukseen olisi tullut vähemmän työkaluja, koska harjoitustyön vaatimuksissa niitä vaadittiin ainoastaan muutama. Ilman suunnitelmaa piirto-ohjelmaan syntyi työkaluja ja ominaisuuksia sitä mukaan, kun niitä tuli mieleen. Tämän johdosta lopulliseen sovellukseen syntyi peräti 13 ominaisuutta. Vähempikin olisi riittänyt, mutta tulipahan samalla opeteltua Processingin perustoiminnot hyvin.

Kurssin kotisivuilla annettiin esimerkkejä siitä minkälaisia työkaluja sovellukseen olisi voinut toteuttaa. Yksi niistä oli useista kuvankäsittelyohjelmista tuttu maalipurkki, joka värjää kaikki naapuruston pikselit maalipurkin värisiksi. Tämä oli työkalu, jota yritin toteuttaa, mutta käytettävissä olevan vähäisen ajan takia en ehtinyt. Yksinkertainen maalipurkkini osasi kyllä värittää hiirellä klikatun kohdan viereiset pikselit, mutta ongelmia tuli siinä vaiheessa, kun piirtoalueella oli paljon piirrettyjä objekteja. Maalipurkin matemaattinen algoritmi ei tutkinut tarpeeksi hyvin sitä, mitkä pikselit kuuluu värittää ja mitä ei. Niinpä vaihdoin lopulta maalipurkkini työkaluksi, joka vaihtoi piirtoalueen taustaväriä.

Lopullisessa piirto-ohjelmassa voi valita erilaisia työkaluja, joilla voi piirtää piirtoalueelle. Joillekin työkaluille voi valita värin ja koon. Piirtoalueelle voi myös lisätä kahdenlaisia kuvia ja sisältöä voi peilata x- ja y-akseleiden suhteen. Lisäksi taustaväriä voi muuttaa ja halutessaan koko piirtoalueen voi tyhjentää.

Ohjeet

Kuvat

Piirto-ohjelma - Esimerkki 1 sovelluksen ominaisuuksista Piirto-ohjelma - Esimerkki 2 sovelluksen ominaisuuksista

SVG-standardin hyödyntäminen grafiikan luomisessa

Harjoitus 1: SVG-standardin hyödyntäminen grafiikan luomisessa

Ensimmäisen varsinaisen ryhmäohjelmoinnin tehtävänä oli tuottaa tietokoneavusteista taidetta. Ryhmämme päätyi tekemään metroa, joka seikkailisi eri maisemissa. Itse henkilökohtaisesti olin ensimmäisenä esseen kirjoitus vuorossa. Esseen kirjoituksen tehtävänannossa oli mainittu, että esseen pitäisi olla noin 10 000 merkkiä pitkä ja sisältää tieteellistä otetta sekä omaa pohdintaa. Valitsin esseen aiheekseni skaalautuvan vektorigrafiikan, SVG:n. Olin kuullut aiemmin SVG-standardista ja sen mahdollisuuksista tuottaa WWW-sivuille skaalautuvaa grafiikkaa, kuten taidetta. En ollut kuitenkaan koskaan ehtinyt tarkemmin perehtyä SVG:n nykytilaan, joten tämä oli mielestäni loistava tilaisuus siihen. Aihe oli itseäni kiinnostava ja lisäksi onnistuin löytämään muutaman hyvän lähteen, joten tekstiä syntyi nopeaan tahtiin.

Esseen lähteitä lukiessani selvisi aika nopeasti, että SVG:llä ei ollut hirveästi yhteyksiä kurssin ensimmäisen harjoitustyön aiheeseen eli tietokoneella luotavaan taiteeseen. Toki SVG:llä pystyi taidetta luomaan ja siitä myös muutamia esimerkkejä esseessäni mainitsin, mutta enemmän SVG:tä hyödynnetään tilanteissa, joissa grafiikkaa on tarkoitus kyetä esittämään eri resoluution omaavilla päätelaitteilla. Tällaisia ovat nykypäivänä erityisesti matkapuhelimet. Myöhemmin kurssilla huomasin, että SVG liittyi enemmän kurssin toiseen ryhmätyönä ohjelmoitavaan harjoitukseen, jossa aiheena oli informaation visualisointi. SVG on meinaan XML-pohjainen standardi vektorigrafiikan luomiseen, joten se soveltuu erinomaisesti skaalautuvien tilastojen, kaavioiden ja karttojen esittämiseen. Esseetä kirjoittaessani selvisi kuitenkin, että selainten tuki SVG:lle ei ole vielä riittävällä tasolla, jotta SVG:tä voitaisiin hyödyntää kunnolla WWW-sivuilla.

Metroasemien matkustajamäärät vuosina 1995 ja 2008

Harjoitus 2: Metroasemien matkustajamäärät vuosina 1995 ja 2008

Kuvaus

Kurssin toinen ryhmätyönä ohjelmoitava harjoitus käsitteli informaation visualisointia. Ohjelmoitavissa harjoitustöissä tehtävien arviointikriteereiksi kurssihenkilökunnan puolelta oli määritelty muun muassa työn tekninen laatu, algoritmien monipuolisuus, luovuus, innovatiivisuus, käytettävyys, toimivuus ja hyödyllisyys. Pyrimme ottamaan näitä asioita huomioon suunnitteluvaiheessa ja itse aiheen osalta päätimme jatkaa ensimmäisessä harjoitustyössä olleen teemamme eli metron ympärillä. Ohjelmoimme animaation, joka kuvaa matkustajamääriä metroasemilla vuosina 1995 ja 2008. Tätä varten tarvitsimme tiedot matkustajamääristä ja ne saimme Helsingin kaupungin liikennelaitokselta. Olisimme saaneet halutessamme myös tiedot muilta vuosilta, mutta esimerkiksi 2000-luvun muutokset ovat sen verran pieniä, että niiden väliset erot eivät olisi näkyneet sovelluksessamme. Niinpä valitsimme vain kaksi vuotta, joiden välillä oli selviä eroja ja pyrimme panostamaan enemmän siihen millä tavalla ne esitetään sovelluksessa.

Työ jaettiin käytännössä muutamaan isoon luokkaan, jotka toteutettiin yksi toiminto kerrallaan. Jokaisen toiminnon valmistuttua testasimme sen toimivuutta ja mikäli se toimi suunnitellulla tavalla, jatkoimme seuraavaan vaiheeseen. Sen sijaan jos testauksessa ilmeni ongelmia, niin korjasimme löydetyt ongelmat ennen seuraavaan vaiheeseen siirtymistä. Tällaisessa toteutustavassa on mielestäni hyvät ja huonot puolet. Sovelluksen jakamista vain muutamaan luokkaan voidaan pitää huonona, koska sen johdosta lähdekoodista ei tule parasta mahdollista. Tällöin sovelluksen laajennettavuus tai koodin osien kierrättäminen myöhemmin ei ole juurikaan mahdollista. Toisaalta tässä tapauksessa tiesimme, että sovellusta ei tulla myöhemmin laajentamaan ja sovellus oli muutenkin sen verran yksinkertainen, että ratkaisua voidaan pitää tähän tapaukseen sopivana. Lisäksi tällainen toteutustapa voi toimia silloin, kun tehdään prototyyppiä tiukalla aikataululla. Esimerkiksi jos työelämässä tulee tehtäväksi suunnitella prototyyppi, joka pitää esitellä tiettynä päivänä. Silloin on tärkeää saada aikaiseksi jotain mitä näyttää, koska pahinta on mennä esittämään toimimatonta sovellusta. Tällä tavalla toteuttamalla varmistetaan koko ajan se, että saadaan jotain näkyviin myös näytölle. Jos vain koodattaisiin paloja, jotka yhdistettäisiin juuri ennen aikarajaa, niin yhdistämisessä saattaisi ilmetä sellaisia ongelmia, joita etukäteen ei osattu huomioida. Koko ajan testaamalla nähdään myös kuinka raskas sovelluksesta on tulossa. Jos jossain testissä ilmenee, että sovelluksesta on tulossa liian raskan testikoneen pyöritettäväksi, niin voidaan peruuttaa muutama askel taaksepäin ja keventää sovellusta ennen eteenpäin jatkamista. Koko ajan myös nähdään missä vaiheessa työtä ollaan menossa ja mitä pitää vielä toteuttaa. Niinpä tällainen toteutustapa sopii mielestäni prototyyppien, mutta ei lopullisten tuotteiden toteutukseen.

Ohjeet

Kuvat

Metroasemien matkustajamäärät vuosina 1995 ja 2008 - Alkunäkymä Metroasemien matkustajamäärät vuosina 1995 ja 2008 - Kuva sovelluksesta

Kalapeli

Harjoitus 3: Kalapeli

Kuvaus

Kolmannen ohjelmoitavan harjoitustyön aiheena olivat vuorovaikutustekniikat. Tarkoituksena oli toteuttaa sovellus, jossa käytettäisiin hyödyksi jotain muuta kuin perinteisiä ohjaimia, kuten hiirtä ja näppäimistöä. Harjoitustyön aiheemme rajautuivat varsin nopeasti perinteiseksi peliksi, jonka toteuttaisimme uudenlaisella ohjauksella. Pelimaailmaksi valittiin vesiympäristö, jossa ideana on ohjata kalaa. Alusta lähtien peliin haluttiin myös kaksinpelin mahdollisuus, jotta pelistä tulisi entistäkin viihdyttävämpi. Yksin- ja kaksinpelissä on kummassakin tavoitteena ensinnäkin selvitä hengissä ja se tapahtuu väistelemällä vastaantulevia pahoja kaloja ja ylhäältä tippuvia kiviä. Samalla tavoitteena on kerätä kolikoita, joita keräämällä kuusi kappaletta selviytyy voittajana maaliin. Vedessä tulee vastaan myös kaljaa, sieniä ja superhattuja. Kaljasta pelaajan y-akseli menee sekaisin. Sieni sekoittaa puolestaan x- ja y-akselit ja superhattu muiden y-akselin. Lisäksi pelissä voi ampua kuplia, joilla estätetään muita kaloja liikkumasta.

Kaikki objektit toteutettiin sovelluksessa perinnöllisyyden avulla. Täten esimerkiksi kalat ja kerättävät esineet ovat kummatkin merenelävän alaluokkia. Kolikko ja kalja ovat puolestaan kerättäviä esineitä. Ohjaimina sovelluksessa käytettiin näppäimistöä, kameraa, mikrofonia ja Applen MacBook-koneista löytyvää kiihtyvyysanturia. Näppäimistö edustaa perinteistä ohjainta, jolla tietokoneelle annetaan komentoja. Se toteutettiin sovellukseen, jotta peliä voivat pelata sellaisetkin, joilla ei ole mahdollisuutta käyttää muita ohjaimia. Näppäimistön avulla voidaan liikuttaa kalaa ja ampua kuplia. Jos tietokoneesta löytyy kamera, niin kalaa on mahdollista liikuttaa myös kameran kautta. OSX-käyttöjärjestelmissä kameran käyttäminen toimii suoraan, mutta Windows-käyttöjärjestelmiin pitää asentaa QuickTime ja WinVDIG 1.01 –ohjelmat. Kameran kautta tapahtuva ohjaus perustuu värintunnistukseen, joten se vaatii kameran kalibroimista pelin alussa. Kaksinpelissä kameran kautta tapahtuvan ohjauksen vaatimat tunnistunalueet ovat päällekkäin, mutta eivät kuitenkaan aivan kamerakuvan reunasta reunaan. Ohjaus toimii yksivärisellä esineellä. Kuplien ampumiseen näppäimistön lisäksi voi käyttää mikrofonia tai tärinäohjeinta. Mikrofonia käytettäessä kuplan suunta määräytyy äänen voimakkuuden mukaan ja tärinäohjaimessa tärinän perusteella.

Teknisen toteutuksen osalta kalapelissä pyrittiin noudattamaan MVC-arkkitehtuurin (model-view-controller) mukaista periaatetta. Sen tarkoituksena on erottaa malli, näkymä ja ohjain toisistaan. Mallin tehtävänä on huolehtia varsinaisesta tiedon käsittelystä, näkymä vastaa käyttöliittymän esitystavasta ja ohjain vastaanottaa käyttäjän sovellukselle antamia käskyjä. MVC-arkkitehtuurin hyödyntämisestä saadaan paljon etuja, joista työn aikana selkeimmin esille nousi se, että malli voidaan toteuttaa riippumatta sovelluksen muista osista. Tämä mahdollisti sen, että sovellukseen voitiin liittää helposti useita erilaisia ohjaimia. Huonoksi puoleksi MVC-arkkitehtuurille voi muodostua isoissa projekteissa se, että sovelluksesta tulee liian hajanainen. Meidän työmme osalta MVC-arkkitehtuurin hyödyntämisestä oli kuitenkin vain etua ja MVC:n periaatteen noudattamisen voidaan katsoa onnistuneen hyvin, vaikka pientä lipsumista lopussa tapahtuikin. Lopullista peliä ei julkaistu WWW-sivuilla Java Appletin muodossa, koska vaihtoehtoisia ohjaimia, kuten kameraa ei kyetty laittamaan toimimaan selaimen kautta.

Ohjeet

Kuvat ja videot

Kalapeli - Hahmotelma Kalapeli - Alkunäkymä Kalapeli - Kuva yksinpelistä Kalapeli - Kuva kaksinpelistä Kalapeli - H.264-video kalapelistä (mp4)

Linna

Harjoitus 4: Linna

Kuvaus

Kurssin viimeisen harjoitustyön aihe oli kolmiulotteisen grafiikan tuottaminen ohjelmoimalla. Opittavia asioita olivat muun muassa geometriset transformaatiot. Tämä tuntui olevan kurssin harjoitustöistä kaikista mielekkäin, koska tässä joutui miettimään miten kappaletta kannattaa kolmiulotteisessa ympäristössä pyörittää, jotta se käyttäytyy toivotulla tavalla.

Emme osanneet etukäteen hahmottaa kuinka paljon saisimme kolmessa viikossa aikaan, joten valitsimme harjoitustyön aiheeksemme linnan. Linna oli siinä mielessä hyvä valinta, että sitä pystyi laajentamaan sen mukaan miten aikaa riitti. Käytännössä toteutimme koko linnan yhteisissä koodausistunnoissa kolmen päivän aikana. Se voidaan todeta näin jälkitäteen erittäin onnistuneeksi ratkaisuksi, sillä siinä sai koko ajan muilta apua, jos vastaan tuli pieniäkin ongelmia. Lisäksi siinä pystyi jatkuvasti vaihtamaan ajatuksia siitä, mitä kaikkea sovellukseen voisi toteuttaa. Toteutimme näissä istunnoissamme myös parikoodausta, jota kurssin henkilökunta oli jo kurssin alussa suositellut kaikille ryhmille. Se osoittautui erittäin tehokkaaksi työskentelymuodoksi.

Itse sovellus jaettiin mallinnettaviin osiin, joten jokainen pääsi mallintamaan jotain objekteja linnaamme. Mallinnettavia asioita olivat maaperä, muuri, torni, liehuva lippu, puu, nouseva portti, laskusilta, talo ja kyltti. Lisäksi maailmaan mallinnettin aurinko, joten maailmassamme on vuoroin yö ja vuoroin päivä. Näkymää voi pyörittää ja siirtää hiirellä ja näppäimistöllä alla olevien ohjeiden mukaisesti.

Ohjeet

Kuvat

Linna - Linna ylhäältä päivänvalossa Linna - Linna edestä iltahämärässä

Yhteenveto

Lähtökohta

Näin jälkikäteen on erityisen hienoa huomata, miten erilaisia sovelluksia saimmekaan neljässä kuukaudessa aikaiseksi. En olisi uskonut tammikuussa kurssin alkaessa, että toukokuun alussa ollaan todella tehty näin hienoja juttuja. Kevään lukujärjestykseni oli aika täynnä kursseja, joten tammikuussa mietin riittääkö aikani kaikkeen. Tämä kurssi oli kuitenkin selkeästi erilainen kuin muut kurssit ja siinä mielessä se toi mukavaa vaihtelua kevääseen. Kaikki harjoitustyöt tuntuivat syntyneen yllättävän nopeasti, kun osasi vain keskittyä yhteen tehtävään kerralla, eikä miettinyt liikaa tulevaa.

Kurssin aikataulu oli kuitenkin haastava sellaisena hetkenä, jolloin samoille viikoille sattui paljon myös muiden kurssien harjoitustöiden palautuksia. Se johti siihen, että tiettyjä asioita joutui yksinkertaistamaan, kun ihan kaikkea ei ehtinyt tehdä. En kuitenkaan usko, että ajan lisääminen juurikaan muuttaisi mitään. Se vain pidentäisi kurssia ja harjoitustöistä tulisi laajempia. Samalla lisääntyisi myös vapaa-aika, jolloin unohtaisi mitä pitäisi seuraavaksi ohjelmoida. Tässä mielessä kurssin aikataulua voi pitää varsin toimivana, koska yleensä juuri tiukalla aikataululla tulee parasta jälkeä. Opintopisteitä kurssista sai neljä, joten jos pelkästään pisteitä laskeskelisi, niin varmasti löytyisi helpompiakin kursseja ansaita neljä pistettä. Mielestäni kursseja ei tule kuitenkaan suorittaa pelkän hyötysuhteen perusteella, vaan saatuja oppeja ja kokemuksia kannattaa myös arvostaa. Tällä kurssilla joutui tekemään töitä, mutta tuli myös paljon oppia. Lisäksi mielenkiintoisen kurssin eteen jaksaa aina tehdä töitä.

Järjestelyt

Jokainen harjoitustyö alkoi luennolla, jossa perehdyttiin aiheeseen kurssihenkilökunnan johdolla. Sen jälkeen ideoitiin aiheeseen sopiva oma idea, joka ensin suunniteltiin ja sen jälkeen toteutettiin. Luentojen parasta antia olivat niillä näytetyt esimerkit, joista sai paljon ideoita ja näki mitä kaikkea kurssin harjoitustyön puitteissa on mahdollista toteuttaa. Useita luennolle varattuja aikoja käytettiin myös ryhmätöiden edistämiseen ja se auttoi ainakin meidän ryhmää, joka osallistui melko kattavalla kokoonpanolla jokaiselle luennolle.

Demotilaisuus kurssin päätteeksi oli hyvä katsaus kaikkeen mitä kurssin aikana tehtiin. Toinen vaihtoehto tähän olisi ollut se, että edellisen kierroksen harjoitustyöt olisi esitelty aina ennen seuraavaa harjoituskierrosta. Se ei ehkä aikataulullisesti olisi ollut mahdollista, mutta siinä olisi ehditty käydä syvemmin läpi kaikkien ryhmien kaikki sovellukset ja niiden oivallukset. Niistä olisi varmasti oppinut myös paljon ja ehkä saanut uusia ideoita aina seuraaviin harjoitustöihin.

Kurssin assistentit olivat erityisen päteviä juuri tälle kurssille. Kurssin henkilökunta oli myös kiinnostunut ryhmien töistä, joten apuakin sai todella helposti. Tiedotuskin toimi kurssin aikana, mutta sen sijaan kurssin alussa kotisivuilta puuttui oleellisia tietoja. Kurssin aikana niitä sitten ilmestyi sinne pikku hiljaa, mutta sen verran tästä voisi seuraavaan vuoteen parantaa, että jo kurssin alussa kotisivut olisivat kunnossa.

Sisältö

Kurssin sisältö on mielestäni hyvä, sillä kurssi oli monipuolinen katsaus tietokonegrafiikkaan. Hienoa oli erityisesti kurssin vaihtelevat aiheet eri harjoitustöiden väleillä. Kurssilla oli myös vapaus valita mitä halusi tehdä, joten ryhmät pystyivät itse vaikuttamaan harjoitustöiden laajuuteen. Vaatimukset pystyi täten asettamaan ryhmän osaamistason mukaan, joka on mielestäni se järkevin tapa asettaa haasteita. Jos vaatimustasot asetettaisiin tiukasti kurssin henkilökunnan puolelta, niin joku ryhmä selviytyisi haasteista helposti, mutta toiselle ryhmälle samat haasteet voisivat tuntua lähes ylitsepäätemättömiltä. Vapaus mahdollisti myös sen, että oli mahdollista valita aihe, joka kiinnosti erityisesti itseä ja täten myös työskentelystä tuli mielekästä. Lisäksi harjoitustöissä kannustettiin käyttämään luovuutta ja sitä ainakin yritettiin käyttää sopivissa rajoissa, mutta ehkä sitä olisi voinut viljellä rohkeamminkin.

Ainoa kurssin vapauteen ja luovuuteen liittyvä ongelma oli arvosanan muodostuminen. Kun ryhmät saivat itse vapaasti päättää mitä tekivät, niin töistä tuli hyvinkin erilaisia, jolloin niitä on vaikea verrata toisiinsa. Kurssin kotisivuilla oli etukäteen määritelty muutamia kohtia, joita töissä arvosteltiin. Jotkut ryhmät olivat kuitenkin tietoisesti tehneet sellaisia ratkaisuja, jotka eivät täyttäneet kaikkia kriteerejä ja kärsivät sen sitten arvosanassa, vaikka erinomaista työtä tekivätkin. Niinpä näitä arviointikriteereitä olisi voinut tuoda enemmän esille kurssin alussa, jotta kaikki olisivat olleet tietoisia niistä.

Tällä hetkellä on vaikea itse arvioida sitä mitä lopulta jäi käteen kurssin sisällöstä. Luultavasti se selviää vasta sitten, jos tulevaisuudessa joutuu tai pääsee ohjelmoimaan lisää tietokonegrafiikkaa. Ainakin tässä sai laajan katsauksen tietokonegrafiikkaan, joten siitä kokemuksesta on varmasti hyötyä siinä mielessä, että osaa ajatella tietokonegrafiikastakin laajemmin kuin mitä aiemmin osasi.

Harjoitukset

Kurssilla tehtiin useita pieniä harjoitustöitä, joka oli ehdottomasti hyvä verrattuna siihen, että oltaisiin tehty vain yksi iso harjoitustyö. Useammassa pienessä, kun oppii enemmän erilaisia asioita ja myös motivaatio pysyy todennäköisesti parempana, kun tulee koko ajan uusia haasteita. Lisäksi kurssin aikana pääsee ideoimaan useaan kertaan aina harjoitustyön vaihtuessa. Harjoitustöistä informaation visualisointi oli teorian näkökulmasta mielenkiintoisin aihe ja ohjelmoinnin näkökulmasta mielenkiintoisemmaksi muodostui kolmiulotteisen grafiikan pyörittäminen.

Yhdessä isossa harjoitustyössä voisi olla se ongelma, että suunnitteluvaiheen jälkeen se olisi pelkkää ohjelmoimista, jolloin on isompi riski siihen, että motivaatio alkaa jossain vaiheessa laskemaan. Tällä kurssilla ohjelmointiharjoitukset tehtiin vieläpä ryhmänä, joten pienistä tehtävistä oli myös se hyöty, että rooleja ja vastuista voitiin vaihdella tehtävien väleillä. Tietenkään työtunnit eivät ikinä jakaudu tämänkaltaisissa töissä tasaisesti, koska toiset ovat nopeampia ja parempia ohjelmoimaan kuin toiset. Kaikki kuitenkin osallistuivat omalla panoksellaan ja varmasti jokainen myös oppi jotain uutta. Henkilökohtainen motivaationikin vaihteli kurssin aikana aina viikosta riippuen. Välillä tein enemmän ja välillä vähemmän. En usko sen kuitenkaan riippuneen pelkästään tästä kurssista, vaan siihen vaikuttaa luonnollisesti kaikki henkilökohtaisenkin elämän asiat.

Muilla samaan aikaan suoritettavilla kurssilla oli myös valtava vaikutus siihen, kuinka paljon ohjelmointiin ehti käyttää aikaa milläkin viikolla. Välillä oli tenttejä ja muiden kurssien harjoitustöitä, joita piti myös edistää, joten niinä viikkoina panokseni tälle kurssille oli alle tavoitteen. Toisaalta sitten oli muutamia viikkoja ja erityisesti yksittäisiä päiviä, jolloin tuli ohjelmoitua monta tuntia yhteen menoon. Ohjelmointi tuntuikin sujuvan parhaiten juuri siten, että otti yhden päivän, jolloin keskittyi pelkästään tähän kurssiin. Tämä johtui ehkä siitä, että sai pidettyä koko ajan mielessä mitä pitää tehdä, jotta saa tietyn toiminnon toteutettua. Jos piti useamman välipäivän ohjelmoinnista, niin siinä ehti unohtaa aina jotain oleellista. Varsinkin jos muut ryhmäläiset olivat ohjelmoineet paljon juuri niinä minun pitäminä välipäivinä, niin muiden koodin tulkitsemiseen kului paljon aikaa, vaikka se olisikin ollut hyvin kommentoitu. Näin jälkikäteen voinkin todeta, että ohjelmoinnin näkökulmasta kurssin suurin haaste oli toisen koodin ymmärtäminen, koska saman asian voi koodata monella eri tapaa. Niinpä aina välillä kävi niin, että toinen ei heti ymmärtänyt tapaa, jolla jokin toiminto oli tehty.

Jokainen kirjoitti kurssilla myös yhden henkilökohtaisen esseen. Jos esseen tavoitteena oli tukea muun ryhmän ohjelmointia, niin se epäonnistui meiltä jokaisella kierroksella. Tosin emme siihen pyrkineetkään, vaan työ meni siten, että esseetä kirjoittanut ryhmäläinen keskittyi siihen ja muut ohjelmoimiseen. Lisäksi monen esseen kirjoittaminen jäi viimeisiin iltoihin, joten ei siitä paljon apua olisi ryhmälle edes ollut, vaikka aihe olisi sopinut sovellukseen. Esseen kirjoittaminen oli kuitenkin hyvä osa kurssia, koska siinä oppi eniten teoriasta, jota kurssi muuten sisälsi todella vähän. Ryhmät olivat myös sen verran isot suhteessa toteutettaviin sovelluksiin, että yksi tai kaksi pystyi aina hyvin irrottautumaan koodaamisesta esseen pariin.

Yhdessä vaiheessa kurssia tuli mieleen, että olisiko ollut järkevämpää, jos esseetkin olisi kirjoitettu ryhmänä. Silloin essee olisi voinut käsitellä laajemmin jotain tietokonegrafiikkaan liittyvää asiaa, josta olisi myöhemmin kurssilla ohjelmoitu harjoitustyö. Silloin esseen olisi saanut yhdistettyä kiinteemmin itse ohjelmoimiseen ja siitä olisi ollut enemmän hyötyä, koska teorian pohjalta olisi todennäköisesti ollut helpompi lähteä rakentamaan itse sovellusta. Jokaisen ryhmän esseen teoriaosuudet olisi voitu esitellä lopuksi demotilaisuudessa muille ryhmille harjoitustöiden esittelyn yhteydessä. Silloin ryhmät olisivat opettaneet toisiaan. Samalla sitä olisi itsekin oppinut enemmän tietokonegrafiikkaan liittyvää teoriaa, koska nyt sen osuus jäi todella pieneksi. Kyseessä on myös ryhmätyökurssi, joten mielestäni silloin olisi mielekästä, että kaikki harjoitukset tehtäisiin ryhmänä.

Yksi kurssin osatehtävistä oli myös tämän portfolion luominen. Portfolion luomisessa oli ongelmana se, että palvelimella, jossa opiskelijoiden kotisivut sijaitsevat, ei voi ajaa mitään varsinaisia ohjelmointikieltä, eikä opiskelijoilla ole käytössään tietokantaakaan. Näin ollen on mahdotonta toteuttaa dynaamista portfoliota, jossa kaikki sisältö sijoitettaisiin tietokantaan. Tämä ei ole tietenkään pelkästään tämän kurssin asia, vaan koko Teknillistä korkeakoulua vaivaava ongelma. Mielestäni etenkin informaativerkostojen opiskelijoille olisi kuitenkin hyödyllistä, jos tarjottaisiin mahdollisuus toteuttaa dynaamisia WWW-sivuja, koska kaikki työelämän WWW-sivut ovat kuitenkin sellaisia. Tämä olisi siten loistavaa tilaisuus myös sen asian harjoittelemiseen, vaikka se ei varsinaisesti tämän kurssin ydinasia olekaan.

Työkalut

Kurssin grafiikat ohjelmoitiin Processingilla ja tuloksena oli Java Appletteja. Processing on ohjelmointiympäristö, joka on suunniteltu graafisten installaatioiden tekemiseen ohjelmoimalla. Se perustuu avoimeen lähdekoodiin ja sen ovat kehittäneet MIT:n medialaboratoriossa Casey Rears ja Benjamin Fry. Processing-ohjelmointiympäristöön oli myös mukavaa tutustua, kun en ollut aiemmin siitä kuullut. Sen perustoimintojen oppiminen oli suhteellisen helppoa, joten sillä kykeni luomaan nopeasti yksinkertaisia graafisia sovelluksia. Sen sijaan mukana tullut editori osoittautui kehnoksi muun muassa huonojen virheilmoitusten takia. Näin emme juurikaan käyttäneet sitä, vaan käytimme ohjelmointiin Eclipse-ohjelmointiympäristöä ja ryhmäohjelmoinnissa hallitsimme koodia Subversio-versionhallintaohjelmalla, joka liitettiin Eclipseen Subclipse-clientilla. Koodin hallitseminen versionhallinnan kautta osoittautui todella toimivaksi ratkaisuksi. Sitä kautta kaikilla oli käytettävissä koko ajan uusin versio työstämme.

Vaikka Processing toimiva ohjelmointiympäristö onkin, niin todennäköisesti en tule Processingia jatkossa juurikaan käyttämään. Sillä saa kyllä aikaiseksi todella helposti yksinkertaista grafiikkaa, joten yksittäiseen digitaaliseen taideteokseen sitä pystyy hyvin hyödyntämään, kuten huomasimme jo kurssin ensimmäisellä luennolla, jolla käytiin tutustumassa digitaalisiin näyttämöefekteihin suurjännitehallissa. Verkkoon Java Appletien tuottaminen ei kuitenkaan ole mielestäni järkevää, koska niitä ajetaan niin sanotussa hiekkalaatikossa. Niissä ei pääse käsiksi lähdekoodiin, joka estää niiden uudelleen kierrättämisen tai hyödyntämisen osana jotain toista sovellusta. Lisäksi monesta ohjelmasta tuntui tulevan yllättävänkin raskaita, vaikka koodia ei ollut mitenkään erityisen paljon.

Työskentely

Ryhmämme pyrki käyttämään kurssin sisältämiä luentoja hyödykseen työn edistämiseksi. Luentoja yhteydessä pidettiin yleensä aina palaveria, jossa käytiin läpi mitä on saatu aikaiseksi ja mitä pitäisi seuraavaksi tehdä. Samalla sovittiin työnjaosta ja aikataulusta. Lisäksi kommunikointiin käytettiin IRCiä, jonka kautta sovittiin tapaamisia. Varsinainen suunnittelu oli kuitenkin helpointa kasvokkain, mutta suunnitteluvaiheen suurin ongelma oli siinä, että ei ollut käsitystä paljonko jonkin tietyn jutun toteuttaminen vaatisi työtunteja. Esimerkiksi kolmiulotteinen grafiikan ohjelmoiminen oli helpompaa kuin mitä etukäteen odotin, joten jos sen olisi tiennyt etukäteen, niin sovelluksesta olisi voinut suunnitella monimutkaisemman. Tarvittavan ajan oikeaan arviointiin olisi tarvittu enemmän kokemusta.

Ryhmätyöskentelystä saatuja oppeja oli muun muassa se, että ryhmätyöskentely on syytä aloittaa ajoissa, koska ihmisillä on henkilökohtaisia menoja, jolloin kaikki eivät ole käytettävissä viimeisinä päivinä ennen palautuksen aikarajaa. Täten on hyvä verrata heti harjoitustyön alussa kalentereita ja etsiä yhteiset vapaat hetket sovelluksen toteuttamiseen. Parhaiten tunnuimme onnistuvan tässä viimeisen harjoitustyön kohdalla.

Viimeisen harjoitustyön kohdalla harjoitimme myös eniten sosiaalista ryhmäkoodaamista, josta kerroin viimeisen harjoitustyön yhteydessä. Näin jälkikäteen on tietysti helppoa olla viisas ja todeta, että ryhmä- ja parikoodausta olisi pitänyt kokeilla heti ensimmäisestä harjoitustyöstä lähtien. Se oli erinomainen ja pelkästään positiivinen kokemus, koska siinä joutui selittämään suullisesti mitä tekee, jotta toinen pysyi kärryillä. Sitä kautta sitä tuntui itsekin ymmärtävän miksi toteutti jonkin asian tietyllä tavalla. Se oli kokemus, jota suosittelen vilpittömästi kaikille muille ja aion ehdottomasti hyödyntää sitä itsekin tulevaisuudessa muiden projektien yhteydessä, jos suinkin vain mahdollista.

Kiitokset hyvästä kurssista kaikille kurssille osallistuneille, Tassulle ja assistenteille. Hyvä me.

Arvostelu

Seuraavaan taulukkoon on kerätty kurssin sisältämät tehtävät, niiden työskentelymuodot, painokertoimet ja niistä saadut arvosanat. Painokertoimen ja arvosanan pohjalta on laskettu pisteet, joista yhteenlaskemalla on saatu kurssin lopullinen arvosana. Kurssin arvosteluasteikko oli normaali nollasta viiteen, mutta yksilöohjelmointi arvioitiin hyväksytty/hylätty periaatteella.

Tehtävä Työskentelymuoto Painokerroin Arvosana Pisteet
Harjoitus0 Yksilöohjelmointi - Hyväksytty -
Harjoitus1 Yksilötyö, essee 0,2 4 0,8
Harjoitus2 Ryhmäohjelmointi 0,2 4 0,8
Harjoitus3 Ryhmäohjelmointi 0,2 3 0,6
Harjoitus4 Ryhmäohjelmointi 0,2 5 1,0
Esitys Ryhmätyö 0,1 4 0,4
Portfolio Yksilötyö 0,1 5 0,5
Arvosana ≈ 4