You are currently browsing the category archive for the 'Teoriatehtävät' category.
Ja niin koitti sekin pimeä marraskuinen päivä, jolloin oli aika palauttaa viimeinen teoriatehtävä. (Koittipa myös se tammikuun päivä, jolloin eräs henkilö muisti unohtaneensa kirjoittaa aiheesta. Ei siitä sen enempää.) Tuo viimeinen tehtävä käsitteli säikeiden toimintaa ja käyttöä java-kielessä. Swingistä selvittyäni olin varautunut vähintään yhtä kylmään kyytiin ja suureen svengaamattomuuden tilaan säikeiden kanssa. Oli kuitenkin jonkinasteinen helpotus kun osoittautui, että säikeiden toiminta vaikuttaa ihan ymmärrettävältä touhulta, vaikka mitään käytännön kokemusta minulla ei asiasta ollutkaan.
Säikeiden perimmäinen tehtävä on pelastaa ihmiskunta rinnakkaisuuden haasteilta. Mikäli ohjelmaan olisi tarkoitus saada kaksi asiaa toteutumaan yhtä aikaa, nuo pienet huijarit suoriutuvat asiasta niin, että jakavat asiat pieniin osiin, joita sitten suorittavat vuorotellen. Varsin toimiva ratkaisu.
Säikeiden hallinnan tärkeimmät osa-alueet ovat prioriteettien määrittäminen sekä säikeen suorittamisen pysäyttäminen tai keskeyttäminen. Ne kun osaa, niin tietää jo paljon. Ainakin siltä nyt tuntuu.
Vaikka säikeiden toiminta oli mielestäni helpompaa ymmärtää kuin swingin, on kirjaviisaus kuitenkin aina kirjaviisautta. Käytännössä vähänkään vaativamman säiekoodin tuottaminen saattaisi tuttuun tapaan tuottaa harmaan hiuksen, kun taas swingi svengaa jo kohtuullisesti. Käytännön kokemus vasta opettaa. Kalakirja luo vain harhakuvitelmia.
“Parempi myöhään kuin ei milloinkaan”, sen tiesi jo Taikapeili näin laulaessaan. Eli, tämä tekstini käsittelee luokkia ja olioita Javassa, ensimmäistä armasta esseetehtäväämme. Toisaalta on ihan vinkeä palata ajassa taaksepäin ja muistella niinkin kaukaisia menneitä, ehkä siitäkin taas oppii, kun miettii näitä asioita uudestaan ihan näin kirjallisesti. Niin tai näin, täältä pesee.
Java on oliopohjainen ohjelmointikieli (kuten joku jo ehkä tietää), joka luotiin tuottamaan helpotusta c:n ja c++:n ääressä taisteleville. Se on käyttöjärjestelmästä riippumaton ohjelmointikieli, joka on (olevinaan) helppo ja mahdollisimman yksinkertaisesti ymmärrettävissä oleva(yhtä ymmärrettävä kuin edellinen lause). Sen suurin erikoisuus ja erkanevuus elikkäs ero tuosta kantaisiensä (c, c++) toiminnallisuudesta on se, että Javassa ohjelma käännetään ensin tavukoodiksi, jonka jälkeen tavukoodi ajetaan Java-tulkilla. Tämä mahdollistaa sen, että samoja ohjelmia voi ajaa eri ympäristöissä, niin Windowsilla kuin Linuxillakin. Pitkien filosofisten pohdintojen jälkeen selvisi myös, että Javan tärkeimmän herrain roolia miehittävät oliot, jotka ovat luokan ilmentymiä. Javalla on myös käytössään kattavia luokkakirjastoja, joita on erittäin kiva ja mukava ja vinkeä hyödynnellä koodissaan.
Esseetä kirjoittaessani en vielä tienny, kuinka ihana API onkaan. En muuten tainnut edes tietää, mikä on API. Kaikkea oppii. Tämä oli matalalentoinen sivuhuomautus.
Arkielämän hierarkisointi on huomaamatonta ja salakavalaa. Tiedämme helposti, että koira on eläin samoin kuin kissa, tuoli ja pöytä ovat huonekaluja, tissit ja käsivarsi ruumiinosia ja niin eespäin. Ja siis tämähän on aivan psykologista, ihmisellä on tarve luokitella asioita, jotta järki pysyisi päässä eikä maailma kaatuisi niskaan. Olis se raskasta, jos kaikki olisi vaan soppaa ja salaattia. Eikä sitten lopulta erottais niitäkään! Noniin, Javassa tämä samanmoinen systeemi on otettu oivasti käyttöön, ryhmittelemisen hierarkia on kuin luokka, esimerkiksi Eläin-luokkaan voisi kuulua juuri edellä mainittu koira-olio ja Ruumiinosa-luokkaan niin kantapää- kuin huuli-oliokin. Luokassa näille oliolle voi määritellä metodeita, eli olion piirteitä, esimerkiksi koira-olion toiminnallisuus voisi olla hännän heiluttaminen, syöminen, kepin noutaminen tahi emännän kiusaaminen. Metodit voivat olla arvon palauttavia tahi tietyin toiminnallisuuden suorittavia.
Näkyvyysmääreet olivat myös olennainen osa ensimmäisen esseen oppimistavoitteita. Luokalle voi siis asettaa erinäisiä näkyvyysmääreitä, joista yleisin on luokalle public, eli yleinen. Myös attribuuteille asetetaan näkyvyysmääreitä, yleisin niistä on luokan sisällä näkyvä private.
Kaiken oppimani ja wordiin suoltamani lisäksi oli vielä tarkoitus kääntää koko setti html-kielelle, ja erityisen viehättävää oli lukea ja sisäistää tämä asia ensimmäisen deadline-päivän iltana kello hieman yli viisi. Siinä opin kantapään kautta, että tämän kurssin tarkoitus on nujertaa ihminen, opettaa elämänkoulua karulla tavalla ja itkunkatkuisten hetkien jälkeen pakottaa opiskelija oivaltamaan, että joskus asiat todella kannattaa aloittaa ajoissa. Jos jotakin olen oppinut näiden esseetehtävien aikana, niin sen (nimim. kaksi viime tehtävää palautettu etuajassa!). Eli, elämänkoulu taisi sittenkin opettaa ihan nohevasti.
Näin tällä kertaa, on muuten hauska ymmärtää, että esseetehtävät tämän kurssin osalta ovat nyt ohi (joojoo, lukuunottamatta kaikenlaisia dokumentointeja ja projektijuttuja), eiköhän tässä ole jotakin oppinutkin. Ja lukiessani uudestaan aikaa sitten kirjoittamaani esseetä luokista ja olioista, hymy hiipii silmille oivalluksen lomassa – ymmärrän asioita (siis joskus ja jouluna, mutta silti! 
Ihmettelyn aiheena neljännellä käsitekartta/essee -kierroksella oli Swing. Nopea silmäys oppikirjaan paljasti, että kyseessä on työkalujen kirjasto, jonka avulla voidaan tehdä graafinen käyttöliittymä. Swing-työkalupakista ammennetaan aina tilanteeseen sopivia komponentteja, jotka ovat sidottu yhdeksi interaktiiviseksi kokonaisuudeksi. Ironia oli huipussaan, kun siirtelin Cmapin pallukoita ja seuloin tietoa Internetistä naama kiinni tietokoneen kuvaruudussa: näytöllähän se koko ajan oli, tuo Swingin perusolemus. Metsää ei nähnyt puilta.
Ensimmäisenä on aina alusta, jonka päälle aletaan rakentaa: laitetaan komponentteja toistensa sisään tai viereen. Näistä Swingin peruspalikoista sain onneksi helposti jonkinlaisen käsityksen, monet komponentit kun kuuluvat pävittäiseen käyttöliittymäannostukseen. Java-komponenttien väliset suhteet olivat vaikeampia hahmottaa hieman ristiriidassa olleiden lähteiden takia.
Kuten otsikkokin antaa ymmärtää, ulkonäöllä on väliä puhuttaessa graafisista käyttöliittymistä. Harmoniselta näyttävän komponenttikokonaisuuden luovat Javan omat stylistit eli virallisemmin asettelijat. Jokaisella on oma tyylinsä, ja ohjelmoija värvää aina asettelijan kustakin komponentista huolehtimaan.
Graafisen käyttöliittymän implementointi valottui sen jälkeen, kun oli sisäistänyt tapahtumapohjaisen ohjelmoinnin hienoudet. Käyttäjän käynnistäessä Java-ohjelman tämä vain alustetaan ensiksi. Se on kuitenkin koko ajan odottamassa käskyjä, ja kun käyttäjä aiheuttaa oikeanlaiset ärsykkeet (kuten vaikka hiiren liikuttaminen) vastaa ohjelma ennaltamäärätyin toimenpitein. Tapahtumia pyydystämään ja käsittelemään on olemassa tietenkin olioita.
Fiksulta vaikuttaa kaiken kaikkiaan, toisaalta – etenkin tapahtumapohjaisen ohjelmoinnin kohdalla – mieleen pulpahti kysymys: mitenkä muutenkaan? Voiko asiat tehdä toisinkin fiksusti? Tätä täytynee tutkia.
Muistan vielä oikein hyvin sen, kun ensimmäistä kertaa jotakin koodia kääntäessäni eteeni hyppäsi NullPointerException. Siinähän sitä sitten oltiin silmät ymmyrkäisinä ja sormi suussa ihmettelemässä mistä oikein oli kyse. Sitten NullPointereita tuli myöhemmin uusia ja taas uusia ja ne tuntuivat lähinnä vihollisilta, ilkeiltä kommenteilla, jotka kertovat, että koodissani on jotain vikaa. Lyhyellä koodaus urallani olin siis heti saanut aikaan vihollisia.
Kolmannen teoria tehtävän myötä pääsin tutustumaan poikkeuksiin sitten hieman tarkemmin. Kirjaa ja netti tutkiessani huomasin, että poikkeukset eivät olekaan ilkeitä veijareita, jotka ilmestyvät koodaajan kiusaksi vaan ne ovat oikeasti hyödyllisiä! Pakkohan se on myöntää, että on kätevää, että joku muu tarkistaa minun virheitäni ja ilmoittaa sitten niistä minulle. Poikkeukset ovat siis tärkeitä apuvälineitä, jos niitä osaa käyttää oikein ja oppii niitä ymmärtämään. Niiden avulla vältetään monia ongelmatilanteita ja jopa ohjelman kaatumista.
Samalla selvisi siis vielä jotakin java-kielestä. Joku on ehkä oikeasti miettinyt sitä, miten kieli olisi hyödyllisintä rakentaa, jotta se olisi käyttäjä ystävällinen. Eli ehkä jatkossa minun tulisi suhtautua koko java-kieleen kaverina tai apuvälineenä ennemmin kuin koodaajien työn vaikeuttajana.
NullPointereita tulee varmaan jatkossakin eteeni, ja onhan se sillä hetkellä hieman ärsyttävää, mutta ehkä osaan nyt myös arvostaa niitä hieman enemmän. Kone “ajattelee” minun parastani heittäessään poikkeuksia eteeni.
Sanonpa vielä muutaman sanan teoriatehtävän toteutuksestakin. Itse olen aina kokenut esseen kirjoittamisen melko mielekkääksi. Syy siihen on ehkä se, että se on tutuin muoto kirjoittaa jotakin. Kuitenkin on mielestäni mukava kokeilla uusia tapoja ja siksi olin innoissani käsitekarttojen tekemisestä. Ensimmäisellä kerralla en kuitenkaan oikein päässyt käsiksi siihen, millainen käsitekartan tulisi olla. Assareilta saadun palautteen jälkeen päätin, että kokeilisin karttaa uudelleen. Nyt koin saavani kartasta jo paljon enemmän irti, mutta en silti ehkä aivan kaikkea, mitä olisin voinut saada. Luulenpa, että karttojen teossakin oppii tekemällä, joten voi olla, että kokeilen sitä jatkossakin.
Mieliala on aika matalalla. Sain juuri kuulla Mariannelta, miten suuri vaikutus käsitekartoilla on arvosanaan. Käyttämäni aika ja vaiva ei taida vastata prosenttiosuutta. Käytin taas tehtävään satamiljoonaatuhatta tuntia. Koitin tsempata itselleni lauantaiaamun vapaaksi palauttamalla käsitekartan jo perjantai-iltana. Perjantai-ilta tosin vaihtui lauantaiaamuksi. Kaiken muun hyvän lisäksi huomasin kartassani virheitä ja typeryyksiä heti sen palautettuani. 
CmapTools on kyllä erittäin hyvä uusi ystävä. Se löi parhaimmankin kynä-paperi-KUMI -yhdistelmän aivan
laudalta. Ohjelman peruskäytön oppi hetkessä. Ainut ohjelman miinuspuoli oli se, etten onnistunut lisäämään sillä kuvia käsitekarttaani. Turvauduin PhotoShopin luotettavaan apuun.
Jokatapauksessa harjoituksen anti oli aivonystyröitä hyväilevä. Ahaa-elämyksiä siunautui taas monia säkillisiä. Mielestäni on käsittämätöntä, miten asiasta, josta ei tiedä mitään voi tajuta parin illan ja yhden yön jälkeen näin paljon. Perjantaiyön pikkutunteina pohdittiin Ollin kanssa rajapintoja ja abstrakteja luokkia ja näiden toteutuksia OLO-ryhmämme IRC-kanavalla. Kokoelmat ovat nyt ainakin teoriassa tuttuja. Käytäntöön tutustutaan taas ohjelmointiharjoituksissa. Primitiivityypit ja taulukot olivatkin jo entuudestaan hallussa.
Olen yhä erittäin innoissani kurssin tavasta lähestyä ohjelmointia. Jos kaikkea voisi opiskella näin, ei mikään olisi mahdotonta.
