Javasoturi kävi taistoon

Bottiseminaari on nyt kunnialla ohi! Javasoturi aloitti pitkän taipaleensa kohti Studio1:n pääassaruutta. Se käyttäytyi kiltisti ja oli suostuvainen esimerkkiassaroimaan eikä ujostellut suuren yleisön edessä. Javasoturi-botin kaikki ominaisuudet esiteltiin, ilmoille kajahti niin javaviisauksia, teekkarihymni kuin kehotuksia taukojumppaankin. Assarin ominaisuudessaan Javasoturi jakeli myös linkkejä Java-APIin ja luentokalvoihin.

Tarkempaa tietoa Javasoturin ominaisuuksista ja niiden toteutuksesta seurannee myöhemmin.

Edit Antti 1.12: Javasoturin mahtavat esittelykalvot löytyvät alta:

Javasoturi esittely pdf

Javasoturi esittely ppt

Viimeinen tapaus

Ei, en ole Sir Arthur Conan Doyle eikä kirjoitus liity nimestä huolimatta mitenkään piippu suussa kulkevaan salapoliisiin. Sen sijaan se kertoo tapaamisesta T-talon geneerisessä neukkarissa, jossa Javasoturit jakoivat viimeisen kerran tietoa toisilleen. Ei enää pälyileviä katseita uutta puheenjohtajaa haettaessa, ei enää uusia Post-It -lappuja, ei enää uusien nimien keksimistä Paulille. Yksi aikakausi Studio 1:llä päättyi.

Avauksessa valitut oppimistavoitteet liittyivät poikkeuksetta Swingiin ja jokainen läsnäolija olikin hoitanut omaan tutkimuskohteeseensa tutustumisen. Monien käsitteiden nimet kuulostivat etäisesti tutuilta johtuen Swingiä käsitelleestä essee-tehtävästä ja Java 5:n ensimmäisistä osatehtävistä. Saimme nähdä Lauran lähde-kuuntelija -kaavion ja kuulla Taijan esitelmän asettelijoista. Mikko (se assari-Mikko) kertoi BorderLayoutin monipuolisemmasta käyttämisestä sisäkkäin useammassa komponentissa. Sovittujen J*-komponenttien yleiset piirteet kävivät selviksi.

Mitä siitä OLOilusta sitten jäi käteen? Aluksi Post-It -lappujen kirjoitteleminen ja taululle piirtely tuntui aika jännältä. Kontrasti jättimäisiin luentosaleihin oli vähintäänkin tyly. Opiskelija riisutaan kaikesta anonymiteetistä, pakotetaan osallistumaan. Toisaalta tarjotaan mahdollisuus kysyä tyhmiä. Kuinka moni viittaa kesken Hakulan luennon jos ei ymmärrä mitä taululle kirjoitettiin? Niitäkin ihmisiä on, onneksi. Itse en kuulu siihen joukkoon. Kaikenkaikkiaan tuntuu siltä, että kyseinen opetusmetodi sopii loistavasti Javan alkeiden opetteluun. Ei ole mitään mieltä laittaa professoria puhumaan täysille untuvikoille peruskäsitteistä kun he voivat helposti, nopeammin ja ehkä jopa paremmin tuloksin etsiä saman tiedon kirjasta tai Javan lähinnä raamattua muistuttavasta API:sta. Eri käsitteiden dokumentaatio on niin laaja ja tieto on niin helposti etsittävissä, että määritelmien löytäminen ei vaadi mahdottomia työmääriä tai yli-inhimillisiä taitoja.

Viimeinen tapaus ei jäänyt Sherlock Holmesin viimeiseksi esiintymiseksi. Myös Javasoturit tapaavat vielä ainakin kerran, samaisessa geneerisessä neukkarissa, aiheenaan tällä kertaa projekti. Vielä kun keksisi jonkun aiheen.

Projektia pukkaa

Stressaa. Tänään puhuttii OLOssa ja myöhemmin olkkarilla vähän projekteista ja niiden aiheista. Aihe alkoi ahdistaa, itselläni kun ei vielä ole mitään fiksua ideaa, ei siis edes ideatasolla toimivaa.. Vaikeinta ideoiden keksimisessä on ettei ollenkaan tiedä mihin pystyy. Tähän ei niistä assareiden neuvoista “oikeestaan sä voit tehdä ihan mitä vaan” ole kauheasti apua. Olisikin kiva jos kuulisi vähän kuinka vaikeita eri jutut on toteuttaa (ja ylipäätänsä jotain kaikista noista graafisista jutuista ym) ja minkälaisia asioita ei välttämättä kannata ainakaan aivan heti lähteä yrittämään.. Näin. Ei tässä sitten muuta. Piti purkaa.

Java-tehtävä 4: Pelaajan alter ego

Java-ohjelmointisarjamme neljännessä tehtävässä viimeisteltiin luomamme pelimaailma lisäämällä peliin pari olentojen liikkeisiin reagoivaa olioita, yksinkertainen vuorottelujärjestelmä sekä sokerina pohjalla käyttäjän ohjaama pelaaja.

Tehtävä sisälsi uusia asioita reilusti enemmän kuin aikaisempi ohjelmointiurakka. Luokkarakenteisiin tuudittautuneet ohjelmoijat saivat heti tehtävän alussa kolauksen, kun eteen heitettiin rajapintaluokan käsite. Javan rajapintaluokkia käytetään usein, kun halutaan taata jonkin luokan tietty toiminnallisuus. Ne toimivat melkein kuin abstraktit luokat, jotka sisältävät pelkästään abstrakteja metodeja. Tässä tehtävänä oli määrätä muutamille maailmamme olioista kyky tarkkailla ympäristöänsä rajapinnan Sektorintarkkailija avulla.

Sektorintarkkailija ninja väijyy pahaa-aavistamatona sienestäjää.

Erityisen haastavana koin pelimoottorisysteemin rakentamisen. Luokat Pelimoottori, pelaajan omaa sankaria ohjaava Avatar sekä lopulta koko sovelluksen käynnistävä Peli täydensivät kaikki toisiaan, jolloin muutos yhdessä luokassa saattoi vaikuttaa ratkaisevasti toiseen. Oli mukavaa huomata, kuinka tehtävänanto antoi ensimmäistä kertaa melko vapaat kädet systeemin toteutukseen. Tämä vaati toisaalta paljon omaa ajattelua ja pakotti aktiiviseen tiedonhakuun.

Ensimmäistä kertaa käyttäjä pääsi itse kirjoittamaan konsoliin ja näin vaikuttamaan pelin kulkuun. Merkkijonojen lukemiseen ja tulkitsemiseen käytettiin merkkivirtaa BufferReader. Nyt kävi viimeistään selväksi myös pääohjelmametodin String[] args – lausekkeen merkitys komentoriviparametrien keräämistaulukkona ohjelmaa käynnistettäessä.

Koin neljännen ohjelmointitehtävän melko haasteellisena, mutta erityisen palkitsevana, kun peliä pääsi ensimmäistä kertaa oikeasti pelaamaan ja vaikuttamaan lopputulokseen. Älytön kiire pakotti minut palauttamaan tehtävän harmillisesti hieman keskeneräisenä. Ei auttanut, vaikka piiskasin itseäni saamaan urakkaa valmiiksi aamun pikkutunneilla ninjojen, merirosvojen ja tryffeleiden pomppiessa seinillä. Javadoc-kommentoinnin olisi myös voinut hoitaa jo vaikkapa aikaisemmassa tehtävässä, sillä nyt koin sen vain mukaan ahdettuna ärsykkeenä.

Botti alkuun

Soturibotin toteutus alkoi perjantaina iltapäivällä. Koodasimme pircBotin ohjeiden avulla botin perusosat, ja saimme liitettyä sen irc-kanavalle.  Varsinainen botin toiminta-ajatus ei vielä selkiintynyt. Ilmeisesti päädymme vaihtoehtoon, jossa jokainen kooda yhden luokan, ja samalla tekee botille jonkin toiminnallisuuden. Toiminnallisuuksia on tietenkin tarkoitus koordinoida siten, että ne sopivat yhteen. Oletettavasti Soturibotista on tulossa monitaituri, kuten soturin toisaalta kuuluukin.

Purku number 7

Edellisviikon OLOsessiossa olimme kirjanneet oppimistavoitteiksi lähinnä kaikkea botteihin ja bottien toimintaan liittyvää. Muutama oli myöskin saanut oppimistavoitteekseen tutustua itse irciin, mutta näiden oppimistavoitteiden purkamisen jätimme vähemmälle

Bottihakusanoilla löytyy Googlesta lukemattomia sivuja ja itse esimerkiksi etsiessäni inhimillisen botin piirteitä Internetistä, päädyin lukemaan monenlaisia hauskoja pätkiä ihmisten ja bottien välisistä keskusteluista. Puhealgoritmejä itsessään oli kuitenkin hankalampaa löytää. Joka tapauksessa “tutki botteja”-tyyppiset oppimistavoitteemme eivät olleet kovinkaan hedelmällisiä kertoilla kaikille muille, joten purku sujui kohtalaisella speedillä.

Sitten muutama sama omasta rakkasta SoturiBotista: yksissä tuumin olimme sitä mieltä, että parhaiten SoturiBotti (tai tässä vaiheessa lähinnä botin idea) kehittyy sillä tavoin, että jokainen itseksemme mietimme yhden hyvän toiminnan, jota kokoonnumme sitten yhdessä koodaamaan. Koko porukka oli myöskin enemmän kiinnostunut tekemään nimenomaan ‘ihmillistä bottia’ eikä niinkään usean !-komennon toteuttavaa yleiskonetta. Perjaintai-extrassa sitten jatketaan!

Järjestelmä.ulos.tulostinrv()

Aamun javailun innoittamana rupesin tässä pohtimaan, että mitenkäs ne tulostukset oikeastaan menevät, eli mitenkä saan systeemistä ulos jotain näkyvää. Samoin tietovirran käsite on minulla vielä hieman hakusessa.

Luulin aiemmin, että String to string metodi tulostaisi jotain, mutta sehän palauttaakin vain merkkijonon.

Joku sanoi, että virhetulostukset pitäisi tehdä system.err.println() -metodilla, jolloin ne kyllä tulostuvat ruudulle, mutta päätyvät samalla johonkin virheilmoituspaikkaan. Olikohan niitä tarkoitus käyttää neljännen javatehtävän osatehtävässä 4.2?

Voisikohan tietovirtoja ajatella jotenkin kaksisuuntaisina? Siten, että kun käyttäjä tekee jotain, esim. kirjoittaa näppiksellä, siirtyy tietoa suunnassa konsoli->ohjelma. Kun taas ohjelma tekee jotain, esim. kirjoittaa näytölle, siirtyy tietoa suunnassa ohjelma->konsoli. Onko tietovirta aina jotain, joka menee systeemin ulkopuolelle tai tulee sieltä? Onko tietovirtoja myös ohjelman sisällä?

Tämä ei selvittänyt varmaan kenellekään mitään.

Muisteloita Java 3-tehtäväkierrokselta

Vaikka kolmostehtävästä tuntuu nyt vierähtäneen jo pieni ikuisuus, koitan muistella silloin mieleni pinnalla liikkuneita asioita. Tällä kierroksella opimme muun muassa heittelemään ja käsittelemään poikkeuksia. Myös iteraattori ja kokoelmien läpikäynti tulivat läheisesti tutuiksi. Lisäksi opimme abstraktin luokan käsitteen ja käytön. Jo tehtävän alkupuolella kompastelimme suureen kiveen nimeltä rekursio. Kahden eri luokan toisiaan kutsuvien metodien välillä temppuilu aiheutti suuresti päänvaivaa ja ensimmäisen kerran joutui toden teolla pohtimaan, miten toteutus olisi mahdollista ja mitä tehdä, ettei tulisi StackOverflowErroria.

Mukavaa oli, että pääsimme vihdoin luomaan pelimaailmaamme erilaisia olentoja; ninjoja, merirosvoja ja sienestäjiä, jännää! Eniten ongelmiä näitä luokkia ohjelmoidessa aiheutti ehdottomasti teeSiirto()-metodit. Helpotus oli kuitenkin aina suuri, kun testejä ajettaessa konsoliin printtautui “onnistui” sen tavallisen “VIRHE!”-tekstin sijaan. Näiden virheiden metsästäminen olikin mielestäni yksi kierroksen haastavimmista osa-alueista. Sen sijaan, että konsolissa näkyisi, että NullPointerException rivillä 103, saimme ainoastaan tietää, että VIRHE esiintyi. Näiden virheiden etsiminen omasta koodista oli opettavaista (joskin rasittavaa) ja tämän jälkeen omien loogisten virheiden löytäminen on ollut helpompaa. Lisäksi tällä tehtäväkierroksella itse ainakin loin vielä valtavia if-lause viidakoita, siistimmin looppaamaan olen oppinut vasta myöhemmin.

Edellisen tehtäväkierroksen jäljiltä en ollut kovin javaisella tuulella, sillä sen arvosana aiheutti suuren pettymyksen (valtavasti aikaa käytetty, kaikki osatehtävät tehty, mutta kuitenki hämäävästi oikein toimivan ohjelman kaksi toisensa kumoavaa virhettä laski arvosanaa rankasti). Kuitenkin tämän kierroksen palaute ja arvosana 4 nostivat tunnelmaa kummasti ja toivat lisää luottoa omiin taitoihin. Seuraavan tehtäväkierroksen alussa olin taas asteen innokkampi.

Kolmas essee: Poikkeukset

Kolmas teoriatehtävä käsitteli Javassa esiintyviä poikkeuksia. Tällä kertaa tehtävän tekijä sai itse päättää, tekikö teoriatehtävän essee vai käsitekartta muodossa.

Vaikka edellisten teoriatehtävien perusteella käsitekartan tekeminen tuntui mukavammalta, poikkeukset Javassa oli sen verran rönsyilevä aihe, että päädyin tekemään tehtävän essee-muodossa. Seuraavana aiheesta summa summarum:

Poiketen monista muista ohjelmointikielistä Java tarjoaa ohjelmoijalle mahdollisuuden varautua ajonaikaisiin virheisiin käyttämällä poikkeusmenettelyä. Javassa virhe aiheuttaa poikkeuksen, jonka käsittelemällä ohjelmoija pystyy ennaltaehkjäisemään ohjelman kaatumisen virheen sattuessa. Kuten arvata saattaa, myös poikkeukset ovat Javassa olioita, jotka ovat luokkiensa ilmentymiä. Näin myös poikkeuksilla on keskenään erilaisia ominaisuuksia.

Poikkeukset voidaan käsitellä try-catch -lauseen avulla, jossa poikkeuksen mahdollisesti aiheuttava metodi sisällytetään try-lohkoon. Mikäli poikkeus aiheutuu, jatketaan koodin suorittamista catch-lohkolla, johon ohjelmoija on määritellyt poikkeuksen jälkeiset toimenpiteet. Mikäli ohjelman halutaan suorittavan tietty komento joka tapauksessa riippumatta siitä, ilmenikö metodia suorittaessa poikkeuksia, voidaan käyttää finally-lausetta.

On kuitenkin tapauksia, joissa poikkeusten käyttäminen on turhaa ja joista selvitään vähemmin resurssein poikkeuksia käyttämättä. Yleensä tällaisia tapuksia ovat tilanteet, joissa virheiden ilmeneminen on ennemminkin oletettavaa kuin epätodennäköistä.