Loppupuheenvuoro – Esa

Taitaapi kurssi jo olla loppumaan päin! Loppupuheenvuoron paikka. Ensiksi OLO-sessioista. Etenkin alussa tällä tavoin lähes viikottain työskentely tuntui turhalta, turhauttavalta, epämielenkiintoiselta ja tarpeettomalta. Porukkaa oli paljon, suutaan ei viitsinyt tuntemattomien, itseään enemmän tietävien henkilöiden keskuudessa paljoa availla, seitsemän askeleen menetelmä ei tuntunut toimivan ja muutenkin kokonaisfiilis OLOja kohtaan oli vähintäänkin nihkeä. Toisen kierroksen jälkeen tapaukset alkoivat kuitenkin tuntua huomattavan paljon mielenkiintoisemmilta, ja kolmoskierroksen kohdalla porukkaa karsiutui paljon pois, jättäen tiiviimmän ja paremmin toimivan ryhmän jälkeensä. Olisi varmaankin ollut hyvä, jos jo alusta asti ilmapiiri olisi ollut tälläinen, mutta toimintaperiaatteen epämääräisyys ja yleinen negatiivisuus heikensi kokonaisuutta.

OLO-sessioiden virikkeissä ei aluksi ollut itselle mitään uutta – eikä kieltämättä loppuakaan kohti hirveän paljoa – mutta ryhmän sisäinen keskustelu ja itse tutkittavat asiat toivat erittäin paljon syvyyttä tapausten luomille pohjille. Itse pidin paljon siitä, että opin hieman pintaraapaisua tarkemmin monenlaisia asioita. Ryhmä alkoi toimimaan loppua kohden varsin autonomisesti, ja ainakin itse tulin siinä vaiheessa OLO-tapaamisiin ennemminkin mielenkiinnosta kuin pakosta. Jos se muutos olisi tapahtunut jo aiemmin, olisi kurssilla varmasti ollut kokonaisuutena positiivisempi ilmapiiri – mm. tuotantotalouden ykköskurssilla tehtiin koko kurssin ajan laajaa ryhmätyötä hyvin pienen ryhmän kesken, ja se tuntui toimivan heti alussa paremmin. Tiedä sitten käytännön järjestelyjen hankaluuksista.

Mielestäni tietokoneiden sisäisen toiminnan ja ohjelmistojen suunnittelujen pääpiirteiden ymmärtäminen on hyvä jokaisen tietotekniikan opiskelijan osata, ja siitä tuli myös tällä kurssilla opittua niin aiheiden kuin harjoitusten muodossa. Kokonaisuus pysyi hyvin kasassa ja perusteltua itkemistä kuunneltiin mielestäni hyvin. Toisaalta, palautteen määrän perusteella voisi päätellä, että parannettavaakin on vielä paljon. Kieltämättä moni harjoitustehtävä tuntui hieman kohtuuttomankin laajalta tai epäselkeältä, ja deadlinet alkoivat ajoittain tulla kovastikin vastaan (nimim. useampi kierros yhä palauttamatta). Kuitenkin mielestäni kurssi oli käymisen arvoinen – kiitos kaikille sitä toteuttaneille siitä! 🙂

– Esa Koskinen

Advertisements

Loppupuheenvuoro – Tero

Ja niin on studio ohitse!

OLO-sessiot olivat ihan uudenlainen tapa käydä läpi uusia asioita. Alkuhankaluuksien (niin mitä meidän pitäisi tehdä?) jälkeen ryhmätapaamiset olivat ihan kivoja; itselläni ainaakaan ei ollut mitään stressiä ryhmästä, asiat otettiin varsin rennosti. Ehkä liiankin rennosti järjestäjien mieleen, arvelen ma, mutta parempi olla mukavempaa kuin oppia hitusen enemmän ja ahdistella viikottaista tapaamista.

Tärkeimmät asiat sessioilta oli jo suurinpiirtein tiedossa. Ei kurssi tietenkään pelkkää kierrätystavaraa ollut, sillä tulee kuitenkin nyt mieleen esimerkiksi MVC, mikä tavallaan oli tiedossa mutta tavallaan ei. Kuten palautelappuja täytettäessä viimeisellä kokoontumisella todettiin, ei ollut mitään absoluuttisen turhaa asiaa jonka olisi voinut kokonaan jättää pois. Tai noh, Platon

Tehtävissä oli tekemistä. Ensimmäisestä (nollannesta) jäi tosin vähän karvas maku, kun oma liiankin verboosi miellekartta ei ollut ihan assarien mieleen. Ja “ensimmäisessäkin” meni ensimmäisellä kertaa ohi tehtävänannon painotus UML-kaavion esseeosuudesta, joka ei siis ollut tarpeeksi verboosi. Toinen tehtävä oli jännä kohinasimuloinnin ja virheeneston kanssa, ja kolmas tehtävä… kolmas tehtävä oli sitten jotain. Kuvien filtteröinti oli loppujen lopuksi ihan mielenkiintoista, vaikka tämä vähän “kokenutkin” koodaaja löysi monta mutkaa matkasta. Sokoban-klooni oli itselleni vähän turhan raskas, kun päätin että seinien tulee sovittautua vieressä olevien seinien perusteella! eikä kunnia antanut perääntyä. Voi niitä konditionaaleja ja match-caseja. Huh huh. Viimeinen kierros, pelikokoelma, tämä “tee tämä, ja tee se miten tahdot” ultimaallinen taitojen osoitus. Eh, täytyy tunnustaa että vika kierros ei ole ihan vielä valmis, mutta on ihan hyvä idea antaa vapaat kädet opiskelijalle, ja mikäs sen parempi (oikeasti) harjoitus kuin koodata muutama tuttu peli itse.

Loppujen lopuksi, vaikka kurssin huomaa olevan uusi ja sen kanssa on ollut vähän sähinää (ne irc-logit ovat viihdyttävää luettavaa jos osaa tilanteesta irtautua), en voi väittää etteikö kurssi ole ollut minulle hyödyksi. Kiitän kaikkia jotka ovat tässä olleet mukana.

Joten! Hyvää joulua ja aivan loistavaa uutta vuotta!

 Tero Saaristo

Tehtävä 3 – Kuva

Kolmannnen kierroksen tehtävän tavoitteena oli ohjelmoida kourallinen suotimia joilla kuvia voisi muokata. Itse käyttöliittymä oli annettu valmiiksi, mutta molemmat suodintyypit (PixelFilter ja FourierFilter) piti viimeistellä itse annetun rungon päälle. Tässä tehtävässä hyödynnettiin ensimmäistä kertaa abstrakteja luokkia; näin kumpaakin suodintyyppiä voitiin käyttää samalla tavalla, vaikka niiden sisäinen toteutus olikin aivan erilainen.

Auringonkukka

Kohdekuvamme

PixelFilter muokkasi kuvia annetun matriisin perusteella. Tämä oli varsin mielenkiintoista, sillä oikeasti selvisi “miten matriisilla kerrotaan pikseleitä” ja myös miten monia tuttuja suotimia voi ylipäätään toteuttaa! Todennäköisesti moniin suotimiin on kuitenkin monia eri tapoja, varmasti tehokkaampiakin, mutta tässä pääsi hyvin alkuun. Alla on esimerkkejä muutamista eri efekteistä, osa poimittu GIMPin ohjemateriaalista matriiseja koskien.

PixelFilter-suotimia

Vasemmalta oikealle: sumennus (blur), tarkennus (sharpen), reunanlöytö (edge detect) ja kohokuva (emboss)

Itse vedin PixelFilterin toteutuksen vähän överiksi ja tein oman MatrixFilter -luokan, joka sisälsi kaiken tarvittavan tiedon matriisista: sen nimen, itse matriisin, loppukertoimen, kohdekanavien (R, G, B) ja totuusarvon määrittämään kummassa väriavaruudessa kuvaa suodittiin – RGB:ssä vai HSV:ssä. Lopputuloksena ei tarvinnut kuin lisätä uusi instanssi listaan ja rivi pixelfilter.txt:hen niin operateFilter teki taikansa ilman muuta säätöä. Lisäksi kiersin tehtävänannossa mainitun reunaongelman teeskentelemällä kuvan jatkuvan samana reunojen yli.

FFT

Puolitiehen jätetty kuva, joka on käynyt kerran FFT:n läpi ja saanut reunojensiirron

FourierFilter muokkasi kuvia taajuusavaruudessa, ja se oli aivan yhtä selkeä asia kuin miltä kuullostaakin. Onneksi FFT-muunnoksia ei tarvinnut itse keksiä, vaan ohjeita orjallisesti noudattaen lopuksi voi huomata koodin toimivankin vaikka teoria menisikin ohitse. Yllä oleva kuva ei tietenkään ole riittävä alkuperäisen auringonkukan muodostamiseen, sillä FastFourierTransformin jälkeen kuva on jaettu kahteen osaan: reaali- sekä imaginääriosaan. FourierFilter käytännössä kertoo FFTn jälkeisiä arvoja (reaali ja imaginääri) ja sitten muuntaa kuvan takaisin ymmärrettävään muotoon.

Esimerkkejä taajuusavaruuden suotimista:

Notch

Notch

Lowpass

Lowpass

Highpass

Highpass

Ring

Ring

Bonus! Aaltokuvio joka syntyi kirjoitusvirheen ansiosta. Maskia ei voi näyttää, sillä se ylitti reaalimaailman rajat.

Waves

Waves

Tehtävässä oli myös ongelma ratkottavana: kuinka puhdistaa “vahingoittunutta” kuvaa taajuusavaruuden avuin.

Image

Virheellinen kuva taajuusaravuutensa kanssa.

Itse sain jotain aikaan poistamalla pikselirykelmiä, jotka selkeästi poikkesivat alkuperäisestä kuvasta.

Korjailtu kuva

Korjailtu kuva

Kun tehtävän haastavuudesta selvisi, oli se yllättävän hauska; kuvia sai muokattua ihan itse monilla eri tavoin ja tulevaisuudessa muistan kyllä miten matriisifiltterit toimivat.

Tehtävä 2 – Koodaus ja dekoodaus

Kakkoskierroksella tehtävänä oli toteuttaa metodeita, joiden avulla voidaan luoda bittijonolle toistokoodaus, tai dekoodata tälläinen bittijono. Piti myös toteuttaa metodit, joiden avulla pystytään luomaan virheitä erinäisillä parametreillä mallintamalla, sekä selvittää tuntemattoman bittijonon sisältö.

Ensivaikutelma tehtävästä oli erittäin positiivinen! Kunnolla koodaamista, erittäin mielenkiintoinen aihe, kohtuullisen vapaat kädet silti ohjeistuksen ollessa selkeää.. Mitä muuta olisi voinut haluta? Ylimääräistä aikaa kenties, mutta tehtävä oli itsessään todella hauska toteuttaa. Etenkin digitaaliarkeologia antoi mukavaa haastetta, ja oli varsin hauska osa tätä kierrosta. Veikkaan kuitenkin, että ohjelmoinnin aloittelijoille tehtävä varmasti aiheutti enemmän kuin tarpeeksi ongelmia, jos siinä oli hieman mietittävää jo kokeneemmallekin koodarille.

Muistelisin, että kuvan käsitteleminen virheillä ja virheistä selviytymisen tutkiminen käytännön kautta oli varsin hauskaa. Scalan syntaksi tuli huomattavasti tutummaksi ja “bittijonojen” käsittely on aina hyvää harjoittelua. Tehtävä myös laittoi miettimään tehokkaampia ratkaisuja ja hieman kiinnostumaan siitä, miksi tämmöisiä ongelmia kohdataan ja kuinka olennaista niihin varautuminen on. Kaiken kaikkiaan tämä oli todella hauska, vaikkakin hieman työläs tehtävä.

– Esa Koskinen

Tehtävä 0 – Tieto tietokoneessa

Ensimmäisellä kierroksella oli tehtävänä luoda käsitekartta siitä, miten tiedon tallentaminen ja esittäminen toteutetaan tietokoneessa. Muistan tätä kierrosta erityisellä lämmöllä </3 Yliopisto-opinnot olivat vielä omalta osaltani alkuvaiheessa – ja niin varmasti monella muullakin kurssin kävijöistä – ja tälläinen laajempi tehtävä vaikutti suunnattomalta. Mielestäni tehtävänanto oli aivan liian avoin sekä turhan abstrakti, ja muutenkin monella oli ensimmäisten olosessioiden jälkeen varsin negatiivisia odotuksia harjoitustehtävien tekemisestä. Muutenkin luulen, että käsitekartta oli käsitteenä monelle uusi, joka entisestään lisäsi tuskailua.

Näin jälkikäteen ajateltuna, ei kyseessä ole oikeastaan hirveän valtava tehtävä, etenkään nyt kun on tarkempi käsitys kurssin arvosteluperiaatteista. Alkupäässä otin kuitenkin valtavat paineet niin deadlinestä kuin ohjeistuksen epämääräisyydestäkin. Aloittaminen tuntui raskaalta, ja se tuli tehtyä liian myöhään – sain tuntien tuskailun lopputuloksena vain varsin kehnon ja epäselkeän paperilla tehdyn kuvauksen aiheesta. Ei hyvä.

Tein sitten tehtävän uudestaan, tällä kertaa käyttäen suositeltuja ConseptMap Toolseja, suunnittelin rakenteen tarkemmin jo alkuvaiheessa ja paneuduin sen tekoon oikeasti ajatuksella muutamien tuntien ajan. Tällä kertaa käsitekarttani oli jo huomattavasti informatiivisempi sekä viimeistellyn oloinen. (sitä ei ole vielä arvosteltu, tosin; töks töks)

Luulen, että hieman toisenlainen tai pienempiin osakokonaisuuksiin jaoiteltu tehtävä olisi kenties sopinut tähän vaiheeseen kurssia paremmin. Olen varma, että ensimmäisten kahden kierrosten tehtävistä on tullut paljon itkua suunnasta jos toisestakin.. Tämän tyyliset tehtävät eivät oikein iske. Näin jälkeenpäin ajatellen käsitekartan teko oli kuitenkin tarpeeksi mielenkiintoista ja opin siitä kohtuullisesti – vaikkei se siltä aluksi tuntunutkaan.

– Esa Koskinen

Kierroksen 5 purku

Toiseksi viimeisen tapaamisemme alussa käsittelimme kuvan varsinaisesti piirtämiseen liittyviä aiheita. Olimme jälleen kahden viikon ajan keränneet informaatiota erinäisistä asioista, ja tässä ovat lopputulokset tiivistettyinä:

Animaatio:

Animaatiot ovat käytännössä peräkkäin näytetty sarja kuvia, joita tarpeeksi nopeasti vaihtamalla saadaan ihmiselle luotua illuusio liikkeestä. Usein sanotaan, että kuvia on tietty määrä sekunnissa (frames per second), ja sen avulla voidaan hieman vertailla animaatioiden sulavuutta. Toteutustapoja on Scalassa useita, mutta yksinkertaisinta lienee päivittää näytölle piirrettävien Image-olioiden kuvaa tarvittaessa. Siinä on kuitenkin lukuisia puutteita – uudelleenpiirrettäessä ei voida suorittaa muuta ohjelmakoodia, animaation ajoitus oikeaan aikaan on vaivalloisempaa ja etenkin pelien toteuttaminen näin on ongelmallista.

Monella tapaa parempi ratkaisu olisi hyödyntää säikeitä. Luomalla Thread -olio ja jättämällä animaatioiden ylläpitäminen täysin sen huoleksi, saadaan ajoitus paljon helpommin toteutettua, samanaikaisesti suoritettua muiden objektien ohjelmakoodia sekä renderöidä kuvaa efekteillä haluttaessa. Kuitenkin sykronointi pääohjelman koodin suorittamisen vaiheiden kanssa voi olla erittäin olennaista tällä tavoin.

Canvasia käyttävä Graphics2D on hidas, kun piirrettäviä kuvaolioita on paljon. OpenGL on nopeampi monissa tilanteissa, ja muut menetelmät voivat olla tilanteesta riippuen vielä nopeampiakin. Tämä tuskin tulee kuitenkaan ongelmaksi, ellei luoda ohjelmia esimerkiksi puhelimille tms.

2D-grafiikka Scalassa

Scalassa ei ole natiiveja grafiisia ominaisuuksia, vaan kaikki piirtämistoiminnot tulevat suoraan Javan kirjastoista. Abstract Window Toolkit eli AWT ja Swing ovat Javan kaksi 2D-grafiikan kannalta erittäin olennaista pakettia. Niissä on paljon samanlaisia piirto-ominaisuuksia ja ne osittain käyttävät samoja luokkiakin, mutta erittäin olennainen ero tulee käyttöliittymän suunnittelun kanssa.

AWT ottaa käyttöliittymän ikkunaelementtien tyylit suoraan käyttöjärjestelmän omista tyyleistä, kun taas Swing piirtää ikkunaelementit omista tyyleistään. Muun muassa ongelmia aiheuttaa AWTia käyttävien ohjelmien porttaus, sillä eri käyttöjärjestelmissä ikkunaelementit voivat näyttää hyvinkin erilaisilta. Swingillä tehdyt ohjelmat sen sijaan näyttävät huomattavasti yhtenäisemmiltä eri käyttöjärjestelmien välillä. Tästä on etua, sillä ikkunaelementtien tyyli sisältää informaatiota mm. siitä, minkä kokoisia ja näköisiä erilaiset napit ja valikot ovat. Jos ero on kovin suuri, voi tarkkaan suunniteltu käyttöliittymä näyttää huonolta tai jopa aiheuttaa hankaluuksia muilla tietokoneilla käytettäessä.

Swing

Swing on Scalan peruskirjasto, jonka avulla on helppo rakentaa monenlaisia käyttöliittymiä. Sen luokat sisältävät määrittelyjä ja metodeja mm. nappuloiden, tekstikenttien, valikoiden ja valintalaatikoiden luomiseen ja käyttöön. Nämä käyttöliittymäelementit sitten jaetaan paneeleihin, joilla voidaan tarkemmin valikoida niiden sijaintia ruudulla.

Ne osaavat myös kuunnella erilaisia inputin tapahtumia, kuten hiirellä klikkausta tai näppäimistön käyttöä, ja heittävät tiedon käyttäjän tekemistä asioista tapahtumakuuntelijalle. Kuuntelija sitten suorittaa erilaisia metodeja riippuen siitä, mitä tapahtui ja missä. Tällä tavoin saadaan esimerkiksi toimintoja käyttöliittymässä olevaa nappia painettaessa.

OpenGL ja renderöinti

Open Graphics Library, eli OpenGL on ohjelmistorajapinta, joka sisältää lukuisan määrän funktioita 2D- ja 3D-grafiikan luomiselle. Se on käyttäjästä ja käyttöjärjestelmästä riippumaton, sillä OpenGL-funktiot pelkästään käsittelevät kuvien tehokasta renderöintiä. Puhtaasti grafiikkaa käsittelevänä kirjastona OpenGL:n avulla ei siis pysty hoitamaan esimerkiksi standardien mukaisten ikkunakomponenttien tekoa, elementtien kuuntelemista tai muita vastaavia toimintoja. Vaihtoehtoisia rajapintoja on myös; pienempiä kuvien renderöintiin pureutuvia kirjastoja on lukuisia, ja eräs olennainen kilpailija on Microsoftin DirectX.

Renderöinti on kuvadatan luomista aiemman datan avulla, noudattaen tietynlaista mallia. 3D-grafiikan yhteydessä termillä viitataan mm. realististen valoefektien kirkkauksien laskemiseen. Videoiden renderöinnissä voidaan kuvasarjan jokaiseen kuvaan lisätä jonkinlainen efekti erilaisten filttereiden avulla, jotta saadaan esimerkiksi kuvasta terävämpää tai poistettua epähaluttuja asioita siististi. Esimerkiksi pelien yhteydessä reaaliaikaisesti useita kuvia peräjälkeen renderöidessä joudutaan säästelemään efektien hienoudesta, sillä aikaa yksittäisen kuvan luomiseen saattaa olla vain sekunnin murto-osa.

– Esa Koskinen

Loppupuheenvuoro – Antti

Tämä Ohjelmointistudio 1 -kurssi alkaa nyt pikkuhiljaa olemaan paketissa.

Tunnelmat kurssin osalta ovat varsin kaksijakoiset. Lyhyesti sanottuna: idea hyvä, toteutus huono. Aloitetaan toteutuksen käsittelyllä, niin saadaan sitten hyvät asiat jutun loppuun. Varmaankin suurin perisynti johon tämä kurssi kaatui oli tiedon puute. Sekä yleisen tiedotuksen, että tehtävien sisällön osalta. Kun kurssi alkoi, niin selkeää kuvaa siitä mitä oikein pitäisi tehdä ei oikein ollut. Ensimmäisestä olo-sessiosta iso osa meni ihmetellessä sitä, että mitä seuraavaksi ja ensimmäinen itsenäinen tehtävä aiheutti kysymyksen siitä kuin laajasti ja tarkasti aihetta oikeastaan pitäisi tarkastella. Tehtävänä olleen ajatuskartan kuin olisi voinut periaatteessa toteuttaa minkä kokoisena tahansa väliltä 10-1000 kuplaa.

Olo-tapaamisten osalta homma alkoi selkiytymään suuremmilta osin jo toisesta viikosta eteenpäin, mutta jo lähes samantien alkoi ilmaantumaan uusi ongelmailmiö nimeltä ryhmän koon pieneneminen. Lähinnä tämä aiheutti ongelmia sen suhteen, että tapaamisissa käytyjen keskustelujen sisällön laatu putosi varsin nopeasti ainakin omalla asteikollani varsin lähelle perus kaveriporukan käytäväjutustelua, eli aiheesta ei oikein saanut keskusteluissa mitään uutta irti. Samaten joukon pieneneminen aiheutti sen että itsenäisesti valmisteltavien esitelmien aihealueet muuttuivat laajemmiksi ylimalkaisemmiksi ja uuden asian määrä ennalta asiaan tutustuneille laski. Hämmennystä puolestaan taas aiheutti se, että koska portfolioon tulevien töiden määrä ei pienenisi vaikka ryhmäkoko niin teki, niin asia kuulemma otettaisiin huomioon arvostelussa. Nähtäväksi jää, että mitä tämä nyt sitten käytännössä tarkoittaa.

Harjotustyöt taisivat kuitenkin olla kaikista suurin syy siihen, miks niin moni jätti kurssin kesken. Tehtävät olivat monilta osin erittäin haastavia ja ohjeistus huonoa. Esimerkiksi jos nämä tehtävät aiheuttivat huomattavia vaikeuksia ihmiselle joka on ohjelmontia harrastanut 12-vuotiaasta saakka ahkerasti ja suhtautuu koulutehtäviin yleiseti hyvällä motivaatiolla (minä), niin en yhtään ihmettele jos ne monille aiheuttivat ylitsepääsemättömiä vaikeuksia.

Monilta osin asiaa olisi varmasti jo helpottanut se, että olisi annettu muutamia hyviä lähteitä joista asiaa olisi lähtenyt tutkimaan. Assareiden avulla tehtävistä saattoi ehkä kyllä saada pisteitä irti, mutta kuinka paljon tehtävät sitten lopulta oppimista saivat aikaan? Osaltaan tehtävänannoissa esiintyneet tyhjästä ilmaantuvat käsitteet, oletukset asioiden triviaalisuudesta, sekä virheet, joita ei kuulemma ollut tarvetta korjata, eivät varmasti ainakaan parantaneet tilannetta.

Mutta nyt niihin positiivisempiin asioihin, tai no oikeastaan asiaan. Kurssin idea oli nimittäin mielestäni varsin hyvä ja kehittämiskelpoinen. Toteutus olisi voinut onnistua paremmin jos kullekkin aiheelle olisi varattu enemmän aikaa ja asiaa olisi käsitelty jo ryhmässä siten, että se olisi tukenut itsenäistä työskentelyä . Lisäksi harjoitustyöt olisi mielestäni voitu käydä läpi ryhmässä (vaikkakin tehtävien käsittely jälkikäteen tuntuu olevan varsin vieras käsite yliopistomaailmassa) tällöin myös tehtävissä epäonnistuneet olisivat voineet oppia uutta enemmän.

Meille on tämän syksyn aikana muilla kursseilla ja yhteyksissä toitotettu yhteistyön merkitystä. Itse olenkin ehdottomasti sitä mieltä, että tärkein asia, jonka tänä syksynä olen yliopistossa oppinut on juuri yhteistyön voima. Sekä siltä osin miten sen läsnäolo on lisännyt ja helpottanut oppimista, että myös miten sen puutuminen on vastaavasti asioita vaikeuttanut. Siksi minusta yhteistyöllä olisi tästäkin kurssista saanut huomattavasti enemmän irti. Jos se vain olisi sallittu.

P.S. Tämä portfolio ei taida koskaan saavuttaa sisällöllistä täyttymystään.

P.P.S. Kiitos ja anteeksi tuosta portfolion taustakuvasta.

P.P.P.S. Siinä taustakuvan koodissa on oikeasti jotain järkeä!

P.P.P.P.S. Kiitos ryhmälle (myös sille osalle joka ei loppun asti selvinnyt)!

P.P.P.P.P.S. Rymämme lopullinen jäsenmäärä taitaa olla 5, joten siksi P.S x 5  :)))))

Antti Virtanen

Tehtävä 6 – Pienpelit

Viimeisessä harjoitustyössä saimme tehtäväksemme kirjoittaa Scalalla ohjelman, jossa olisi mahdollista päästä pelaamaan kolmea klassista pienpeliä (eng. minigame): ristinollaa, hirsipuuta sekä ping pongia (jota kutsutaan myös pöytätennikseksi). Tehtävään ei meille annettu valmista ohjelmakoodin runkoa, eli meidän tuli kirjoittaa ohjelma itse alusta alkaen. Itselleni tämä oli varsin posiitiivinen seikka, sillä aiemmilla kierroksilla olen ollut vähän ongelmissa nimenomaan valmiiksi annettujen koodinpätkien kanssa.

Kun ensimmäisen pelin kohdalla olin edennyt jonkin matkaa, oli varsin selkeästi huomattavissa, että syksyn aikana kurssien tarjoama “ohjelmointityyli-propaganda” oli tehnyt tehtävästä varsin tehokkasti. Ohjelman eri osien jaoittelu ohjelmakoodiin, kun näytti kumman tutulta verrattuna kursseilla nähtyihin valmiisiin koodinpätkiin.

Suurin uudistus aiempiin tehtäviin nähden oli nyt siis se, siinä missä aiemmin on pitänyt vain toteuttaa yksittäisiä palsia suuremmasta ohjelmakokonaisuudesta, niin nyt piti itse myös suunnitella ohjelman rakenne ja pitää huoli siitä, että lopullisessa ohjelmakoodissa olisi oma paikkaansa ohjelman jokaiselle palaselle.

Suurimman haasteen tehtävässä ainakin itselleni muodosti swing-grafiikkakirjasto. Eritysesti se, että sai ikkunan elementtien asettelun kuntoon tuotti hankaluuksia. Myös paintComponent metodin ylikirjoituksesta näytti seuraavan varsin outoja asioita, jotka toisaalta ymmärrän, mutta taas toisaalta, “miksi ihmeessä asia pitää tehdä oikesti tehdä näin vaikeaksi”  kun monet muutkin ohjelmointikielet ja kirjastot ovat siinä onnistuneet. Ilmeisesti joitakin vaihtoehtoja swing/awt yhdistelmälle olisi tarjolla, mutta täydellinen tiedonpuute asiaan liityen ei juuri houkuttanut siihen, että olisi kokonaan uuden kirjaston käyttöä alkanut opettelimaan.

Tehtävän kaksi pääpainopistettä olivat siis mielestäni ehdottomasti oman ohjelman rakenteen suunnittelu, sekä grafiikkakirjastoihin tutustuminen. Itse pelilogiikoista vaikeuksia tuotti lähinnä vain pingpong -pelin törmäyksien käsittely. Muilla opiskelijoilla tilanne oli ilmeisesti ollut aika samankaltainen, eli vaikeudet olivat lähinnä painottuneet pingpong -pelin logiikoihin.

Toivottavasti kovin monella opiskelijalla tunnelmat eivät kuitenkaan ollet samat, kuin tällä hirsipuussa epäonnistuneella ukkelilla:

ukko

alkuperäinen kuva: http://www.republicofcode.com/tutorials/flash/hangman/

Antti Virtanen

Tehtävä 4 – Web teknologiat

Tässä harjoitustyössä tehtävänä oli kirjoittaa essee web-teknologioista. Aiempien kirjallisten tehtävien tapaan oli tehtävän anto tälläkin kertaa varsin väliä, joten esseen työstäminen oli käytännössä pakko aloittaa aiheen jonkinlaisella rajaamisella. Lähinnä piti siis päättää kuinka laajasti ja miltä osin käsittelisi mitäkin web-teknilogioiden osa-aluetta. Kaikkia osa-alueita kun tovottiin käsiteltävän jollakin tasolla.

Itse päädyin jakamaan aiheen kolmeen osaan: yhteyteen, palvelimeen ja selaimeen. “Nörttikielellä” siis frontend, backend ja mitä siinä välillä tapahtuu. Yhteyttä käsittelin vain lyhyesti. Lähinnä siiltä kannalta, miten palvelin ja selain kummunikoivat keskenään HTTP- , eli nettisivu-liikenteessä ylimällä ja sille tyypillisimmällä tasolla. Tähän kummunikaatioon kun tavallinen kotikoneen käyttäjäkin voi törmätä varsin usein mm. 404-error viestin muodossa.

Toisesta osa-alueesta, palvelimesta kirjottaessani törmäsin ensimmäisen kerran aiheeseen liittyvään käsitetulvaan. Erilaisia käsitteitä (teknologioita, tuotenimiä yms.) kun on valtavasti. Näistä kun jotkin tarkoittavat samaa asiaa, jotkin melkein samaa asiaa ja joitakin käytetään joissakin yhteyksissä väärin, niin yritä siinä sitten päästä selville siitä mikä on se paras käsite juuri tähän kyseiseen kohtaan omaa tekstiäsi. Pääasiassa päädyin käyttämään eri tuotenimiä, sillä niitten määrittely kun on usein varsin yksiselitteinen.

Palvelinmen käsittelyssä koin tärkeimmiksi osa-alueiksi erilaiset kääntäjän sekä tietokannat. Lähinnä koska koin ne suurimmiksi eroavaisuuksiksi selaipuolen teknologioihin nähden.

Selainteknologioiden käsittelyn tiivistin oikeastaan kolmeen käsitteeseen: html, css ja javascript, sekä siihen mikä kunkin tehtävä nettisivulla on. Näiden erilaisista yhdistelmistä (jQuery, Bootstrap jne.) olisi taas tietysti voinut tarinoida vaikka maailman tappiin asti, mutta päädyin pysyttelemään vain kolmessa käsitteessä itsessään.

Henkilökohtaisesti suurimmat oppimis-saavutuksen käpahtuvat varmaankin palvelin puolen käsitteiden tasolla. Muilta osin en näin laaja-alaisessa esseessä oikein päässyt oman vanhan tietämykseni ulkopuolelle. Ehkä tämän työn olennaisin anti myös muille opiskelijoille oli nimeen omaan aiheeseen liityvät käsitteet. Niiden ymmärtäminen kun helpottaa huomattavasti aiheen pariin palaamista tulevaisuudessa. Aika monilta ohjelmoinnin vasta aloittaneilta kun nimenomaan nämä käsitteet ovat hukassa ja sen vuoksi kulloikin aiheeseen liityvän tiedon löytäminen voi olla vaikeaa. Tästä näkökulmasta tehtävänannon jättäminen laaja-alaiseksi oli mielestä hyvä valinta.

 

Antti Virtanen

OLO5-tapauksen avaus

Ryhmämme koko pienenee kuin tietokoneen vapaan muistin määrä, kun siirryimme tietokonegrafiikkaa ja vuorovaikutusta käsittelevän aiheen pariin. Graffinen osuus herätti huomattavasti vuorovaikutusta paremmin keskustelua. Onhan kyseessä ryhmä tietotekniikan opiskelijoita, joten tämä tuskin tuli kenellekkään yllätyksenä.

Keskustelu (oikeastaan pääasiassa kahden ihmisen välinen sellainen) lähti liikkeelle Javan (ja Scalan) swingistä ja awt:stä. Pohdinnan lähtökohtana toimi ajatus 2d-piirrustus ohjelmasta. Pikkuhiljaa tästä lähdettiin ajautumaan ties minne mm. 3d-grafiikan ja animaation maailmaan.

media-20131218Keskustelun ja Post-it stormauksen jälkeen lopullisiksi itse-opiskelu-aiheiksi valikoituivat seuraavat kokonaisuudet

Vuorovaikutus tms. Scalassa – Karri

2d -grafiikka yms. Scalassa – Antti

Animaation ja piirtämisen optimointi – Esa

3d grafiikka yms. – Markus

Vuorovaikutus siis pääsi kuin pääsikin parempien ideoiden puutteessa mukaan joukkoon.

 

Antti Virtanen