Loppupuheenvuoro

Kurssi alkaa olla paketissa, joten nyt on aika kerrata vähän tapahtunutta ja purkaa omia mietteitä.

Täytyy sanoa, että ensivaikutelma kurssista oli nihkeä. OLO-tapaamiset pistivät vähän epäilyttämään ja pari ensimmäistä harjoitustehtävää tuntuivat aikamoiselta pakkopullalta. Niissä opittiin aika paljon yleistä siitä miten tietotekniikassa ja ohjelmoinnissa asiat ovat suhteessa toisiinsa. Käsitekarttaan tuli läträttyä vähän sitä sun tätä, mutta en kyllä enää muista mitä uutta opin siitä. UML-työ tuli kasattua hammasta purren ja tässä vaiheessa alkoi jo tulevat työtunnit pelottaa mielessä. Epäilykset osuivat kieltämättä oikeaan, MUTTA sanoisin, että kurssi lähti UML:n jälkeen ehdottomasti nousuun.

Ensimmäinen ohjelmointitehtävä oli nimittäin aidosti kiinnostava ja motivoiva. Sitä tehdessä oppi esimerkiksi silmukoiden idean todella hyvin. Sitä seurannut kuva-tehtävä olikin sitten työmäärältään aika hirviö, mutta sekin aiheeltaan ihan mielenkiintoinen. Siihen upposi työtunteja huolella, mutta samalla tuli opeteltua aika paljon ohjelmointia. Muistelen lämmöllä sitä kun koitin valehtelematta viisi tuntia jäljitellä tehtävänannon mallikuvaa vaikka koodini oli ollut koko sen ajan oikein…. jep. Virheen etsiminen toimivasta koodista on aika vaikeaa, voin sen teille kertoa D:

Esseetehtävä oli itselle aika hankala, koska en tiennyt etukäteen kovin tarkasti web-teknologioista. Oppi siitä aihealueesta aika paljon uutta, mutta samalla osa tiedosta jäi kyllä kunnolla sisäistämättä. Tiedon kirjoittaminen kun ei sinänsä vaadi mitään valtavaa sovelluskykyä. Silti ihan hyödyllinen tehtävä, vaikka ei itselle kovin mielekäs.

Pari viimeistä ohjelmointityötä olivatkin sitten aika raskaasti käyttöliittymään liittyviä. Niistä sai aika hyvät perustaidot siihen, miten yksinkertaisia ikkunoita ja 2D-grafiikoita luodaan Scalalla. Osottautui, että kyseisellä kielellä sitä yksinkertaista grafiikkaa saa pöydälle yllättävänkin nopeasti. Käyttöliittymiin sitten liitettiin erilaisia pelejä, joiden logiikan tekeminen oli myös pirun hauskaa. Esimerkiksi ping pongin fysiikkamallin itsenäinen suunnittelu ja sen vaiheittainen testaaminen oli oikein mukavaa hommaa.

Viimeiseen tehtävään anettiin siis käytännössä jo täysin vapaat kädet ja siitä ominaisuudesta pidin. Siinä vaiheessa kurssia oli kuitenkin jo riittävät taidot omatoimiseen tekemiseen. Juuri tämä soveltaminen oli studio -kurssin vahvuuksia. Ohjelmointi 1 opetti enempi ohjelmointiteknisiä asioita ja Scalan käyttöä kun taas studiossa näitä taitoja hyödynnettiin oman koodin suunnittelussa. Toki samaa tehtiin ohjelmointi 1:ssä, mutta siellä tehtävänannot pitivät enemmän kädestä kiinni ja dokumentaatiot olivat tarkkoja. Kurssit toimivat tämän takia mielestäni hyvin yhdessä vaikka välillä olikin vähän synkronointiongelmia (silmukat ja gui käsiteltiin ensin studiossa).

OLO-tapaamisista voin sanoa, että vaikka alkuun tuntuivat turhauttavilta, niin niihinkin alkoi ajan kanssa suhtautua ihan positiivisesti. Ryhmässä oli hyvä meininki ja assarimme oli hyvä tyyppi. Valitettavasti suuri osa ryhmästä lopetti kesken kurssin, mutta toisaalta se toi vähän eloa ryhmäkeskusteluihin. Pienessä ryhmässä juttu ja läppä lensi herkemmin kun tapaamiset eivät tuntuneet enää niin ‘virallisilta’ ja muutaman henkilön kesken oli muutenkin kevyempää jutella. OLOista oppi yleisesti ihan kivaa lisätietoa.

Voisin vielä lopuksi itkeä siitä miten kurssissa oli liikaa työtunteja, mutta siitä on jo tarpeeksi jauhettu opiskelijoiden keskuudessa. Olen kyllä samaa mieltä siitä, että työtä oli vähän turhan paljon suhteessa 5op:hen, mutta toisaalta ymmärrän sen, että aloittelijoille voi olla aika vaikea suunnitella ohjelmointitöitä. Jollekin kokeneelle kodaarille (tehtävän suunnittelijalle) naurettavan helpolta vaikuttava homma saattaa olla toiselle kymmenien tuntien duuni. Ja sitä on vaikea tietää/huomata ellei anneta palautetta. Onneksi siis kritiikkiä on kuunneltu ja studio -kurssia tullaan varmaan modaamaan tulevaisuutta varten.

Kiitos vielä ryhmälle.

— Karri Haranko

Advertisements

Tehtävä 1 – Luokat ja oliot

Toisen harjoitustehtävän tarkoituksena oli tutustuttaa opiskelijat UML-mallinnuksen perusteisiin. Tehtävänantona oli luoda luokkakaavio, joka kuvaa puhelinlaskuja hallitsevan järjestelmän toimintaa sekä kirjoittaa sen kylkeen pienimuotoinen essee. Tekstissä piti avata oman kaavion toimintaa ja kertoa yleisesti UML:n ominaisuuksista kuten esimerkiksi niistä käytännöistä, joilla kaavioissa merkataan luokkien välisiä yhteyksiä.

Tehtävää tehdessä monet olivat vielä opiskelun ja koodamisen suhteen aika alkutaipaleella, mikä aiheutti ainakin minulle (ja kuulemani mukaan muutamalle muullekin..) päänvaivaa. Tehtävä löi lievästi korville, koska tässä kohtaa joutui ensimmäistä kertaa opiskeluaikana tekemään astetta haastavamman ja työläämmän tehtävän. Olio-ohjelmointi ja yleiskäsitys ohjelmien rakenteista oli vielä vähän hakusessa ja asiaa ei helpottanut se, että tehtävänanto oli tarkoituksella melko avoin, minkä ansiosta olennaisen asian suodattaminen lopulliseen työhön jäi itselle mietittäväksi.

Tästä tehtävästä sai kuulla kovaa purnausta aika monen kanssaopiskelijan suusta ja se on helppo ymmärtää. Työ oli hämmentävä, työläs eikä kovinkaan mielenkiintoinen. Aihealue oli toisaalta ihan hyödyllinen, mutta tehtävän ajoitus meni mielestäni vähän pieleen. Ehkä jos sama homma olisi tarjottu yksi tai pari kuukautta myöhemmin, olisi työ tuntunut kevyemmeltä ja oppiminen olisi ollut vähän hedelmällisempää.

Se mitä työstä jäi itselle käteen, oli parempi käsitys olioiden välisestä toiminnasta. Lisäksi pääsi tutustumaan täysin uuteen asiaan eli UML-mallinnukseen. Täytyy kuitenkin todeta, että tehtävä ei ehkä tarjonnut ihan tarpeeksi vastinetta sille ajalle, minkä tähän joutui kuluttamaan.. ellei sitten tulevaisuudessa joudu enemmänkin tekemisiin UML:n kanssa?

— Karri Haranko

Tapaus 6 – Avaus

Tällä kertaa pureuduimme tarkemmin käyttöliittymään liittyviin asioihin ja erityisesti sen suunnitteluun. Ryhmämme oli jälleen pienehkö ja koostui neljästä henkilöstä, mutta se ei menoa haitannut. Ilmeisesti aihealue oli kaikille läheinen ja kiinnostava tai jotain, koska keskustelua riitti läpi avauksen ja se rönsyili mukavasti. Puheenaiheiksi nousivat esimerkiksi shakkitekoälyt, pelien huijauskoodit sekä YouTuben käyttöliittymä, joka aina vaan jatkaa ihmisten suututtamista päivityksillään. Innostuimme lopulta jauhamaan erinäisistä asioista niin pitkään, että aika karkasi käsistä ja päätimme poikkeuksellisesti skipata stormauksen ja fläppitaulut. Tutkittavat aiheet päätettiin jakaa suoraan henkilöille ja ne menivät seuraavasti:

Esa – käyttöliittymäsuositukset pelikonsoleille
Karri – käytettävyystestit
Antti – hiddentest ja perustelut pelien koodeille ym. salaiselle sisällölle
Markus – käyttöjärjestelmien interaktion suositukset

— Karri Haranko

Tapaus 4 – Purku

Neljännen tapauksen aiheena oli web-teknologiat ja sitä lähdettiin purkamaan yhden miehen vajauksella. Tero sai kuitenkin lähetettyä esityksensä verkon kautta, joten hänenkään aiheensa ei jäänyt käsittelemättä. Aiheista löytyi niin vertaisverkkoa kuin URL:n ja MVC:n toimintaa. Oheen on kasattu töiden muistiinpanoja, joista ilmenee olennainen.

MVC (model-view-controller)

– tapa järjestellä koodia
– useat frameworkit toteutettu käyttäen
– ongelmana, että kontrolleriin kasautuu liikaa kamaa

– model (malli), määrää sen, miten asiat näytetään
– view (näkymä), luo mallin luomasta datasta lopullisen visuaalisen esityksen
– controller (ohjain), vastaanottaa käyttäjän komennot, prosessoi ne ja ohjaa mallia ja näkymää

Sekä hyvä havainnollistava kuva:
mvc

URL

– tietty merkkijono, joka sisältää viittauksen lähteeseen
– rakentuu seuraavasti:
1. ensin protokolla esim. http
2. kaksoispiste ja kaksi kauttaviivaa
3. host, joka yleensä annetaan verkkotunnuksena, mutta joskus myös kirjallisena IP-osoitteena
4. koko loppupolku
– protokolla kertoo miten yhdistää, host määrittää minne yhdistetään ja loput sen, mitä pyydetään

DNS

– nimipalvelujärjestelmä, joka muuntaa verkkotunnuksia IP-osotteiksi
– mahdollistaa helposti muistettavien nimien käytön numeeristen osotteiden sijaan (jolla Internetin laitteet kommunikoivat)
– toimii kuin puhelinluettelo, joka liittää verkkotunnuksia IP-osotteisiin

Nimipalvelun toteuttavia palvelintyyppejä on kaksi:
– resolverit – hakee nimipalvelukyselyihin vastauksia
– auktoritatiiviset nimipalvelimet – antavat vastauksia nimipalvelukyselyihin

P2P -verkot (vertaisverkko, peer-to-peer-verkko)

Markuksen tekemän hienon esityksen voi katosa tästä:
ME-C2110 Kierros 4 – Web-teknologiat – P2P

— Karri Haranko

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

23.10. OLO3:n purku

Tällä viikolla neljättä olo-tapausta, joka oli siis kuva, oli saapunut purkamaan vain noin puolet ryhmämme vahvuudesta. Lieneekö tenttiviikko sitten tehnyt tehtävänsä vai mikä, mutta muutama aihe kuvaan littyen saatiin kuitenkin käytyä läpi.

Väriavaruus

Väriavaruus on matemaattinen malli siitä, kuinka esittää värejä lukujen avulla. Usein tämä toteutetaan kolmella tai neljällä luvulla, elöi komponentilla. Väriavaruus määrittelee, mitä kaikkia värejä voidaan käyttää – määrä ja määrittely vaihtelee värimallien välillä.

Erilaisia värimalleja ovat esimerkiksi:

  • RGB (Red Green Blue) – tietokonegrafiikassa varmasti yleisin värimalli

  • HSB (Hue Saturation Brightness) – sävyyn, kylläisyyteen ja kirkkauteen perustuva malli. Yleisesti käytetty valo- ja videokuvan käsittelyssä, sillä se mahdollistaa kuvan helpon värikorjauksen.

  • CMYK – tulostukseen tarkoitettu värimalli (värit sekoittuvat eri tavalla kuin tietokoneen näytöllä)

  • Lisäksi mm. PAL-videokuvan YUV, sekä RGB:n johdannaiset sRGB ja Adobe RGB.

Vektorigrafikka

Vektorigrafiikka eroaa rasterigrafiikasta siinä, että kuvaa ei tallenneta kuvapisteinä, vaan matemaattisesti määriteltyinä muotoina, esim. ympyrä ja neliö.

Käytännössä kuvatiedostoon tallennetaan solmujen paikkoja ja tiedot siitä miten mitkäkin solmut yhdistetään. Alla olevassa kuvassa esim. suorilla viivoilla.

vector4

Määritellyt muodot voidaan lopuksi määritellä täytettäviksi jollakin värillä (kuten mallikuvassa keltaisella) tai vaikka rasterimuotoisilla kuvilla, mikä on mahdollista esim. EPS-vektoriformaatissa. Koska kuva on tiedostossa määritelty ainoastaan matemaattisesti, täytyy lopullinen kuva muodostaa joka kerta uudestaan kuvaa näytettäessä. Tästä on tosin hyötynä se, että vektorigrafiikkaa voidaan skaalata loputomasti ilman että sen laatu kärsii. Yleisimpi vektoriformaatteja on  SVG, johon voidaan itse grafiikan lisäksi suoraan tallenetaa myös esimerkiksi animaatiota. SVG on nettisivuilla eniten käytetty vektoriformaatti sillä kaikki uudenaikaiset selaimet tukevat sitä.

HDR (High Dynamic Range) -kuva

  • Kuvantamista, jossa kuvaa käsitellään muodossa, jossa dynamiikkaa enemmän kuin tavalliset monitorit ja tulostimet pystyvät esittämään
  • HDR-kuvan tulostaminen/näyttäminen monitorilla: tavanomaista laajempi kirkkausalue kutistetaan tulostimen/näyttölaitteen kirkkausaluetta vastaavaksi
  • Yksinkertaisin, lineaarinen kutistaminen →kontrastittomat, mitäänsanomattomat kuvat; eivät vaikuta luonnollisilta.
  • Kehittyneemmättonemapping-algoritmit; pyrkivät säilyttämään paikallisen kontrastin

Dynamiika

  • Tarkoittaa sitä, kuinka laaja kirkkausalue voidaan esittää niin, että kuvan yksityiskohdat vielä erottuvat
  • Mitataan yleensä aukkoina →kukin aukko kaksinkertaistaa kirkkauden
  • Korkealla ja matalalla dynamiikkalla ei yksikäsitteistä rajaa
  • Tyypillinen matalan dynamiikan kamera/filmi/monitori toistaa noin 5-9 aukon laajuisen dynamiikka-alueen

HDR -kuvan ottaminen

  • Tyypillisesti valotushaarukoinnilla: samasta näkymästä otetaan useampi valokuva eri valotuksilla
  • Esim. 1/125 s, 1/250 s, 1/500 s, 1/1000 s, 1/2000 s; muut valotusparametrit (aukko, herkkyys) pysyvät samoina
  • Kuvien yhdistäminen: esim. Photoshop, LuminanceHDR →rekonstruoivat eri valotusajoilla otetuista kuvista kameran toistokäyrän, laskevat kullekin pikselilletodellisen kirkkauden

Tallentaminen

  • Yleensä jossakin muodossa, jossa ei ole käytännössä rajoja, esim. EXR
  • EXR-muodossa kunkin pikselinvärikomponentti (RGB, punainen, vihreä sininen) liukuluku →kirkkauden suuruusluokka voi vaihdella huomattavasti, merkitsevien numeroiden määrää vakio
  • Liukulukuina esitetty HDR-kuva tavallaan rekonstruktio siitä, millaiset valoisuuserot maisemassa oli ennen kuin se kuvattiin, lisättynä mahdollisesti kuvantamisvälineen virheillä

Kuvaputkinäyttö

Kuvaputkinäyttö koostuu tyhjiössä olevasta elektrinitykistä, jonka lähettämiä elektroneja ohjataan kaksisuuntaisella magneettikentällä. Elektronit kohdistetaan fosforipintaan siten, että ne muodestavat halutun kuvan. RGB-näytössä elektroneja kohdistetaan erikseen punaista, vihreää ja sinistä valoa emitoiville kohdille fosforipintaa. Yksi kuvaputken erityis-sovelluksista on oskilloskooppi.

Tälläistä siis tällä viikolla OLO-ryhmä #10 purussa.

Antti Virtanen

9.10 – OLO3 -session avaus – Kuva

Keskiviikkona 9.10 Kävimme läpi Tapaus Kolmosta eli Kuvaa.

Brainstormaamisen jälkeen taulullemme oli kertynyt seuraavanlaista lappua:

Tapaus 3 Post-itit

(Klikkaa isompaa)

Näistä ideoista karsimme kokoon seuraavat aiheet:

Tapaus 3 aiheet

(Klikkaa isompaa)

avuK

  • Värifilosofia – Matias
  • Näytöt – Sampsa, Esa
  • HDR – Markus
  • Kuvaformaatit – Terhi
  • Vektoriformaatit – Antti
  • Tietokonegrafiikka – Lauri
  • Väriavaruus – Tero