Lopuksi

Nyt se sitten alkaa olla viimeisiä taputteluja vaille valmis, Studio 1 -kurssi nimittäin. Ei voi muuta sanoa kuin, että “Huh, huh!”. Tuohon kiteytyykin päällimmäiset tuntemukseni kurssin suorittamisen jälkeen. Vaikka tuosta lausahduksesta varmaan moni päätteleekin, että olen helpottunut kurssin ollessa ohi, niin toisaalta hyvillä mielin todeta oppineeni kurssilla todella paljon ohjelmoinnista, ja siksi tästä kurssista jäi minulle hyvät fiilikset. Haluan nyt heti kiittää ryhmäni jäseniä ja assaria Johannesta yhteisistä OLO-hetkistä. Teidän kanssa oli mukava oloilla ja suorittaa kurssia!

Ensimmäisissä OLO-tapaamisissa ei kukaan oikein tiennyt, miten ryhmissä pitäisi työskennellä ja mitä ylipäätänsä kurssilta olisi saattanut odottaa. Tämän tiedon puutteen tuoman alkuhämmennyksen voitettuamme, ryhmässämme syntyi joka viikko hyväntuulista ja vilkasta keskustelua silloisella hetkellä työn alla olleista aiheista. Itselleni, ohjelmoinnin vasta-alkajalle, moni asia oli ja on edelleen tietotekniikan osalta uutta ja vierasta, mutta pyrin OLO-sessioissamme imemään mahdollisimman paljon tietoa itseeni, ja mielestäni siinä hyvin onnistuinkin. Ryhmämme vanhemmat ja muutkin tietoteknisesti tietävämmät jäsenet pitivät kyllä huolen siitä, että sain joka viikko uutta tietoa muistiini. Vaikka informaatiotulva olikin OLOjen osalta suuri, ei tiedon janoni hiipunut silti yhtään, sillä alan kiinnostavuuden kautta uutta, ja välillä myös vähän hämmentävää asiaa oli mielekästä oppia. Harmittavaa oli, että OLO-ryhmämme jäsenten määrä kutistui kursin edetessä lopulta puoleen alkuperäisestä vahvuudesta. Ryhmän koon pieneneminen aiheutti keskusteluiden monipuolisuuden katoamista ja sen, että OLO-tapaamisiin valmisteltavat esitykset muuttuivat jokaisen osalla aihealueiltaan laajemmiksi, minkä seurauksena moneen asiaan saatiin vain pintaraapaisu.

Suurimman osan kurssin suorittamisen vaatimasta ajasta veivät OLOjen sijaan kuitenkin itse harjoitustyöt, joiden tekeminen tuotti ainakin itselläni välillä harmaita hiuksia, kun kaikki tehtävänannot eivät olleet aivan sieltä selkeimmästä päästä. Olisin toivonut ehkä vähän aloittelijaystävällisempää ohjeistusta tehtävien osalta, mutta varmasti tämän kurssin tarkoituksena oli osoittaa ja totuttaa opiskelijat siihen, että työelämässäkään asiakkaan ohjelmalle antamat kriteerit ja ohjeet eivät aina ole yksiselitteisiä. Itse opin sen tämän kurssin myötä, sillä samaan aikaan Studion kanssa rinnakkain suoritetulla Ohjelmointi 1 -kurssilla kaikki asiat selitettiin kädestä kiinni pitäen, jotta myös tällaiset ohjelmointitaidoiltaan vajavaiset opiskelijat ymmärtäisivät käsiteltävät asiat. Se peruskurssin tarkoituksena onkin ja hyvä niin, joten siihen verrattuna tämä Studio 1 oli kuin toiselta planeetalta tempaistu. Tämä kurssi oli nimittäin vaikeustasoltaan ja työmäärältään täysin omaa luokkaansa, jos sitä vertaa muihin tähän mennessä suorittamiini yliopistokursseihin.

Harjoitustöiden osalta ensimmäisen kierroksen UML-kaavion sisältö ja merkitys ohjelmoinnissa eivät vieläkään ole hahmottunut minulle aivan kokonaan. Tämän lisäksi myös kolmannen kierroksen filtterit tuntuivat aluksi ylipääsemättömän vaikeilta toteuttaa, ja koodaamista ei yhtään helpottanut heti tehtävänannon alussa käsitelty Fourier-muunnos, joka tuntui täysin heprealta. Tähän kierrokseen kului minulla varmasti eniten aikaa muihin tehtäviin nähden, luukun ottamatta kurssin päättänyttä grande finaalia, johon oli aikaisemmista kierroksista poikkeavasti annettu aikaa kolme viikkoa ja jonka pisteytys myös erosi muista tehtävistä. Tuota kuudennen kierroksen peliohjelmointia oli mielestäni ehdottomasti hauskinta ja mukavinta tehdä, sillä siinä pääsi työstämään graafista käyttöliittymää sekä ilmettä koodin kautta ja oman työn tuloksen näki heti. Tehtävän toteuttamiseen annettiin myös muutamaa ohjeistusta lukuun ottamatta vapaat kädet, joten edellisten kierrosten tapaan ei tarvinnut tuskailla valmiiden koodin pätkien kanssa. Ohjelmoinnin aloittaminen “tyhjästä” ei kuitenkaan ollut helppoa vasta-alkajalle (minulle), eikä mielestäni sellaista pitäisi edes vielä vaatia tässä vaiheessa opintoja.

Studio- ja Ohjelmointi 1 -kurssilla oli myös havaittavissa ajoittaisia synkronointiongelmia, sillä esimerkiksi silmukat ja GUI käsiteltiin täällä Studiossa ennen kuin niitä oli nähtykään peruskurssilla. Mielestäni asiat olisi ensin pitänyt opiskella peruskurssilla ja vasta sitten soveltaa Studiossa, sillä esimerkiksi silmukat kasvattivat toisen kierroksen koodauksen ja dekooodauksen vaikeustasoa entisestään. Toisaalta niiden käytön opettelu Ohjelmointi 1:ssä tuntui naurettavan helpolta Studion harjoitustyön jälkeen.

Kurssin ehkä yksi mieleenpainuvimmista kokemuksista oli yli puolen vuorokauden mittaiset lauantain deadlinea edeltävien perjantaiden koodaussessiot Paniikissa, ja joskus ihan oikeasti paniikissa, kun jokin tehtävän osa ei meinannut aueta. Muutamana perjantaina sessiot venyivät jopa yön yli aamuun, kun deadlinet hengittivät pahasti niskaan. En ollut kuitenkaan ollut yksin tässä tilanteessa, sillä Paniikissa oli myös muita kohtalotovereita, joiden henkisellä tuella jaksoin suorittaa kurssin kunnialla loppuun asti. Yhdessä panikointi lievitti ainakin minun stressiäni tehtävien suhteen, kuitenkaan sitä kokonaan poistamatta. Luulen, että myös kaverini ovat tunteneet osaltaan osin samoin.

Nyt lopulta voin rehellisesti sanoa oppineeni näiden kahden ohjelmointikurssin myötä koodaamaan ainakin perustasolla, sillä ennen elokuista Espooseen muuttoani en ollut kirjoittanut riviäkään koodia, saati sitten kuullut Scalasta, muista ohjelmointikielistä senkin edestä. Tämä Studio-kurssi on konkretisoinut huomattavasti käsitystäni ohjelmoinnista, sillä “oikeassa elämässä” ohjelmointiin ei anneta vaiheittaisia ohjeita, vaan koodin tuottaminen pitää aloittaa puhtaalta pöydältä. Kurssin avulla opin myös todella paljon yleistä tietoa ja vähän enemmänkin tietotekniikasta, jonka takia ylipäätänsä hakeuduin Otaniemeen.

Tähän on hyvä lopettaa, ja lopuksi haluan toivottaa kaikille oikein hyvää, rauhallista ja lämmintä joulua! Etenkin tuota lämpöä tuntuu täällä eteläisessä Suomessa vielä riittävän, mutta toivottavasti jouluksi saadaan pientä pakkasta ja valkea maa! 🙂


Markus Pajari

Tehtävä 5 – Tietokonegrafiikka ja vuorovaikutus (Sokoban)

Kurssin viidennen kierroksen harjoitustyön aiheena oli ohjelmoida yksinkertaistettu versio klassikoksi muodostuneesta Sokoban-ongelmanratkaisupelistä. Sokobanissa pelaaja siirtelee laatikoita tai muita vastaavia esteitä ennalta määrättyihin paikkoihin, ja pelin läpäistäkseen pelaajan on saatava siirrettyä kaikki laatikot merkityille paikoille. Pelin osatehtävien ratkaisemiseksi pelaajan täytyy aina miettiä, millaisia seurauksia tietyn esteen siirtämisellä on jatkoa ajatellen.

Scala-muotoinen ohjelmointitehtävämme oli tosiaankin karsittu versio alkuperäisestä esikuvastaan, sillä meidän versiossamme pelin osatehtävien läpäisemiseksi riitti ainoastaan esteiden siirteleminen pois kulkuväylältä siten, että pelaaja pääse maaliin. Tämän kertainen koodaustehtävä oli täysin erilainen kuin edellisen kierroksen kuvasuotimien kanssa puuhastelu. Kuvakoodauksen jäljiltä minulla, jolla ei ennen Otaniemeen ja Tikille tuloa ollut mitään aikaisempaa kokemusta ohjelmoinnista, oli varsin kaksijakoiset tuntemukset ohjelmoinnista. Toisaalta oli onnistunut fiilis, kun olin saanut aluksi ylipääsemättömän vaikealta tuntuneen tehtävän kunnialla tehtyä. Toisaalta oli vähän sekavat tuntemukset siitä, että tälläistako ohjelmointi sitten ylipäätänsä tulee olemaan, sekavaa ja raskasta. Onneksi tämän viidennen kierroksen Sokoban oli lähempänä sitä, mitä olin ehkä jonkin verran ohjelmoinnilta odottanutkin, vaikka sisältyyhän koodaamiseen paljon muutakin kuin graafisten käyttöliittymien parissa työskentelyä.

Tämän kertaisen näpyttelyn tehtävänanto oli jo mielestäni sitä tasoa, jota voisi ohjeistukselta odottaakin; selkeä ja kattava. Lisäksi kierrokseen liittyvän OLO-tapaamisen virike antoi perustietoa piirtämiseen tarkoitetun Graphics2D-luokan käytöstä, jota hyödynnettiin Sokobanin graafisen ilmeen muodostamisessa. Ohjelmointi 1 -kurssilla graafisia käyttöliittymiä oli jo aikaisemmin sivuutettu hiukan, mutta sen enemmin niistä tiedoista ei tässä tehtävässä ollut apua.  Näillä perusteilla ryhdyin tuottamaan tehtävän vaatimaa koodia ja aluksi tehtävä tuntuikin haastavalta,  mutta kun aiheesta sai kunnon otteen ja teki omaa etsivän työtä, alkoi koodia syntyä tasaiseen tahtiin. Tehtävän suorittamisen kannalta varmasti eniten haasteita tuotti siis se, että Scalan Swing-kirjaston oma dokumentaatio ei näin aloittelevan ohjelmoijan näkökulmasta ole se kaikkein selkein ja yksinkertaisin opas. Pulmien ratkaisemiseksi jouduinkin käyttämään huomattavan paljon Googlea apunani, jotta Eclipsen antamista virheviesteistä päästiin eroon. Assareiden antamaa apua ei pidä sitäkään yhtään vähätellä, sillä ilman heitä tämän kurssin suorittamisesta ei yksinkertaisesti tulisi yhtään mitään.  Tehtävä itsessään ei siis loppujen lopuksi ollut edes kovin vaikea, mutta ensikertalaisen alkuhaparoinnit tuottivat aluksi mutkia matkaan eikä tehtävänannon kuvan mukaiselta reaktioltakaan voitu välttyä, mutta onneksi virheet oli helposti löydettävissä ja korjattavissa. Suurimmat ongelmat johtuivatkin siis Swing-kirjaston dokumentaation auttamattomasta köyhyydestä, tai ehkä en vain osannut hyödyntää sen kaikkea potentiaalia.

Tehtävän palauttamisen jälkeen miettiessäni, mitä kierroksesta oli jäänyt käteen, pystyin rehellisesti toteamaan, että aika paljonkin. Opin nimittäin käyttämään Graphics2D:tä ja Scalan Swingiä perustasolla, ja näitähän tullaan hyödyntämään myös kurssin seuraavalla ja samalla myös kurssin päättävällä ohjelmointikierroksella, jossa koodataaan yhteensä kolme pientä peliä ja omien mieltymysten sekä taitojen mukaan myös lisäpelejä.

Tässä vielä lopuksi kuvakaappaus omasta tuotoksestani tältä harjoituskierrokselta. Aikaansaannokseni ei kuitenkaan ole se kaikkein kaunein monipuolisin toteutus, jonka tehtävänannon puitteissa olisi voinut koodata, mutta aikaa on aina rajallinen määrä ja haasteiden tuomat viivästykset syövät sitä yleensä yllättävän paljon. Nyt voin kuitenkin luottavaisin mielin jatkaa kohti finaalikierrosta. 🙂

Kierros 5 - Sokoban


Markus Pajari

Tapaus 6 – Käyttöliittymäsuunnittelu, purku

Viimeisen OLO-session angendana oli kuudennen eli kurssin päättävän kierroksen (GUI) purku ja lopuksi ryhmän jäsenten yhteisen palautelomakkeen täyttäminen. Kun kaikki ryhmän jäsenet olivat saapuneet paikalle kävimme heti purkamaan viimeisen tapauksen sisältöä. Edellisellä kerrallahan tutkittavaksi aiheiksi oli valikoitunut käytettävyystestit, hidden test ja käyttöjärjestelmille laaditut interaktion suositukset, joista edelleen tarkasteltiin Windows Phonen ja Androidin ominaisuuksia. Seuraavassa lyhyesti, mitä saimme aiheesta irti.

Videopelien oudot ominaisuudet

– Tyyppi 1 – Debug-toiminnot:

Joihinkin peleihin on kehitysprojektin jäljiltä jäänyt erilaisia debug-toimintoja. Esimerkiksi Windows XP:n Space Cadet -pinball pelissä pelin aikana kirjoitettu “hidden test” avaa useita eri debug-ominaisuuksia. Palloa on mun muassa mahdollista liikuttaa hiirellä ja pistesaldo on mahdollista muuttaa arvoon 1,000,000,000. Lisäksi on esimerkiksi mahdollista katsoa pelin viemän muistin määrä ja kehysnopeus. Tarkemmin Pinballin “hakkeroinnista” on kerrottu tämän linkin takana.

– Tyyppi 2 – Pelin tekijöillä oli tylsää tai he halusivat välittää jonkin viestin:

Avoimesta pelimaailmastaana tunnettu Grand Theft Auto -pelisarja on tästä mainio esimerkki. Esimerkiksi GTA IV – pelissä New Yorkin edustalla sijaitsevalla, Liberty Islandin saarella Vapaudenpatsas on kaikkea muuta kuin pelkkä viaton patsas. Vapaudenpatsaan ovikyltissä nimittäin lukee…

“No Hidden Content this way”

…ja mitä patsaan sisältä paljastuukaan…

“Heart of the City”

Eivätkä patsaan kasvotkaan taida ihan vastata esikuvaansa…

Jos kiinnostuksesi heräsi, aiheesta löytyy enemmän tietoa tämän linkin takaa.

– Tyyppi 3 – Pelin tekijät olivat laiskoja tai budjetti loppui kesken:

Seuraava video kertoo luultavasti kaiken tarvittavan siitä, mitä seurauksia tällä voi olla.


Sittemmin huippusuosion saavuttanut Creepy Watson on myöhemmissä saman studion Sheerlock Holmes -peleissä jätetty tarkoituskella enalleen.

Käytettävyystestit

Käytettävyystestaus on prosessi, jossa käyttäjien avulla arvioidaan tietyn tuotteen käytettävyysongelmia, esimerkkinä käyttöliittymien testaus. Tuotteen kohderyhmästä valitaan käyttäjiä, jotaka testaavat tuotetta valvotuissa olosuhteissa. Pelkkä mielipiteiden keräämien ei ole käytettävyystestausta, vaan olennaista on nimenomaan myös testin systemaattinen tarkkailu. Käyttäjien toiminnasta voidaan päätellä, mitkä asiat esimerkiksi juurikin käyttöliittymän käytössä aiheuttavat ongelmia ja mitkä taas luonnistuivat helposti.

Vuorovaikutus käyttäjien kanssa antaa suoraa palautetta siitä, mtien tuotetta kannattaa kehittää eteenpäin. Tarkoituksena ei välttämättä ole löytää joka ikistä ongelmaa tai todistaa nitä tieteellisesti.

Testiin osallistuu usein muutamia käyttäjiä, koska parilla ei saada tarkkoja tuloksia ja todella suuret ryhmät vaatiavat paljon resursseja. Testillä on tarkkailijoita tyypillisesti yhdestä kolmeen, ja he voivat olla joko taustahavannoitsijoita tai näkymättömissä.

Käyttöjärjestelmien interaktion suositukset

Tarkastelun kohteina oleiden moobilialustoiden Windows Phonen ja Androidin sovelluskehittäjille annettuissa ohjeissa on monia yhtäläläisyyksiä, mutta vähintään yhtä paljon löytyy myös poikkeavaisuuksia.

Alustoiden varmasti tärkein omien sovellusten yhtäläisyys on appien ulkoasu. Valmistajat haluavat säilyttää niissä samat piirteet, jotta sovellusten käyttäminen olisi kautta linjan helppoa ja intuitiivista. Windowsilla ulkoasun määrittely on ehkä kuitenkin Androidia vähän tiukempaa. Android-alustalla sovelluksilla ei nimittäin aiemmin ollut ulkoasun määräviä kriteereitä, mutta sittemmin Google on halunnut järjestelmänsä ulkoasuun yhdenmukaista logiikkaa.  Molemmille käyttöjärjestelmile yhteistä on myös omien sovelluksien johdonmukainen käytettävyys. Tämä tarkoittaa sitä, että jos esimerkiksi sovelluksessa olevalla painikkeella on tietty toiminto, täytyy vastaavan ulkoasun omaavan painikkeen suorittaa toisessa ohjelmassa samankaltaiset toimenpiteet.

Mobiilialustoiden eroavaisuuksia mainitakseni Windows Phonen sovelluksissa painotetaan liikettä ja elävyyttä, kun taas Androidin puolella asiat pitäisi ilmaista mielummin kuvien avulla kuin tekstillä, kertoohan kuva tunnetusti enemmän kuin tuhat sanaa. Androidilla myös tiedon nopea käytettävyys on avainasemassa, mikä tarkoittaa sitä, että käyttäjän syöttämää tietoa pitäisi tallentaa laitteen musitiin, jotta sama tieto on myöhemmin nopeasti saatavilla. Tällä pyritään siihen, että samaa asiaa ei tarvitsisi kertoa laitteelle joka kerta uudelleen. Windowsin kehittäjille annetaan puolestaan ohjeeksi sovelluksen ongelmaton eri ympäristöissä; onhan Windows alun alkaen ollut PC-tietokoneiden käyttöjärjestelmä eikä mobiilikäyttöjärjestelmä.

Tämän linkin takaa löytyy vielä pääpiirteet Androidin appien kehittämiseen annetuista ohjeista, joiden avulla sovellusten kehittäjät voivat laatia käyttäjäystävällisiä ohjelmia.


Markus Pajari

Tapaus 4 – Web-teknologiat, avaus

Tämän kertaiseen OLO-tapaamiseen oli tosiaan kokoontunut noin puolet ryhmämme alkuperäisestä vahvuudesta. Tenttiviikkoa eletään, mutta liekö katoon muitakin syitä – mene ja tiedä. Saimme kuitenkin viiden hengen voimin pohjustettua seuraavaa aihetta eli web-teknologioita, joiden tiimoilta syntyikin mukavasti keskustelua. Kun viisi päätä “lyötiin yhteen”, post-it-lapuille saatiin stormattua seuraavia asioita:

(Klikkaa isommaksi)

(Klikkaa isommaksi)

Ja näistä asioista seuraavalle OLO-sessiolle tutkittaviksi aiheiksi valikoitui kuvan mukaisesti:

(Klikkaa kuvaa isommaksi)

(Klikkaa kuvaa isommaksi)

  • TCP/UDP – Tero
  • Suuret käyttäjämäärtä – Esa
  • URL+DNS – Karri
  • MVC – Antti
  • P2P-verkot – Markus


Tällaista OLO #10 :ssä.

Markus Pajari