You are currently browsing Marianne's articles.
Loppu hyvin, kaikki hyvin? Vähän yli syksynhän se venähti, mutta Studio1 on vihdoin enemmän tai vähemmän kunniakkaasti suoritettu. Täytyy kyllä sanoa, että tätä hetkeä olen hyvin hartaasti odottanut. Se oli fiiliskierros – sitten asiaan.
Kuten jotkut muutkin blogiryhmäläiseni ovat loppupuheenvuoroissaan virkkaneet, oli alkukurssin ”Java vasten kasvoja”-pläjäys ehkä turhankin mahtipontinen ja huikea osoitus siitä, että nyt ei enää todellakaan olla lukiomaailmassa, jossa tarjoillaan lähes kaikki tarjottimelta, vastaukset valmiina, jos vain tajuaa niihin tarttua. Johdanto Javaan olisi voinut olla tosiaan vähän laajempi ja kattavampi, toisaalta voi toki olla, että siinä alkutiimellyksessä ei monia javaluentoja olisi osannut niin arvostaa. Voisikohan, tai olisikohan järkevää, toteuttaa luentomeiningit siten, että alussa olisi tosiaan pari ”pehmeä lasku”-luentoa, sitten päästäisiin itse harkkoihin ja testailemaan, seuraako ymmärrys. Parin viikon päästä voisi olla hankalammista asioista muutama luento, jotta tehtävien edistymistä tuettaisiin mahdollisimman kivasti. Nyt itseopiskelun varaan tosiaan jäi paljon, mutta toisaalta akateemisessa maailmassahan tässä jo ollaan.
Toisaalta kun miettii, OLO-sessioissa käytiin paljon juuri harkoissa käsillä olevia asioita, joten niistäkin sai ammennettua tietoa, jos vain olisi tehokkaammin pystynyt keskusteluun osallistumaan ja näitä neuvoja hyödyntämään. Välillä sessioissa tuntui, ettei ollenkaan pysynyt teknisessä ja loogisessa ajattelussa mukana, ja koska näissäkin asioissa edettiin aika vauhtia, jäi olojen anti turhan laimeaksi. Ryhmähenkeä nostattavat ja samalla koettelevat tehtävät olivat botti sekä robotti, jotka toimisivat varmasti paremmin juuri Oulan jossakin blogipostauksessa ehdottamalla tavalla – niille olisi varattava enemmän aikaa tai vähemmän montaa yhtäaikaista lähestyvää deadlinea. Yksilösuoritus meni useilla, ja itsellänikin, liian usein ryhmätyön edelle, kun näitä oli arvotettava ja ajankäytön takia tehtäviä priorisoitava.
Esseet ja käsitekartat eli kässeet olivat paikka paikoin erityisenkin hyödyllisiä, mutta työmääräänsä nähden tosiaan liian vähäisesti arvosanaan vaikuttavia. Blogista jäi mieleen lähinnä ihana Svante, joka aina muisti patistella blogipostailun pariin olosessioiden jälkeen. Blogi on kehittelemisen arvoinen työ- ja oppimisympäristö, mutta vaatisi kunnolla kurssin aikana toimiakseen lisää ponnisteluja kurssilaisilta, sillä se oli kurssin aikana hyvin helposti unohdettavissa, kun raaka koodaus täytti elämän. Kaksi kertaa viikossa pidettävät koodausharkat ja assareiden vankka ja kärsivällinen tietotaito olivat oivia ja erittäin tarpeellisia apuja sille ankaralle elämälle, jota infolaiset syksyn ajan viettivät.
Tosiaan kurssin laajuus aiheuttaa samanmoisia kysymyksiä kuin Tiinankin loppupuheenvuorossa, missä menee raja järkevän kokonaisuuden hallintaan? Kuinka tärkeää on opetella Javan ohella myös se ”erittäin yksinkertainen” html:kin pintaraapaisun lailla, kun lähtökohtana kuitenkin oli, ettei erityisiä esitietovaatimuksia koodauksesta tai tietotekniikasta ollut. Asiaa tuli joka tuutista välillä niin kovalla paineella, että kaikkea ei millään ehtinyt käsitellä, ja esimerkiksi siksi saattoi html:n ja omien kotisivujen vääntäminen jäädä vähemmälle ja kun html-aika taas tuli, meni sormi suuhun ja itku kurkkuun. Eli, voi tietysti olla että kuulun vähemmistöön, mutta toivoisin tähän jotakin rotia, ei liikaa herneitä yhteen soppaan, jollei se ole aivan välttämätöntä ja perusteltua!
Itse ohjelmoinnista vielä sen verran, että vaikeaa se oli, mutta yksi syksyn parhaista ja ikimuistoisimmista hetkistä liittyy ikävä kyllä kuitenkin Javaan ja omaan projektiin. Maarilla koodatessa ja monen päivän rutistuksen jälkeen pelilogiikan vihdoin toimiessa pääsi jos jonkinmoisia ilonkiljahduksia, huudahduksia ja voitonriemuisia äännelmiä. Saa nähdä, kultaako aika muistot, ja lopulta näen Javan vain sinä ihanana onnistumisen hetkenä ja tunteena.
Rekursiivinen metodi tarkoittaa metodia, jonka sisältä kutsutaan toistamiseen metodia itseään. Perinteisillä tehtäväkierroksilla opimme rekursion käyttöä, mutta itselleni asia valkeni hehkeämmäksi vasta projektia koodatessa. Pelilogiikkani ongelma oli se, että tarvitsin metodia, joka tarkistaa ruudukon tietyn ruudun jokaisen naapurin, ja mikäli naapuri on samanlainen kuin alkuperäinen tietty ruutu, tarkistetaan kyseisenkin ruudun naapurit samanlaisia kuvioita etsien. Assistentti sekä viisas kurssitoverini ehdottivat kauan kammoksumaani sanaa – rekursio. Päätin ottaa aasia hännästä ja katsoa, mitä tapahtuu, kun minä ja rekursio katsomme toisiamme silmiin. Seuraavassa tekemäni metodin rekursio-idea hiukan lyhennettynä, mutta kuitenkin niin, että rekursio tullee selväksi.
public boolean loytyykoSamaNaapuri(int x, int y, Kuva kuva){
boolean loytyy1 = false;
boolean loytyy2 = false;
boolean loytyy3 = false;
boolean loytyy4 = false;
if(x – 1 >= 0){
if(this.ruudukko[x - 1][y] == kuva){
if(!this.koord.contains(new Point(x-1, y))){
this.koord.add(new Point(x-1, y)); loytyykoSamaNaapuri(x-1, y, kuva);
loytyy1 = true;
}
}
}
if(x + 1 < this.annaLeveys()){
if(this.ruudukko[x+1][y] == kuva){
if(!this.koord.contains(new Point(x+ 1, y))){
this.koord.add(new Point(x+1, y));
loytyykoSamaNaapuri(x+1, y, kuva);
loytyy2 = true;
}
}
}
if(y – 1 >= 0){
if(this.ruudukko[x][y - 1] == kuva){
if(!this.koord.contains(new Point(x, y-1)){
this.koord.add(new Point(x, y – 1));
loytyykoSamaNaapuri(x, y-1, kuva);
loytyy3 = true;
}
}
}
if(y + 1 < this.annaKorkeus()){
if(this.ruudukko[x][y + 1] == kuva){
if(!this.koord.contains(new Point(x, y+1))){
this.koord.add(new Point(x, y +1));
loytyykoSamaNaapuri(x, y+1, kuva);
loytyy4 = true;
}
}
}
Yllä siis tarkastellaan tietyn x,y-ruudun jokaista suuntaa, tutkitaan löytyykö vierestä sama kuva kuin kyseinen ruutu on. Mikäli sama kuva löytyy esimerkiksi ruudun vasemmalta puolelta, lisätään tämän ruudun koordinaatit this.koord-listaan ja tehdään rekursiivinen tutkimus näillä uusilla koordinaateilla, eli kutsutaan sama metodi tarkistamaan myös uuden koordinaatin viereiset ruudut. Tämän metodin kautta itselleni selvisi lopulta rekursion järkevyys, olin välillä jopa niin epätoivon partaalla, että meinasin toteuttaa kyseisen metodin vähintään niillä 25 if-lauseella, jotka olisivatkin olleet sitä ohjelmointityyliä tyylikkäimmillään.
Kuten yllä nähdään, ei rekursio lopulta ole kovin monimutkainen asia. Javalla sen toteuttaminen on suhteellisen helppoa, on vain oltava varovainen ja tarkka, että logiikka on rekursiossa oikein. Vaarana voi olla se, että rekursio jää ikuisesti toistamaan itseään, ja siksi esimerkiksi yllä on neljä boolean-apumuuttujaa, jotka määritellään ensin falseksi. Mikäli samoja kuvia löytyy vierestä ja rekursiota lähdetään pyörittämään, vaihtuu apumetodi trueksi. Omassa koodissani metodin suorittaminen loppuu silloin, kun kaikki apumuuttujat pysyvät falseina, eli mistään ei ole löytynyt kuvatun ruudun kanssa samantyylistä kuvaa. Näin siis varmistetaan, että metodin suorittaminen loppuu joskus.
Kurssilla on yleisesti opittu, jo ennen rekursiota, se, että yhden metodin A sisältä voidaan kutsua myös muita metodeja, ja käyttää näiden metodien palautusarvoa metodin A edetessä. Esimerkiksi kun metodi A kutsuu sisältään metodia B, metodi A jää odottamaan metodin B edesottamuksia, ja toiminta jatkuu vasta sitten, kun metodi B on valmis ja antanut tuomionsa. Rekursiivisessa metodissa tämä toimii samalla tavalla, on vain otettava huomioon, että samasta metodista voi lähteä useita sisäkkäisiä aktivaatioita eli kutsukertoja samanaikaisesti.
Rekursio on näppärä apu ja järkevä käyttää, kun halutaan siisti vaihtoehto esimerkiksi iteratiiviselle, toistoon perustuvalle silmukkaratkaisulle. Esimerkiksi projektini kyseiseen metodiin olen erittäin tyytyväinen, mielestäni sen logiikka pelaa ja ratkaisu on siisti. Kannatti siis tutustua lähemmin rekursioon, se ei ollutkaan pahin viholliseni.
Aika jännä, jos se siihen menee. Oman jouluisen projektini parissa hääriessä aloin pohtia ohjelmointityylin tärkeyttä. Itsekseni, vain omaa koodia tuijotellen en tätä olisi ehkä tullut ajatelleeksi, mutta kurssitovereiden vilkaistua koodinpätkiäni ja palautteen oltua ”öö, oliskohan tossa luupin paikka.. Miten sä oot tehnyt on tolleen, eikä tää ois parempi? Miksi sulla on noikin for-lauseen sisällä? Miten sun sisennykset on ihan miten sattuu?” – tyylistä, heräsi sisimmässäni palava tarve jakaa ajatusta kansalle.
Toinen aiheeseen innoittajani oli seuraava, elävän elämän esimerkki, projektiin koodaamani pätkä.
if(this.ruudukko[this.tykinX][0] == null
&& this.ruudukko[this.tykinX][1] == null
&& this.ruudukko[this.tykinX][2] == null
&& this.ruudukko[this.tykinX][3] == null
&& this.ruudukko[this.tykinX][4] == null
&& this.ruudukko[this.tykinX][5] == null
&& this.ruudukko[this.tykinX][6] == null
&& this.ruudukko[this.tykinX][7] == null
&& this.ruudukko[this.tykinX][8] == null){
this.ruudukko[this.tykinX][0] = this.ruudukko[this.tykinX][this.tykinY];
this.ruudukko[this.tykinX][this.tykinY] = null;
this.tykinY = 0;
}
Anam nam, eikö vain? Olisiko kenties luupin paikka? Tässä tilanteessa siis todella itsekin tajusin, ettei välttämättä näytä jokaisen mielestä kovin nätiltä, mutta jätin silti tai juuri siksi kyseisen kohdan projektini osaksi. Se oli niin viehättävä, että sillä alkoi olla tunnearvoa. Kyseisen if-lausetarkastelunhan olisi voinut nätisti toteuttaa myös for-lauseella, mutta lopulta, olisiko se kuitenkaan ollut kauniimpaa, kuin tuo harmoninen rivi lähes identtistä koodia? Tästä päästäänkin jännittävästi pohtimaan, onko edellä oleva koodi sitten varsinaisesti ”huonoa ohjelmointityyliä”, voiko aiheesta kiistellä, olemmeko lopulta niinkin raastavan asian kuin mielipidekysymys, äärellä?
Tosikoodari, joka tuntee jo Javan ja mahdollisesti monen muunkin ohjelmointikielen salat, on varmasti tottunut tekemään asiat omalla tyylillään ja tavallaan, yleensä mahdollisimman loogisesti, järkevästi ja selkeästi. 25 rivin if-lauseparatiisit yhden metodin sisällä ovat vain rapistunut muisto menneestä, eikä turhia attribuutteja, metodeja saati vääränlaisia sisennyksiä näy. Javan saralla maitohampainen ohjelmoija (esimerkiksi allekirjoittanut) ei taas aina voi ymmärtää, miksei if-lauseet olekaan niitä kivoimpia kavereita, miksi täytyisi tutustua johonkin, joka tuntuu monimutkaisemmalta, kun on vasta juuri ja juuri hahmottanut if- ja else-if – lauseiden jännän maailman. Maitohampainenkin koodari tiputtaa purukalustonsa jossain vaiheessa koulutusta ja huomaa ehkä, että aluksi hankalammilta tuntuvat ratkaisurakenteet ovat lopulta paljon yksinkertaisempia, kun niitä vaan rohkeasti uskaltaa kokeilla ja käyttää. (eli pitää vain uskaltaa uskaltaa)
Studio1-kurssin aikana minulle on opetettu, että hyvään ohjelmointityyliin kuuluu ennen kaikkea oikeanlaiset sisennykset, tarpeeksi lyhyet rivit (suositus 80 merkkiä), riittävä ja selkeä kommentointi. Kapinani keskeltä myönnän, että näissä taitaa olla kyllä vinhasti perää, kantapään kautta olen oppinut, että omasta koodistaankin ymmärtää vielä viikon tai tunnin päästä edes yhden metodin, jos sitä on näppärästi kommentoitu. Toisaalta on myös pyrittävä välttämään kommentti-ylilyöntejä, joku roti on oltava ja kommentit osattava sijoittaa niihin kohtiin, joissa ne ovat perusteltuja ja kaivattujakin. Lisäksi koodia lukee mieluummin, ja virheetkin löytyvät helpommin, jos rivit ovat riittävän lyhyitä, ja sisennykset on jäsennelty oikein (tai annettu eclipsen hoitaa). Myös liian pitkät metodit liittyvät omalla tavallaan hyvään tyyliin, jos metodi vain venyy ja paukkuu, on se hankalaselkoisempi, ja sinne livahtaa helpommin virheitä.
Ennen kaikkea tärkeintä olisi mielestäni tehdä koodistansa loogista ja rakenteesta perusteltua. Kun isot linjat on hallussa ja oma ohjelmointityyli kehittynyt, voi alkaa pohtia, onko vinkeämpää, näpytelläänkö
if(!enkoMinaTaastaanOsaa())
vai
if (enkoMinaTaaskaanOsaa() == false).
Nämä kysymykset listaisin ehkä mielipidekysymysten alle, joidenkin on helpompi hahmottaa itselleen alempaa mallia, ja oletan, että rautahammaskoodareiden mielestä se on aivan kammostuttava, sillä ylempi on ennen kaikkea lyhyempi, myös siistimmän näköinen. Tärkeintä on, että sama linja pysyy läpi koko oman tuotoksen.
Viimeiseksi voidaan vielä pohtia, mikä on tavoitteemme esimerkiksi tämän kurssin osalta. Onko tavoitteemme lopulta tuottaa siistiä, selkeää, hienoilla rakenteilla ja monimutkaisilla luokkakuvioilla varusteltua koodia mallikkain kommentein, vai olisiko kuitenkin tärkeintä aluksi keskittyä ohjelmoinnin ymmärtämiseen ylipäätään, ja luottaa siihen, että vaikka koodi vielä olisikin rumaa mutta toimivaa, on se silti selkään taputtamisen arvoinen asia – on saatu aikaan jotakin toimivaa, jota voi sitten kotona äidille näyttää ja mielihyvän vallassa katsoa, kun äiti ei osaisi edes näin rumaa saada aikaan. Tekemällä oppii ja ennen kaikkea niistä virheistään – ehkä minäkin joku päivä vielä syön kapinani ja myönnän, että yllä ollut koodiesimerkki on ruminta koskaan.
Mutta kuitenkaan lopulta ei ole hyvä tämä, jos mennään siihen, että tyyli ennen kaikkea.
“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! 
Moi kaikille.
Kolmas Olo-tapaus iski vasten kasvojamme kuin Apulannan muutkin lyriikat konsanaan. Jo ennen session alkua oli itselläni ollut olo, että puheenjohtajuus kolahtaa tällä kertaa minun nilkkaani, ja vaikka kuinka koetin katsella pöytää ja papereita, joku nimeltä mainitsematon Svante minut nosti esille ja ehdotti puhikseksi. Eihän siinä mitään, se on ihan luonnollista, olin vaan hetken jos toisenkin hiukan hämmentynyt tästä aiheesta, ja epäilin, ettei minulla puhiksena olisi niin paljon annettavaa tälle kerralle. No, yritettiin yhdessä ja homma saatiin toimimaan. Sihteerin hommia tällä kerralla hoiteli Moona, ja varsin mallikkaasti hoitikin. Okei. Ja sitten asiaan.
Aiheena oli täten tietorakenteet, hiukan takkuileva aihe kaikille ainakin näin aluksi (mutta toisaalta purku on varmasti sitten sitäkin antoisampi..), edellisen kerran leppoisa teevesileikittely sai jäädä unholaan, nyt oltiin vakavampien asioiden äärellä. Tietorakenne tarkoittaa siis tietojen esitysmuotoa, esimerkiksi taulukoita ja listoja. Tietorakenteiden avulla pyritään ohjelmoinnissa esittämään reaalimaailmaa mahdollisimman hyvin. Nämä hiukan monimutkaisemmat tiedon esitysmuodot, ovat tärkeitä juurikin siksi, ettei reaalimaailmakaan usein ole niin yksinkertainen kuin toivoisi tahi luulisi.
Oloilun tiimellyksessä tutustuimme pintaraapaisun omaisesti joukon (ja allekirjoittaneen isän nimi on siis Jouko, jos se jollekin jäi epäselväksi), listan, taulukon sekä sanakirjarakenteen ominaisuuksiin. Post-it -lapputuokiomme antia oli muun muassa se, että joukko on järjestyksetön, joukossa realisoituu ihmisen roolit (voi kuulua moneen joukkoon samaan aikaan), ja jokainen kuuluu yleensä aina johonkin joukkoon. Listarakenne toi mieliimme muun muassa simppeliyden, jono-efektin (josta oivana esimerkkinä baarijono!) ja sen, kuinka listassa ei ole tyhjää välissä (eli baarijonossa pysytään tiukasti kiinni edessä heiluvan hepun selkämyksessä, eikä etuilijoita suvaita! Ja jonon perään voi mennä seisomaan, tai jonon eteen jos maksaa paljon portsarille). Taulukkorakennetta hahmottelimme munakennoimaiseksi; kun pari kakkua on leiponut ja yhden krapulamunakkaan paistanut, voi munakennosta löytyä ns. tyhjiä arpoja eli lokeroita ilman munaa. Kuitenkin munakennon koko on aina rajattu (oli kanat vapaita tai muuten vaan iloisia). Näin siis taulukoissakin, se on määrittelyn jälkeen rajattu ja muuttumaton työväline, jonka “lokeroihin” voi sijoittaa haluamiaan arvoja.
Sanakirjarakenne oli ehkä kaikista hankalimmin hahmotettavissa, se hämmästytti ja kummastutti. Entisajan ei-niin-kehittyvän yhteiskunnan puhelinluettelo saapui pelastavaksi esimerkiksi, sen hahmotelman ja idean avulla pääsimme käsiksi myös tähän rakenteeseen. Sanakirjarakenteeseen alkioita lisätään aina pareittain, ensimmäinen alkio on avain ja toinen alkio varsinainen alkio. Tämän jälkeen arvot haetaan avainten perusteella, kuten puhelinluettelossa nimi on avain ja numero arvo. Nimen perusteella etsimme vaikka mielitiettymme numeron näppärästi luettelosta. Sanakirjarakenteesta jäikin oppimistavoitteeksi Oulalle ja Antille pohtia, voiko yhdellä sanakirjan avaimella olla useita arvoja? (eli voiko esimerkiksi perhe Teknisen isännällä, Teuvolla, olla puhelinluettelossa monta eri numeroa samassa luettelossa)
Varsinainen tehtävämme oli suunnitella tietorakenne Pala erilaisin olettamuksin. Lämmittelyleikkinä tutustuimme Carcassone-pelin sääntöihin. Hämmennyksen sekaisin tuntein mietin edelleen, olisiko tarkoitus kuitenkin ollut keksiä annetuista tehtävistä koodiesimerkkejä, vai vain miettiä (kuten päädyimme tekemään), mitä tietorakennetta kussakin kohdassa voisi hyödyntää. Vaan voimmehan tehdä niinkin, että pohdimme pari koodimuotoon puettua tietorakenne Palaa purkusessiossamme, jos niikseen tulee ja ryhmä halajaa.
Muita oppimistavoitteita jakelimme seuraavanlaisesti: Olli ja Sanna saivat pohdittavakseen probleeman siitä, miten joukko liitetään taulukkoon ja kuinka niitä voidaan käyttää sisäkkäin. Sofi ja Marianne suunnittelevat tietorakenne Pala:n vitoskohdan, jossa on määritelty maailmassa olevan yhdeksään osaan jaettuja paloja ja niin eespäin. Tietorakenne maailman ykköstehtävänantoa mietiskelevät päissään Suni sekä Svante ja kakkoskohtaa pähkäilevät Moona ja Tiina. Jutellaanpa irkissä vaikka tosta vielä ennen tiistaita, jotta kirjoitetaanko siitä valmiiksi koodia, vai kuinka sitä pitäisi miettiä. Huhu nääs tosiaan kertoo, että joissain toisissa hapokkaissa ryhmissä kirjoitetaan raakaa koodia, mutta mehän teemme niin kuin yhteisesti parhaalta tuntuu, tärkeintä on kuitenkin, että jotakuinkin sisäistäisimme tietorakenteiden toiminta- ja käyttöperiaatteita. Luulisin. Huutakoon minut suohon ken vastaan vänkää tai rakentavasti muuten kommentoi.
Kuten jo edellä mainitsin, tämä Olokerta tuntui ehkä hankalimmalta, uutta asiaa ja hahmotettavaa tuli jälleen, mutta mielestäni selvisimme yhdessä hyvässä hengessä ja kutakuinkin kunnialla loppuun asti, nyt vaan purussa tsempataan niin saadan paljon irti tietoa ja rakenteita! Ja rakenteita ja tietoa.
