Loppupuheenvuoto

Oho. Nyt se on todella lopussa. Mahtava, aikaavievä, opettavainen, hajoiltu, mieleenpainuva, vaativa ja jännittävä Studio1. Mieleeni muistui hauska mielikuva viime kesältä, kun eräänä päivänä postilaatikkooni kolahti kirje, jossa toivotettiin tervetulleeksi Varaslähtöön tapaamaan tulevia opiskelukavereita. Kirjekuoressa oli myöskin räiskyvän värinen informaatiolehtinen syksyn suuresta opintokokonaisuudesta Studio1:sestä, yhdestä infon ‘omaleimaisista Studio-kursseista’. Muistan lukeneeni esitettä kesän aurinkoisessa lämmössä takapihan terassilla ja ihmetelleeni koko ohjelmointikäsitettä. Ja mitä ihmettä tarkoittaa että jokainen osaa ohjelmoida oman pienen pelin?! Aikaisempi kosketukseni Javaan kun oli se satunnainen kahvikuppi, joka joskus ilmestyi esille pelatessani jotain pikkupeliä netissä. Löysin taannoin tuon samaisen esitteeni ja huomasin lukevani sitä aivan erilaisin miettein. Vasta nyt teksti oikeastaan avautui minulle ja hymyilin huomatessani, kuinka sitä onkaan muuttunut näinkin lyhyen ajan aikana. Näistä mietteistä saammekin sopivan aasin sillan päivän polttavaan puheenaiheeseen: mitä siitä sittein oikein jäikään käteen?

Noh, luonnollinen vastaus on tietenkin tyydyttävät Java-koodaustaidot. Totta tuokin, mutta todellisuudessa Studio1 oli ja antoi paljon enemmän. Kurssin alussa kokoonnuimme oman OLO-ryhmämme kanssa T-talon neukkariin nimeltä Käymistila ja totuttelimme meille jokaiselle uuteen opiskelutekniikkaan. Ensimmäiset OLO-sessiot olivat Javaan johdattelemis tarkoituksensa lisäksi tutustumistilanteita: niissä sai ainutlaatuista ensikosketusta uusiin opiskelukavereihin. Tämä varmasti olikin yksi OLO-ryhmien päämääristä: yhdistää pientä joukkoamme ja opettaa meitä toimimään ryhmässä. Itse koin OLO-sessiot pääasiassa positiivisesti, alkuun oli tosiaan hyvä, että oli myös ihmiskontakteja ja alustusta aiheeseen, ettei meitä suoraan kylmästi isketty näytön eteen koodaamaan. Mukavaa oli myös, että ryhmämme suhtautui OLOiluun asenteella ja keskustelut olivat mielenkiintoisia ja innovatiivisia. Javasoturit-ryhmämme yhteistyö huipentui kuitenkin ryhmäkoodausprojekteihin, irkkibottiin ja robottiin. Ryhmässä koodaamisessa on puolensa, mutta kymmenen hengen porukkamme taisi silti olla hieman liian suuri sujuvaan yhteiskoodaukseen. Kuitenkin nämä projektit opettivat meille jotain ohjelmoinnin sosiaalisesta puolesta.

Itse ohjelmoinnista sen verran, että sitä oli paljon ja opin valtavasti. Koodaustehtävät haukkasivat tosin suuren osan vapaa-ajastani ja vasta myöhemmin ymmärsin, mitä eräs ISO-henkilö naurahti ensimmäisenä päivänä, kun me uudet phuksit tutkailimme väljältä näyttävää lukujärjestystä. Tulin tutuksi myös samaisen henkilön mainostamille perjantai-illoille Paniikissa. Aikaa vievyydestään huolimatta Java-tehtävät olivat olennainen osa kurssia, ja tietynlaisia etappeja matkallamme. Jokaisen tehtävän jälkeen huomasi, kuika sitä ihan huomaamattaan oli oppinut uusia asioita.

Älkäämme unohtako myöskään kurssimme joka toinen viikko tapahtuneita kässeepalautuksia. HTML-muodosssa palautettavia esseitä ja Cmap-toolsilla rakenenttavia käsitekarttojahan oli kurssissamme peräti viisi kappaletta. Käsitekartat oli itselleni uusi ja mielenkiintoinen tapa tutustua uusiin aiheisiin, mutta teoriatehtävien painoarvo kurssiarvosanassa jäi mietityttämään. Useammankin kerran kun tuntui, ettei kässeissämme ollut järjen hiventäkään, sovelsimme “kultaisen kahden prosentin säätöä”. Yhden kässeen painoarvo kun on vain niin vähän. Se ei kuitenkaan vastaa mielestäni teoriatehtäviin käytettävää aikaa, varsinkin jos toivottavaa olisi, että ne tehtäisiin aiheeseen paneutuen. Nyt teoriatehtäviä tehtiin hieman vasemmalla kädellä.. Painoarvosta puheen ollen huomaa hassun painotuksen blogin ja teoriatehtävien suhteen. Blogi painottaa 20% arvosanasta, eli tuplasti sen mitä esseet. Ajankäytännöllisesti laskien jos yhtä teoriatehtävää kohden käytti suunnilleen 5-6 tuntia, olisi kymmenkertaisesti sama aika täytynyt käyttää blogin kirjoittamiseen :/ Vaikka blogista oli ihan mukava lueskella oman ja muiden ryhmien kuulumisia ja kokemuksia, ei blogi mielestäni täyttänyt tarkoitustaan kurssilaisten keskustelufoorumina ja kevennyksenä koodaukseen. Nyt blogikirjoituksista tuli lähinnä pakkopullaa ja ylimääräistä rasitusta koodin lisäksi. Blogin konseptia voisi miettiä uudelleen tai ainakin sen painoarvoa arvosanaan voisi punnita.

Kaikkien kaikkiaan kurssi on ollut huima kokemus, ja uskonkin että sen ainoa tarkoitus ei suinkaan ollut opettaa meitä koodaamaan. Studio1:sen aikana olen tutustunut erittäin hyvin mahtaviin kurssikavereihini, ja olemme lähentyneet ryhmänä aivan eritavalla kuin jos kaikki kurssimme olisi olleet vain C1-tyyppisiä massaluentokursseja. Olen viettänyt hillittömän hauskoja hetkiä uusien ystävieni parissa niin Olkkarilla, Paniikissa kuin Maarillakin, mutta myös hajoillut yksinäni kotona epätoimivan koodin kanssa. Loppuunvetona: kurssista jäi käteen paljon, niin kokemuksia, muistoja, kuin valmiudet Java-ohjelmointiinkin. Ajan kullattua muistot uskon, että muistelen tätä phuksisyksyä aivan erityisellä lämmöllä!

public class Sieni extends Esine {

Javassa löytyy mahtavan yllättävä ja tarpeellinen ominaisuus. Se on luokkien periytyminen. Luokalla voi siis olla yliluokka, jonka käyttäytymistä se perii. Jännittävää on myöskin, että luokalla voi olla monia aliluokkia. Luokat järjestyvätkin näin eräänlaiseen puumuodostelmaan. Periyttäminen on myökin näppärä tapa niputtaa saman tyylisiä luokkia. Esimerkiksi luokasta Koira on helppo tehdä aliluokkia erilaisille koirille ilman, että koodi vaatii paljon muutoksia. Jos meillä vaikka on Koira-luokan aliluokat Mäyräkoira ja Saksanpaimenkoira, ja silti huomaamme, että tarvitsemme vielä luokan Labradorinnoutaja, voimme vain tehdä siitä uuden aliluokan Koiralle. Jos kaikki olisi samassa luokassa, muutoksia tarvittaisiin useisiin paikkoihin tai sitten erilliseen Labradorinnoutaja-luokkaan joutuisi tekemään lähes identtistä koodia kuin muihinkin koiraluokkiin.

Periyttäminen avaa aivan uusia mahdollisuuksia koodaajalle. Periyttämällä jonkun oman luokan jostain valmiista (tai toisesta omasta luokasta) saa käyttöönsä luokan julkiset metodit ja attribuutit. Myös protected-määre avaa ovet metodien käyttämiseksi aliluokassa. Itsekin huomasin tämän koodatessani omaa pallopeliäni. Periytin palloni luokasta Ellipse2D.Double, ja sain käyttööni sen julkiset metodit. Niistä hyödyllisin oli ehdottomasti getBounds2D()-metodi, jonka avulla sain pallon ja kursorin törmäyksen helposti selvitettyä.

Java tarjoaa myös uskomattoman kokoelman pakkauksia ja niissä valtavan määrän luokkia, joista ohjelmoijat voivat mielensä mukaan periyttää omia luokkiaan. Tämä säästää jokaista ohjelmoijaa itseään erittäin paljon, sillä ellei olisi mahdollisuutta periyttää ja käyttää valmiina olevia luokkia, jokainen joutuisi mahdottoman suuren työmäärän eteen. Periyttäminen lyhentää koodirivien määrää: samanlaisten metodien luomisesta jokaiseen luokkaan säästyy periyttämällä kaikki luokat samasta yliluokasta. Esimerkiksi sen sijaan, että tekisi sekä Mäyräkoira- että Saksanpaimenkoira-luokille omat samanlaiset merkkaaReviiri()-metodit, voi vain periyttää kummankin luokasta Koira. Jos metodin toteutuksen halutaan kuitenkin olevan hieman erilainen, on parempana vaihtoehtona tarjolla myös rajapinnat ja abstaktit luokat. Abstrakti-luokka toimii suurelta osin samoin tavoin kuin rajapintakin kuitenkin sillä erotuksella, että luokka voi periä ainoastaan yhden (abstraktin)luokan, mutta toteuttaa monta rajapintaa. Abstrakti yliluokka antaa tosin enemmän mahdollisuuksia: voi esimerkiksi valita kirjoittaako sinne kokonaista koodia vai pelkästään metodeita joiden toteutus määritellään periytyvissä aliluokissa. Rajapintaan kun taas ei voi kirjottaa kokonaista koodia.

Periyttäminen on kuitenkin erittäin hyödyllinen ominaisuus, johon tutustuttiin jo Java1-tehtäväkierroksella. Vaikka silloin tiesin, että Sieni perii luokan Esine, en vielä ymmärtänyt todella mitä se oikein tarkoittaa. Vasta myöhemmin olen löytänyt periytymisen valtavan hienot mahdollisuudet ja valmiiden luokkien hyödyntämisen uusia luodessa.

Parannusehdotuksia.

Laajuudessaan Studio 1-kurssi taitaa vetää vertoja kaikille muille kursseille koko ihmiskunnan historiassa. Kurssin selkärankana toimineet kahden viikon välein palautetut ohjelmointitehtävät olivat kokonaisuutena varsin onnistuneita. Kuitenkin neljän ensimmäisen tehtävän pohjautuminen aina edellisten varaan alkoi syömään motivaatiota. Ymmärrän, että uusien asioiden esittely on helpompaa, kun pohjaa ei joka kerta tarvitse rakentaa uudestaan. Ensimmäiset tehtävät olisi kuitenkin voinut jakaa kahteen erilliseen kokonaisuuteen. Lisäksi ainakin ensimmäisten viikkojen aikana harjoituksia olisi voinut olla enemmän.

Ohjelmointitehtävien välissä palautetut esseistä/käsitekartoista en itsestään löydä sinänsä mitään vikaa. Ohjelmointi on kuitenkin hyvin konkreettista, ja asioihin tutustuminen ja niiden pohtiminen ilman että niitä kokeilee käytännössä ei välttämättä edistä oppimista parhaalla mahdollisella tavalla. Usein kävi niin, että vasta paljon esseen palauttamisen jälkeen, kun ensimmäisen kerran tarvitsi esseessä käsiteltyä aihetta, ymmärsi mitä oli aikoinaan kirjoittanut. Eikä silloinkaan ainakaan omalla kohdalla tullut sellainen olo, että esseistä olisi ollut olleellista hyötyä. Jotain konkreettista olisi esseiden kirjoittamisen yhteydessä pitänyt tehdä.

Kurssiin sisältyi lisäksi täysin irrallisilta tuntuneet robottiturnaus ja bottiseminaari. Erityisesti robottiturnauksessa kävi varsin pian selväksi, että ryhmän sisällä oli havaittavissa selkeitä tasoeroja, eikä tehtävä mahdollistanut erillisten vastuualueiden jakamista. Käytännössä tämä tarkoitti sitä, että ryhmän edistyneimmät keksivät parhaat ratkaisut ja jo ensimmäisen ryhmätapaamisen jälkeen tuntui että oli täysin yhdentekevää mitä muut ryhmän jäsenet tekivät. Bottiseminaaria varten ryhmän jäsenten oli jo huomattavasti helpompi keskittyä omien ominaisuuksien kehittämiseen. Silti, kurssin laajuuden huomioon ottaen, myös tämä tuntui hieman ylimääräiseltä.

Kurssin alkupuolella kokoontuneet OLO-sessiot mahdollistivat dialogin käymisen ryhmän jäsenten välillä, mutta keskustelujen pysyminen liian abstraktilla tasolla ei ehkä näin vasta-alkajille antanut kovin paljon. Sessiot olisivat voineet käsitellä esimerkiksi tulevana viikonloppuna palautettavassa ohjelmointitehtävässä esille tulleita vaikeuksia. Tosin uudenlaisen oppimistavan esittelynä OLO oli mitä mainioin tuttavuus.

Ehkä kurssin ärsyttävin ja omasta mielestäni kaikkein turhin osio oli tämä blogi, poislukien varsin mielekkäiltä tuntuneet portfoliokysymykset. Jos blogin tarkoitus oli edistää ryhmän jäsenten välistä vuoropuhelua, ei se ainakaan omasta näkökulmasta tuntunut sitä tekevän. Dialogia olisi voinut käydä vaikkapa ircissä sovittuina ajankohtina, vaikkakaan mielestäni sitäkään ei tarvita.

Kurssin huipennus, eli oma ohjelmointiprojekti oli ehkä kurssin mielekkäin osio. Se kokosi hyvin yhteen kaikki kurssilla opiskellut aiheet ja päästi valloilleen luomisen innon, mitä ei aina muissa ohjelmointitehtävissä päässyt toteuttamaan.

Kaiken kaikkea, kurssi oli varsin mielenkiintoinen paketti. Itse ehdottaisin keskittymään konkreettiseen ohjelmointiin ja lisäisin ohjeistettuja harjoituksia. Selkeästi vähemmän ylimääräistä härpäkettä ja kirjoittelua.

Kokemuksia S1:stä

Oman ohjelmointihistoriani voisi jakaa kahtia, aika ennen ja jälkeen päivän 12.9.2007. Ennen tuota maagista ajankohtaa tietoni perustuivat tietokonelehtien selailuun ja yläasteen atk-tunnilla Pascalilla kirjoitettuun Hello World! -ohjelmaan. 12.9 sitten istuin kuuntelemassa luentoa siitä kuinka olioon viitataan kaukosäätimellä.

Alku on usein hankalaa eikä Studio 1 ollut poikkeus. Vaikka ensimmäisten Java-tehtävien aikana käytiin läpi vain yksinkertaisia perusteita, nuo asiat vaikuttivat silloin kaikkea muuta kuin selkeiltä. Uuden ajattelutavan, niin matemaattisesti looginen kun se olikin, oppiminen ei tapahtunut ilman ongelmia ja pelkästään Javan syntaksin kanssa tuli tapeltua ihan tarpeeksi; oppimiskäyrä oli vähintäänkin jyrkkä. Hiljalleen koodin kirjoittaminen tuli kuitenkin tutummaksi ja perusasiat alkoivat riittävän toistamisen jälkeen luistaa.

Jotkut inhosivat esseiden ja käsitekarttojen vääntämistä. Itse kuitenkin näen ne hyvänä tapana oppia, tehtävät pakottivat ajattelemaan aiheita, pelkkä koodin suoltaminen ei riittänyt. Ryhmän innostuessa OLO-sessiot toimivat oikein hyvin ja PostIt-lappuja syntyi. Toisaalta välillä syksyn sateisina ja pimeinä iltapäivinä porukka oli niin apaattista, että koko kahden tunnin aikana saadut hyvät ideat oli laskettavissa yhden käden sormin. Kokonaisuutena ongelmalähtöisestä ryhmätyöskentelystä jäi kuitenkin hyvä maku: vaikka joku muu tekniikka olisi joskus saattanut toimia tehokkaampana muistijälkien jättäjänä, antoi ryhmätyöskentely kuitenkin paljon tuoreita näkökulmia omien ajatusten tueksi. Projekti toimi mainiona, joskin raskaana, huipentumana kokonaisuudelle, se testaa opittuja taitoja käytännössä paremmin ja laajemmin kuin yksikään tentti ikinä.

Studio 1 on kieltämättä massiivinen kokonaisuus, varsinkin kun korkeakouluopiskelusta ei ole aikaisempaa kokemusta: kaiken ajan voisi halutessaan käyttää koodin tai esseen hiomiseen ja seuraavaan deadlineen on aina alle viikko aikaa. Välillä logiikkavirhettä yöllä kolmatta tuntia metsästäessä ajatukset liukuivat väkisin Radioheadin klassikkokappaleeseen: “Please could you stop the noise, I’m trying to get some rest..When I am king, you will be first against the wall..” Toisaalta kun virheen sai korjattua, koodin tiivistettyä .jar-paketiksi ja vahvistusviestin perille menneestä tehtävästä sähköpostiin, oli tunnelma vähintäänkin hyvä.

Jonkinlainen kokonaisvaltaisuus on se mitä kurssista jäi päälimmäisenä mieleen: erilaiset opiskelutavat, erilaiset tehtävät, erilaiset ihmiset. Kokonaisuus on äärimmäisen yleissivistävä, tietokoneohjelmia on vaikea katsoa enää samalla tavalla kuin ennen ja neljässä kuukaudessa ehti saada jonkinlaisen käsityksen siitä, mitä isot pojat tekevät Microsoftilla ja Nokialla.  Kunnolla romantisoimalla voisi sanoa, että Studio 1 on enemmän kuin ohjelmointikurssi, se on instituutio, osa infolaista identiteettiä.

SoturiLauri:

SoturiBotin piti olla myös ilkeä, joten se ei voinut vain silittää päätä ja antaa kannustavia neuvoja. Ilkeily-kommentit toteutettiin samalla tyylillä, kuin muutkin

kirjotuksiin reagoivat ominaisuudet: mikäli joku käyttää tiettyjä avainsanoja, kuten “en osaa, irc-kanavalla, vastaa botti siihen piikillä, jonka se arpoo valmiiksi kirjoitettujen piikittelyjen taulukosta. Koska sanoihin reagointi meni päällekkäin useammalla botin ominaisuudella, eri botin alaluokkien toiminta määriteltiin kirjoittajan nimimerkin pituuden jäännösarvon mukaan, kun pituus jaettiin kahdella.

Mitä jäi käteen?

Ensimmäisten ohjelmointitehtävien vääntämisestä tuntuu olevan iäisyys ja hyvän olon tunne sienten ja ninjojen, merirosvojen ja arkkujen kanssa tappelun ollessa takana päin valtaa mielen. Ne uuvuttavat hetket, jotka vietin sienten herkullisuusindeksien ja olentojen sijainnin asettelun parissa, ovat onnekseni tällä haavaa ohitse. Elämä oli yhtä verissä suin puurtamista, jokapäiväinen leipä piti repiä omasta selkänahasta ja assarit vaativat vielä tuhkatkin pesästä.

Ehkä hieman liioiteltu, mutta niin todenmukainen kuva elämäni ensimmäisestä ohjelmointikurssista tiivistyy noihin sanoihin. Nyt kuitenkin tuntuu siltä, että on todellisuudessä oppinutkin jotain. Hyvä ei tule helpolla, sanoi entinen mies. Näin on myös ohjelmointitaitojen suhteen.

Kurssillä käytetyt työmenetelmät, kuten ongelmalähtöinen oppiminen ja itsenäisen opiskelun alleviivaaminen teoriatehtävillä olivat varsin uusia tapoja opiskella, mutta kävi nopeasti ilmi, että näihin raameihin oli sopeudeuttava, mikäli ohjelmoinnista halusi jotain lopulta tietääkin. Kun asioista piti itse ottaa selvää, piti oppia aiempaa säntillisemmäksi toimissaan.

Itse koin jatkuvan tehtävätulvan alussa hyvinkin ahdistavalta. Koko ajan oli lähestymässä seuraava deadline ja varsinkin viikkojen pyörähtäessä loppupuoliskolleen, saattoi tuntea pienen stressipirun soittelevan riitasointuisia sävelmiään olkapäällä. Tähän onneksi kuitenkin tottui, kun pari kolme viikkoa oli kurssin parissa vierähtänyt. Lauantai-iltaiset tehtävien palautukset loivat turvallisen väylän syyslauantaiden viettoon baarin huuruisissa nurkissa.

Kurssisällön omaksuminen oli näin jälkikäteen tarkasteluna helpointa teoriatehtävien ja itse koodauksen lomassa, kun hyvät alkutiedot oli esseillä ja käsitekartoilla muodostettu. OLO-tapausten merkitys itse oppimisprosessissa jäi mielestäni hieman toissijaiseksi, vaikka itse oloilu oli varsinkin alussa hauskaa vaihtelua tavanomaisiin oppimismenetelmiin. OLO-sessiot ohjelmointikäsitteiden omaksuminen jäi melko vähälle, kun teoriatehtävät olivat jo asiansa ajaneet.

Suurin kysymysmerkki kurssissa oli mielestäni blogin merkitys oppimisessa. Blogikirjoitukset tuntuivat varsin irralliselta osalta koko muuhun kurssiin verrattuna, vaikka blogin tarkoituksena toisaalta oli OLO-sessioiden muodollinen kontrollointi. Bloginkirjoitusten merkitys opiskelussa jäi mielestäni hyvin vähäiselle, joten sen suhteen kurssia tulisi ainakin omasta mielestäni kehittää. On tietysti helppo arvostella ilman vastauksia, mutta tällä kertaa soorun siihen surutta.

Lopuksi voin todeta kurssin olleen pääosaltaan mielenkiintoinen kokonaisuus, jolta jäi runsaasti uusia tietoja ja taitoja käteen. Työmäärältään kurssi oli herkullinen ja sen ollessa takan on helppo hymyillä ja jatkaa uusin eväin kohti kevättä.

Mitä hyötyä on rajapinnoista?

Yksi olio-ohjelmoinnin perusominaisuuksista eli eri luokkien periyttäminen toisistaan mahdollistaa monia olio-ohjelmointiin liittyvistä positiivisista toiminnoista. Kuitenkin ainakin Javan tapauksessa yksi luokka on mahdollista periyttää ainoastaan yhdestä yläluokasta. Tämä asettaa tiettyjä rajoituksia muuten niin mainiolle periytysmenetelmälle. Saattaa tulla tilanteita, joissa luokan halutaan omaavan ominaisuuksia, joita yläluokka ei omaa, mutta joita monen eri luokan tulisi toteuttavan niin, että saadaan vakuutus siitä, että alaluokat omaavat tietyt metodit.

   Tähän ongelmaan Java tuo ratkaisun niin sanotuilla rajapinnoilla, joita luokkia voidaan pakottaa toteuttamaan. Tämä tarkoittaa käytännössä sitä, että rajapinnan toteuttava luokka omaa ja toteuttaa kaikki rajapinnassa määritellyt metodit. Itse rajapinnassa metodien toiminnallisuutta ei määritellä, joten jokaisella rajapinnan toteuttavalla luokalla määrätyt metodit voivat omata aivan omanlaista toiminnallisuutta. Tämä mahdollistaa muun muassa Javan valmiiden rajapintojen kanssa toimittaessa sen, että kaikki rajapinnan toteuttavat luokat ovat kykeneväisiä toimimaan tiettyjen Javan valmiiden metodien kanssa. Luokan toteuttaessa rajapinnan ei ole kuitenkaan pakollista, että rajapinnan määrittelemät metodit luokassa omaisivat minkäänlaista toiminnallisuutta.

   Rajapintojen käyttö on erityisen järkevää sellaisissa tilanteissa, kun kahden eri yläluokista periytyvän metodin halutaan omaavan samoja metodeja. Esimerkiksi ”Koira”- ja ”Kissa”-luokan halutaan omaavan metodit ”nuku()” ja ”herää()”, voidaan niiden määritellä toteuttavan rajapinta ”Nukkuva”, joka sisältää edellä mainitut metodit. Näin kyseisten luokkien voidaan turvallisesti olettaa toteuttavan rajapinnassa määritellyt metodit. Kun koodissa emäntä herättää kaikki koirat ja kissat, kutsuu hän vain kaikkien ”nukkuvien” olioiden herää()-metodia.

   Rajapinnat ovat varsin oleellinen lisä Javan perusominaisuuksiin, joista yksi on juuri rajapintojen hyödyllisyyttä tukeva moniperiytyvyyden puuttuminen. Javan valmiit rajapinnat tarjoavat työkaluja niin erilaisten olioiden vertailusta aina hiiren liikkeiden tarkastelemiseen.

Miten toimin opiskellessani ohjelmointia?

Studio 1-kurssi oli ensimmäinen koskaan käymäni ohjelmointikurssi, joten kokemukseni ohjelmoinnin opiskelusta perustuvat täysin tämän syksyn koettelemuksiin. Alusta alkaen kurssi antoi eväitä oman opiskelutyylin löytämiseen, mutta ohjasi opiskelijan ottamaan asioista ensin selvää ja toimimaan vasta sen jälkeen. Tämänkaltainen prosessi syntyi ongelmalähtöisen oppimisen, käsitekarttojen tekemisen ja esseiden kirjoittamisen myötä. Käsitekarttojen ja esseiden tekemisen kautta Java-ohjelmointiin liittyvistä peruskäsitteistä sai hyvän kuvan, jonka jälkeen sitä vielä tarkasteltiin eri näkökulmista ongelmalähtöisen oppimisen avulla. Opiskelutovereiden mielipiteet ja käsitykset toivat uusia näkökulmia asioihin ja ohjelmoinnin käsitteistä syntyi yhä parempi kuva, jota pyrittiin soveltamaan aina seuraavassa ohjelmointitehtävässä. Näin itse koodauksen aloittaessa opiskelija omaa jo pääpiirteissään tiedot rakenteiden ja käsitteiden toiminnasta.

Itse toimin kyseisenkaltaisella tavalla ennen itse koodausprosessia, jonka yhteydessä pyrin syventämään tapauskohtaisesti tietojani muun muassa Java-APIn ja Sunin Java Tutorialin avulla. Olotapausten yhteydessä asioita ei ollut tarkoituksenmukaista käydä läpi juurta jaksain metodikohtaisesta, joten koodatessa metodien toiminnan selvittäminen oli tärkeää. Pyrin aina ensin ottamaan eri rakenteiden ja metodien toiminnasta yksityiskohtaisesti selvää, ennen kuin sovelsin tietoja käytännön tasolla. Tämä toimintatapa tuntui alusta asti järkevimmältä sen sijaan, että olisin kokeillut eri toimien vaikutusta järjestelmällisesti selvittääkseni käsitteiden käytännön toimintaa. Tämä olisi näin jälkikäteen ajateltuna vaatinut edes hieman ohjelmointikokemusta, jota itse en valitettavasti ennen kurssia omannut. Varsinkin Java-APIn avulla metodien toiminta tuli kerralla selväksi, eikä turhaan kokeiluun tuhraantunut aikaa. Tässä oli kuitenkin myös hieman tapauskohtaista vaihtelevuutta, kun joidenkin ohjelmointikäsitteiden käytön opettelu eteni yrityksen ja erehdyksen kautta. Tällaisia tapauksia olivat muun muassa iteraattoreiden ja erilaisten looppien yhteensovittaminen. Kokeilu oli loppujen lopuksi esimerkiksi tässä tapauksessa paras keino ymmärtää rakenteiden toimintaa.

En voi vetää suoraviivaista linjaa ohjelmoinnin oppimisprosessin kululle, sillä tapaukset eivät olleet kurssin aikana samanlaisia. Pääosassa toimintatapa noudatteli kuitenkin tiedonjanoisen oppijan polkua, jossa oppiminen tapahtui lukemisen ja tiedon etsimisen kautta. Onnistunutta koodia on helpointa saada aikaan, kun oli selvä käsitys koodin toiminnasta.

Entäpä jos luokkia ja olioita ei olisi?

Ennen Studio 1-kurssia oma ohjelmointiosaamiseni rajoittui lähinnä villeinä nuoruusvuosina QBasicillä väännettyihin tekstipeleihin. Kymmenvuotiaalle Altille suurin ylpeyden aihe oli yli kaksituhatta riviä pitkä Star Wars aiheinen seikkailupeli. Koko komeus oli samaan pötköön kirjoitettu, eikä luokista, metodeista tai olioista ollut tietoakaan. Eipä tarvinnut Altin silloin miettiä, mitä luokan X pitää voida käyttää luokasta Y, ei ollut murheita näkyvyysmääreiden merkityksen ymmärtämisen kanssa, eikä tarvinnut vaivata päätä järkevän luokkarakenteen miettimisellä.

Lukiossa päätin tutustua uuteen ohjelmointikieleen ja valitsin C++:n peruskurssin. Hermohan siinä meni, kun tehtävät olivat (myöhemmin myös Javaan perehtyessä tutuksi tulleen) “Hello world!”-ohjelman tasoisia. En ymmärtänyt mikä järki oli käyttää olioita, kun samat asiat pystyi tekemään Basicilläkin ilman niitä. Viime syksy tutustutti minut uudestaan ohjelmoimisen maailmaan, ja sai minut vihdoin tajuamaan luokkien ja olioiden merkityksen. Kaivoin esiin vanhat tekstiseikkailupelini ja ymmärsin miten kömpelöä on toteuttaa ohjelma ilman että se on jaettu selkeisiin osakokonaisuuksiin. Asioiden toistoa ei pysty välttämään, kun ei ole tapaa viitata vaikkapa nopan toteuttavaan osaan ohjelmassa, ilman että ohjelma menettää tiedon siitä, missä päin Tatooinea Luke sillä hetkellä seikkailee. Erillisiä, lähes metodimaisia osia toki pystyi luomaan jo Basicissa, mutta sellaiseen osioon viittaaminen sujuvasti muun toiminnan ohessa, tuntui silloin ja myös näin jälkikäteen, jos ei mahdottomalta, niin ainakin äärimmäisen hankalalta. Ilman olio-ohjelmoinnin mukanaan tuomia hienouksia pelin hahmot ovat vain kasa täysin toisistaan irrallisia muuttujia. On huomattavan paljon vaikeampaa, kun jonkin luokan ilmentymän sijaan joutuu joka kerta määrittelemään tarvittavat muuttujat. Muuttujien määrän kasvaessa niiden hallinnointi muuttuu yhä vaikeammaksi.

En aikoinaan tutustunut ohjelmien visualisointiin, ja näin jälkeenpäin ajatellen, hyvä niin. Ohjelman mennessä riittävän monimutkaiseksi (tällä kurssilla se hetki lienee ollut Swingin mukaan tulo) tulee luokkien olemassaolon edut ilmiselviksi. Usein toisteltu ohje ohjelman käyttöliittymän ja logiikan erillään pitämisestä paitsi helpottaa koodin hahmottamista, myös yksinkertaistaa muutosten tekemistä myöhemmässä vaiheessa. Ilman erillisiä luokkia jaon toteuttaminen on lähes mahdotonta. Tilanteessa jossa ohjelmaa on kehittämässä useampi henkilö, lienee selvää että vastuualueiden jakaminen on hyvin vaikeaa jos ohjelman eri osa-alueita ei jaeta selkeästi omiksi kokonaisuuksikseen. Oliot ja luokat eivät ole vain kosmeettisia, kokonaisuutta selkeyttäviä asioita, vaan ne mahdollistavat monien sellaisten asioiden toteuttamisen, jotka muuten olisivat mahdottomia.

Työtä ja välineitä

“Niin, miten tämä suljettiinkaan?” Syyskuun alussa otettiin ensimmäiset varovaiset askeleet Javan salaperäiseen maailmaan. Ihan kun tässä ei olisi ollut tarpeeksi, myös ohjelma oli vähintäänkin outo, Emacs. Siirtyminen graafisesta XP-Vista-KDE-Os X -karkkimaailmasta karuun ja silti massiiviseen outojen pikanäppäinten, toimimattoman copy-paste -ominaisuuden ja hassun logiikan maailmaan ei ollut helppo. Olihan Emacsissa hienojakin ominaisuuksia: Java-koodi sisentyi nätisti ja ohjelma pyöri ripeästi etäyhteydenkin kautta. On ehdottomasti oikea ratkaisu tehdä alkupään tehtävät editorilla joka ei päästä koodin kirjoittajaa liian helpolla. Jos olisin heti tarttunut Eclipseen tai muuhun virheistä varoitteleviin ohjelmaan Javan syntaksi ei varmasti olisi luonut kaikkia niitä synapseja kun se nyt loi. Monen hehkuttama Emacs ei kuitenkaan muodostunut minulle jumalan sanansaattajaksi jollaisena se monien puheessa esiintyy. Vaikka pikanäppäimiä kuinka oppi, aina tuntui siltä, että kaiken voisi tehdä helpommin, selkeämmin ja toimivammin. Ohjelma saa toki olla yksinkertainen, mutta voisi olettaa, että silloin se olisi myös selkeä. Minulle Emacs ei ole sitä vieläkään. Kaikkein raivostuttavinta oli ikuinen kaatuilu ~joka kolmannella kerralla tekstiä leikepöydältä liitettäessä.

Vanhasta kaksitasosta Concorden ohjaamoon siirtyessä on varmaan jokseenkin sama tunne kuin ensimmäistä kertaa Eclipsen avautuessa Emacsin kanssa taistelun jälkeen. Kaikki on huimasti huimasti tehokkaampaa, nopeampaa, automatisoidumpaa ja kauniimpaa, säädettäviä nappuloita on kymmenkertainen määrä ja systeemi toimii ilman sen kummempaa arpomista. Eclipse on ohjelmana huiman laaja enkä vielä kurssin lopussakaan osannut käyttää kuin murto-osaa sen tarjoamasta potentiaalista. Silti se tarjosi minulle sen, mitä siltä kaipasin: se hoiti rutiininomaiset tehtävät antaen täyden vapauden keskittyä olennaiseen eli luokkarakenteiden suunnitteluun, eri vaihtoehtojen pohtimiseen ja mahdollisimman järkevän rakenteen luomiseen. Yksi parhaista ominaisuuksista oli uusien luokkien tuominen automaattisesti, varsinkin Swing-komponenttien kanssa leikkiessä tämä säästi huimalta määrältä kirjoitettuja rivejä. Kaikkine valikkoineen Eclipse oli graafisen käyttöliittymän aikana elämänsä eläneelle melko intuitiivinen ja helposti lähestyttävä kokonaisuus, ja varmasti se ohjelma jonka avaan jos vielä joskus jotain Javaan liittyvää teen.