Ohjelmoinnissa syntaksit ja esimerkiksi metodien nimien mistaminen on siis vain erittäin pieni osa kokonaisuutta, vaikka jotkut varmasti kuvittelevatkin ohelmoimisen olevan juuri ohjelmakoodin kirjoittamisen osaamista. Syksyn aikana oli hauska seurata kuinka tietokoneiden ja ohjelmoinnin karu logiikka kuritti välillä pahaa-aavistamattomia fukseja. Itse ”luonnonmenetelmällä” kasvaneena nörttinä ei aina muista kuinka erilainen rakennuspalikkoina ykkösiä ja nollia käyttävä looginen kokonaisuus oikeastaan onkaan. Ainoa mikä voi oikeastaan valmistaa koodin kurimukseen on ehkä matematiikka, sillä ohjelmointi on pohjimmiltaan erilaisten ongelmien ratkomista juuri matematiikan ja logiikan keinoin.

Mielenkiintoisa ohjelmoinnista tekee sen erittäin yksinkertainen säännöstö. Ohjelmoidessa voi periaatteessa vain tallentaa numeroita erilaisiin muuttujiin ja taulukoihin, viitata muisitissa olevaan tietoon ja suorittaa erilaisia tätä tietoa manipuolivia komentoja sarjassa ja erilaisissa loopeissa. Ohjelmoinnin onnistuessa näkee työnsä tulkoset, eli ajatustoimintansa tulokset puhtaana lopputuloksena ilman kehon fyysisiä rajoitteita. Ohjelmat tekevät juuri sitä mitä haluat niiden tekevän, tai sitten jotain aivan muuta. Karnaveneet taas eivät lopulta useinkaan vastaa alkuperäistä mielikuvaa. Lisäksi on kierolla tavalla kiehtovaa saada ratkoa erilaisia ongelmia mahdollisimman elegantilla tavalla. Vaikka kukaan ei näe tekeekö ohjelmasi 10 vai 1000 looppia jonkun ongelman ratkaisemiseksi, tulee täydellisestä ratkaisusta silti hyvä mieli. Tavoitelähtöisys tulisi mielestäni kuitenkin aina pitää mielesä. Joillain ihmisillä ohjelmoinnista tulee nimittäin itse tarkoitus ja he haluavat tehdä kaiken itse, vaikka vastaava tai parempikin ratkaisu olisikin jo olemassa.

Ohjelmoinnin logiikka on mielestäni samoilla linjoilla niinsanotun ”insinöörilogiikan” kanssa. Ja kuten insinöörimäisyyskin, ohjelmoinnin logiikka tarttuvaa. Siihen jää koukkuun.

Olen aina ollut hirveän laiska opiskelemaan mitään itselleni vähänkään tylsää tai vastenmielistä. Ohjelmointi lukeutuu molempiin kategorioihin. Siksi kurssilla olevat teoriatehtävät ovat olleet tuskallisia tehdä, vaikka niistä läpi selvisinkin. Itse ohjelmointi menee ihan hyvin, ja koen oppivani sitä nopeimmin kokeilemalla. Kurssikirjaa en ostanut, vaan lainasin kirjastosta, mutta se maksoi minulle 11 euroa, koska kaksi kertaa unohdin uusia lainan ja sainpa tilille hetkeksi lainauskiellonkin. :)

Itse asioista selvää ottaminen on raskasta ja aikaavievää. Varsinkin graafisiin käyttöliittymiin liittyvät asiat ovat tämän vuoksi olleet minulle raskaita. Sadat valmiit luokat ja niiden tuhannet metodit ja niistä sopivimpien etsiminen ja löytäminen ovat varmasti alkukynnyksen ylittymisen jälkeen käteviä käyttää, mutta minulle opettelun henkinen muuri on liian korkea ylitettäväksi - tai ainakin on ollut tähän asti.

Pidän vihjeiden perusteella tekemisestä, ja siksi olenkin aina nauttinut Studio1-kurssin ohjelmointiosan tehtäväkierroksista, joissa kerrotaan, missä järjestyksessä asiat kannattaa tehdä ja miltä niiden tulee näyttää. Jopa käytännön toteutukseen saa vähän apua, tai ainakin on kerrottu, mistä aiheeseen liittyvää teoriaa kannattaa opiskella. Varsinkin tänä vuonna vihjeet olivat tehtävänantojen välittömässä yhteydessä, mikä auttoi omaa keskittymistä ja opiskelua paljon. Minulle yhdessä tekeminen on aina ollut mieluisaa, mutta Studio1-kurssin suuresta yhteisöllisyydestä huolimatta ohjelmoimisesta on jäänyt vähän negatiivinen kuva "yksinäisen puuhasteluna". Ehkä siksikään ohjelmointi ei ole minun lempitekemistäni, etten usko koskaan haluavani tehdä tai suunnitella ohjelmia käytännön tasolla.

OLOsessioissa on hyvä idea, pienryhmäoppiminen ja asioiden pureskelu yhdessä, mutta sen toteutus on mielestäni itselleni sopimaton. Olisi hyvä, jos tilaisuudessa olisi puheenjohtajana asioista eniten tietävä, jolta olisi helppo kysyä mitä tahansa mieleen tulevaa ongelmaa. Tällä hetkellä OLOsessiot ovat ryhmäläisten yhteistä pohtimista asioista, joista assistentit jo valmiiksi tietävät erittäin paljon mutta ovat taka-alalla. Itselleni voisi sopia paremmin suorempi "tässä aihe, lähdetään purkamaan tällä tavalla" -lähestyminen kuin Post-it -laput, tussit ja seitsemän tuskaista askelta. Myös se, että tapaamisen puheenjohtajaksi joutuu joku tehtävään sopimaton tai sitä haluamaton henkilö, on mielestäni aivan turhaa. Jos tapaamisen perusideassa on mielestäni joku virhe, asioiden omaksuminen ja niistä keskusteleminen vaikeutuvat minulle henkilökohtaisesti aika paljon. Itselleni sopisi ehkä parhaiten, että asiat käytäisiin läpi yhdessä ja pienryhmätasolla mistä tahansa asiasta voisi herättää keskustelua, jos ei ymmärrä tai haluaa lisäselvitystä. Keskusteluun voisivat osallistua kaikki, mutta sitä johtaisivat assistentit käytännönläheisin esimerkein. Tähän suuntaan ollaan ymmärtääkseni oltu muutama viime vuosi siirtymässäkin.

Tentissä huomasin, että ensimmäisten kahden osan teoriat eivät olleet ollenkaan tarvittavalla tavalla hallussa, mutta se oli odotettavaakin laiskasta lukemisesta johtuen. Tämä kaikki heijastui myös ohjelmointitehtäviin, joissa kesti aina aikansa opiskella tulevaa teoriaa ennen kuin pääsi kunnolla vauhtiin. Tekemällä teoriatehtävät kunnolla olisi ehkä säästänyt joissain ohjelmointiharjoitusten asioissa, mutta oppinut ehkä paljon sellaistakin, jota ohjelmointiharjoituksissa ei suoranaisesti tarvinnut. Minulle hieman vastenmielisen aihepiirin asiat eivät motivoineet tarpeeksi opettelemaan kaikkia asioita kunnolla.

Itselleni siis ohjelmoinnin opiskeluun sopivat parhaiten yhdessä tekeminen ja avoin keskustelu asioista enemmän tietävien kanssa, sekä käytännön kokeileminen ja itse tekeminen. Asioiden opettelu ennakkoon oppikirjoista tai nettiartikkeleista ei välttämättä ole se omin juttu, vaikka se varmasti paljon olisi oppimista helpottanutkin.

-Henri

Koska uusien opiskelijoiden ensimmäinen syksy perinteisesti kuluu lähes kokonaisuudessaan tietokoneen äärellä ohjelmointia opetellessa, opetusajan maksimaalinen hyödyntäminen on mielestäni erittäin oleellinen asia. Olin itse Studio1-kurssilla ensimmäistä kertaa jo kaksi vuotta sitten. Kurssi on mielestäni muuttunut aika paljonkin silloisesta. Me emme tehneet ollenkaan tenttiä, blogin paikalla oli jokaisen henkilökohtainen portfolio, ohjelmointitehtäviä oli nykyisen kuuden sijasta viisi, bottiturnausta ei ollut, kumpaakaan turnausta ei arvosteltu, OLOsessioiden opetuksen taso oli heikompaa ja ainakaan muistaakseni projektityölle ei oltu varattu ohjattua opetusta joululoman aikana.

Lähes kaikki uudistukset ovat mielestäni parannuksia menneeseen, mutta käytännön pikkuasioita voisi viilata. Jos ohjelmointitehtävien keskiarvo on melkein neljä, mutta tentistä jaetaan sääliykkösiä, pitää mielestäni miettiä. Ovatko vaatimukset linjassa ohjelmointitehtävien vaatimusten kanssa, vai onko ohjelmointitehtäviä tehty yhteistyössä niiden muutamien asiat oikeasti parhaiten hallinneiden kanssa? Jos ohjelmointi- ja teoriatehtävien keskiarvot kohoavat lähelle nelosta, mutta tenteissä on havaittavissa selkeä kahtiajako osaajiin ja osaamattomiin, on joku pielessä.

Mielestäni tentin osuutta kurssin arvostelusta kannattaisi nostaa korkeammaksi, ja vaikeammin arvosteltavissa olevien asioiden, kuten näiden blogikirjoitusten sekä robo- ja bottiturnauksen arvostelun osuutta pienentää tai poistaa kokonaan. Tentin arvosanan tulisi mielestäni olla suoremmin linjassa koko kurssin arvosanan kanssa, koska samaa menetelmää käytetään muutenkin yleisesti koulumme kursseilla. Toisaalta ennen kurssia arvottujen ryhmien töiden oikeudenmukainen arvosteleminen on ongelmallista, koska riittää, että ryhmässä on yksi ohjelmointimestari, joka tekee tehtävän valmiiksi ja muut hoitavat dokumentointiosuuden. Jos ryhmään ei ohjelmointimestaria satu, on se huonompi juttu.

Kun mietin, kumpi oli parempi idea, tehdä portfolio vai kirjoittaa yhteistä blogia, en päässyt selvään lopputulokseen. Portfoliota tehdessä kenenkään ei tarvitsisi vaivata päätään sillä, miten muiden ryhmäläisten panos vaikuttaa omaan kurssiarvosanaan, mutta toisaalta olen ymmärtänyt, että ohjelmointi suuremmassa mittakaavassa yleensä on ryhmätyötä, jossa ryhmällä on yhteisiä tavoitteita ja vastuita. Toisaalta portfoliota tehdessä saa harjoitusta html:n käytöstä, saa itse päättää, minkälainen toteutuksesta tulee ja pääsee ehkä enemmän toteuttamaan itseään muuten kuin verbaalisesti. Blogissa on helppo seurata, minkälaisissa tunnelmissa muut ryhmäläiset kurssia suorittavat, ja kertoa omia mielipiteitään muille. Yhteisessä vastuussa on taas arvosteluongelmansa, vaikka blogi arvioidaan osaksi henkilökohtaisestikin. Tässä ryhmädynamiikkaa testataan toki eri tavalla kuin robo- ja bottiturnauksissa, sillä ei riitä, että yksi kirjoittajamestari hoitaa homman, kun muut katselevat vieressä, vaan ainakin melkein koko ryhmän panosta tarvitaan blogin onnistumiseen. Tämän vuoksi blogi sopii ryhmässä arvosteltavaksi kokonaisuudeksi mielestäni huomattavasti robo- ja bottiturnausta paremmin.

Ohjelmointitehtävien lisääminen yhdellä ei uskoakseni vaikuttanut kovin oleellisesti kurssin kokonaistyöläyteen, mutta graafisten käyttöliittymien osuuden lisääminen yhdestä viidesosasta yhteen kolmasosaan kurssin ohjelmointitehtävien sisällöstä on mielestäni huippu-uudistus! Vieläkin koen itselleni henkiseksi esteeksi graafisten käyttöliittymien tekemisen, sillä hyppäys valmiiden luokkien hyödyntämisen maailmaan tuntuu liian suurelta.

OLOsessiot, nuo ainaiset henkilökohtaiset riippakiveni, ovat minun nähdäkseni edelleen kurssin "löysin" osa. Jos nuo kymmenisen kaksoistuntia vaihdettaisiin vaikka yhdessä ohjelmoimiseksi niin, että edelleen pienryhmissä yksi assari kerrallaan tekisi konkreettisia mallitehtäviä yhdessä ryhmän kanssa, luulen, että saavutettava hyöty olisi moninkertainen verrattuna nykyiseen. Saataisiin kaksinkertainen määrä opetusta ja konkreettisia esimerkkejä siitä, miten kannattaa tehdä ja miten ei, kun nykyään sessioissa istutaan tuppisuina ja kirjoitellaan post-it -lapuille mielestäni aivan turhanpäiväisiä asioita, kun konkreettinen oppiminen jää todella vähäiseksi.

Kokonaisuudessaan kurssi on mainio paketti, ja varsinkin ohjelmointitehtävät ovat erittäin mielenkiintoisia. Edellä pohdiskelemillani asioilla voisi ehkä viilata toimivamman ja tehokkaamman ratkaisun, mutta varmasti käytännön muutoksia tarvitsisi miettiä tarkkaan ennen toteuttamista.

-Henri

Jos kaikki olisi määritelty oletuksella, niin luokan jälkeläisissä ja sen kanssa samassa paukkauksessa olivissa luokissa voisi muuttaa esimerkiksi jonkin tärkeän vakion arvoa. Esimerkiksi piin arvoa ei voisi muuttaa, koska se on määritelty final-määreellä, mutta jos käyttää jotain tärkeää arvoa, joka voi kuitenkin muuttua, mutta vain jos ohjelmoija niin haluaa tai vain tämän tietyn luokan toiminnot niin päättävät. Tässä tilanteessa, kuitenkin, joku saattaa luoda tälle tärkeän muuttujan sisältämälle luokalle aliluokan ja muuttaa siellä tämän muuttujan arvoa. Tai jokin samaan luokkapakkaukseen kuuluva saattaa muuttaa tätä arvoa, vahingossa tai tarkoituksella. Tämän takia private-määre on tarpeellinen.

Toinen tapaus taas on se, ettei jokin luokka ole samassa pakkauksessa kuin jokin tärkeä tai monimutkainen metodi, eikä tätä luokkaa voi laittaa myöskään perimään tätä metodin sisältävää luokkaa. Tällöin taas tarvitaan public-määrettä.

Samoista syistä kaikki muuttujat eivät voisi olla tyypiltään vain privatea – miten silloin voitaisiin kutsua muissa luokissa olevia metodeja? – eikä myöskään vain publicia – miten tällöin suojataan esimerkiksi suojausta tarvitsevat attribuutit?

Protected-määrettä voidaan näin ollen käyttää kun muuttuja tarvitsee suojaa muita paitsi jälkiläisiään vastaan.

Kaikista eri näkyvyysmääreistä on siis hyötyä.

Parhaimmaksi oppimateriaaliksi on osoittautunut määrätietoinen Googlettaminen ja Java-APIn lukeminen. Lähes kurssin alusta lähtien minulla on aina koodateesani ollut vierekkäin koodi ja nettiselain joko eri näytöillä tai jaetulla ruudulla. Luen ohjetta ja tai googlettamaani esimerkkiä ja krijoitan samalla omaa koodiani. Firefoxin Java-API-hakukone-liitännäinen on osoittautunut korvaamattomaksi työkaluksi. Olen huomannut että itseasiassa opin kaikkein tehokkaimmin lukemalla valmista koodia ja esimerkkejä.

Syksyn alussa yritin opiskella asioita kirjasta lukemalla, mutta pian totesin ettei se ollut lainkaan tehokasta. Loppujen lopuksi Kalakirja on nyt useamman kuukauden päässyt pölyttymään hyllyssä. Hakuteoksena Google ja sen löytämät miljoonat sivut vain ovat huomattavasti näppärämpiä.

Haluan päästä heti kokeilemaan opettelemiani asioita, ja esimerkiksi ohjelmointiprojektin aikana syntyi iso kansiollinen testiluokkia. Jokaista uutta asiaa piti päästä heti testaamaan ja soveltamaan itse. Kommentoin runsaasti koodin sekaan ja kirjoitan itselleni auki mitä missäkin kohdassa tehdään, jolloin opin sen samalla. Testaan koodia hyvin tiheästi, jolloin virheet ja bugit huomaa nopeasti ja pystyy reagoimaan niihin. Pidän myös kirjaa siitä mitä on tekemättä ja mitä pitäisi parantaa, jolloin pystyn helposti palaamaan niihin kohtiin ja etsimään tietoa ratkaistakseni kohdat.

Voisihan sitä ajatella, että kun se on kerran kirjoitettu, niin ei sillä sitten ole enää mitään väliä, että onko esimerkiksi aloita alusta -kuuntelija nyt tämän parin tuhannen rivin koodin alku vai loppu puolella. Mutta mitä sitten tehdään kun ohjelma ei toimikaan; lähdetään selaamaan pari riviä kerrallaan koko koodia läpi vai? Tässä on yksi syy metodien käyttöön.

Toinen hyvä syy käyttää metodeja on toiston väheneminen. Entä jos ohjelmassa on vaikka tuollainen edellä mainittu aloita alusta -toiminto tai vielä parempaa: aloita uusi

-toiminto? Kirjoitetaanko silloin tuon kuuntelijan sisälle kaikki se, mitä uuden ohjelman aloittamisessa tarvitaan – uudestaan? Sillä luultavasti ohjelman aloittaminen täytyy koodata tapahtumaan muutoinkin kuin uuden ohjelman aloittamiseen tarkoitettua nappia painamalla. Tai voisi tuota nappia tässä tapauksessa ehkä vaatia painamaan, mutta kaikissa ohjelmissa tämä ei onnistu ja toistoa tulee varmasti.

Kolmas hyvä syy käyttää metodeja on se, että niitä voi käyttää erikseen luokan ulkopuolelta. Toisaalta, jos tekee vain yhden luokan, niin eihän näitä metodeja tultaisi käyttämään sen ulkopuolelta, mutta koska päädyimme jo siihen, että se oli hyvin epäselvää ja bugien ja muiden virheiden korjaamiseen ja ymmärtämiseen menisi luultavasti hirvittävästi aikaa, niin oletetaan, että luokkia olisi monta, metodeja jokaisessa se yksi. Luokkia olisi silloin vaikea lukea samalla, joutuisi kokoajan vaihtamaan ikkunaa. Lisäksi pitäisi aina luoda uusi luokka, määritellä se ja sitten tehdä vielä kuitenkin se metodi. Mieluummin siis toisin päin: yksi luokka, monta metodia.

Selkeintä ja toistoa vähentävintä olisi kuitenkin käyttää tarvittavan montaa luokkaa, jotka voi laittaa perimään eri muita luokkia ja tehdä niihin useampia metodeja, jotka käsittelisivät kukin yhtä asiaa, löytyisivät helposti, ja joita voitaisiin kutsua näistä toisista luokista sekä vain silloin, kun se on tarpeellista.

Etuja logiikan ja käyttöliittymän eriyttämisestä on useita. Ohjelmalogiikalle voidaan vaikka tehdä useita erilaisia käyttöliittymiä, jolloin samaan tietoon ja ominaisuuksiin pääsee käsiksi monella eri tavalla. Käyttöliittymissä on myös usein monia järjestelmäspesifejä asioita, jolloin eriyttäminen helpottaa erilaisen käyttöliittymien kehittämistä eri järjestelmille. Logiikan toteuttamisessa ei tällöin tarvitse välittää näistä järjestelmäkohtaisista asioista.

Kun ohjelman logiikka toteutetaan erillään käyttöliittymästä, niin myös ohjelman kehittämistä voidaan tehdä huomattavasti joustavammin.  Kun sovitaan tarkasti miten ohjelman eri osat kommunikoivat keskenään, niin ohjelmaa voi olla vaikka kehittämässä useita henkilöitä samanaikaisesti. Ohjelmaa myöskään harvoin suunnitellaan kerralla valmiiksi, jolloin mahdollisuus kehittää eri osia erikseen helpottaa huomattavasti ohjelman jatkokehitystä.

Varjopuolena logiikan ja käyttöliittymän erottamisessa on joissain tilanteissa ohjelman rakenteen turha hajoaminen, kun toisiinsa liittyviä asioita toteutetaan erillään. Lisäksi logiikan ja käyttöliittymän eriyttäminen johtaa väistämättä siihen, että eri luokkien välillä täytyy siirtää entistä enemmän tietoa. Käyttöliittymän täytyy välittää kaikki asiaan liittyvät parametrit mallille, ja joissain tilanteissa niitä saattaa olla aikamoinen määrä. Vaarana on myös epäkonsistentti tila logiikan ja käyttöliittymän välillä, jos tieto ei ole vaihtunut niiden välillä niin kuin pitäisi.

Tässä vaiheessa minulle oli vielä täysin hämäränpeitossa, mitä pääohjelmametodin String[] args oikein tarkoittaa. Olin aina vain kirjoittanut sen sulkujen sisälle kiltisti vailla sen kummempaa ymmärrystä sen tarkoitusperistä. Neljännessä Javatehtävässä vihdoinkin käsiteltiin sitä. Kyse onkin komentoriviparametrista. Omassa ohjelmassamme komentoriviparametreiksi määritettiin nimi ja nopeus. Käynnistettäessä ohjelma kysyi näitä määritettyjä arvoja ja tallensi ne muistiin. Näin ohjelman käyttäjä sai määritellä aluksi oman nimensä ajaessaan ohjelmaa.

Main-metodi on kuitenkin poikkeustapaus. Kurssin edetessä oppia kertyi ja metodien parametritkin tulivat tutummaksi ja tutummaksi.  Ne muodostuivat itsestäänselvyyksiksi. Suuri askel oli kun osasi itse määrittää metodille tilanteeseen sopivat parametrit. Varsinkin lopputehtävissä tuli pelailtua konstruktorien parametrien kanssa, kun monen luokan piti tuntea moni muu luokka ja parametrejä kertyi lukuisia tehtävän edetessä.

Parametreilla voi siis vaikuttaa metodin palautusarvoon. Kuvitellaan, että metodi ottaa parametrinaan boolean-muuttujan ja metodin sisällä määritellään erilaiset palautusarvot sekä true-arvolle, että false-arvolle. Nyt metodi palauttaa arvon, joka riippuu annetun parametrin totuusarvosta. Tässä tulee juuri ilmi parametrien eli argumenttien hyödyllisuus - ei tarvitse tehdä jokaiselle tilanteelle omaa metodiansa.

-Olli

Ensimmäinen harjoitus sujui vielä hyvin tietämättömänä mitään itse koodauksesta tai siitä, mihin kaikkeen sitä voi hyödyntää. Yhteys Java-peleihin oli erittäin häilyvänä mielessä. Jotenkin Java ei ohjelmointikielenä, tai ylipäänsä ohjelmointi, sanonut minulle mitään! Mielestäni oli kummallista kirjoittaa kymmenen riviä tekstiä, jotta saisi tulostettua tekstin "Hello World!" Miksei saman tien vain kirjoittaisi kyseistä lausetta?

En lähtenyt tähän hommaan riittävän hyvällä asenteella. En ajatellut ohjelmointia mitenkään helppona hommana, mutten toisaalta sellaisenakaan, mitä haluaisin tai ylipäänsä voisin vielä joskus osata. Kurssin alkuvaiheessa näin pari kurssilla toteutettua projektia, nämä olivat pelejä, enkä ikimaailmassa osannut kuvitellakaan itse tekeväni mitään senkaltaistakaan. Tuossa vaiheessa opetteluni oli lähinnä ohjeen sokeana seuraamista ja assareilta saamien neuvojen mukaan koodin kirjoittamista. Eli sisäistetty asia jäi ehkä kymmeneen prosenttiin tavoitteesta. Jotenkin suljin Javan kokonaan pois kaiken muun tieltä. En ymmärtänyt, miksi jotain tällaista pitää opetella.

Koodaus alkoi synkän harmaalla Emacs-editorilla. En koskaan oppinut käyttämään kaikkia sen ominaisuuksia, sillä hajosin jo copy-pasten aiheuttamaan jumitustilaan. Eclipse helpotti elämääni sekä fyysisesti että henkisesti. Jotkut tuntevat nostalgiaa nyt myöhemmässä vaiheessa käyttäessään Emacsia. Jotenkin en itse koskaan oikein ihastunut Emacsin käyttöön. Eclipsen avulla opin paljon lisää ja paljon hyödyllistä, muunmuassa parametreista ja valmiiden luokkien tarjonnasta. Aloin oikeasti, ehkä jollain tuntemattomalla tasolla, välillä jopa pitämään koodaamisesta.

Vihdoin, kaikista kolmesta ensimmäisestä tehtävästä selvinneenä, neljäs tehtävä toi mukanaan jo jotain ihan konkreettista näkuviin ikuisen puurtamisen jälkeen. Pääsi jo seuraamaan omaa tuotostaan ja pelaamaan "itse tehtyä" peliä. Sikobanin myötä pääsin luomaan oman graafisen käyttöliittymän. Mielenkiinto lisääntyi koko ajan, kun halusi saada lisää toiminnallisuutta, vielä enemmän juttuja näkyviin!

Omaa aikaa ei ollut käytettävissä koodille, eikä se alkuvaiheessa vielä haitannutkaan. Kuitenkin algoritmit olivat monimutkaisia jo alkuvaiheessa ja näin tuntuivat hyvin hyvin hankalilta vielä myöhemminkin. Jälkeenpäin harmittaa kuinka paljon enemmän olisin voinut alkuvaiheessa perusasioista opetella, ja kuinka paljon enemmän nyt osaisin, kuinka hienon projektin olisinkaan voinut saada aikaiseksi.

Projektin voisin sanoa muuttaneen käsitystäni ohjelmoinnista varmasti eniten. Kun ei ollut käytettävissä assareita, joiden hihasta olisi voinut nykäistä epävarmassa tilanteessa, oli vain pakko uskaltaa kokeilla! Omat ratkaisut eivät aluksi tuottaneet onnistunutta lopputulosta läheskään aina, mutta pienetkin onnistumiset kohottivat itsetuntoa ja auttoivat eteenpäin! Projektiini olen lopulta tyytyväinen . Opin yhteensä varmasti enemmän kuin koko kurssin aikana. Opin itse perehtymään virheisiini ja niiden aiheuttajiin sekä ratkaisuihin. Nyt tiesin jo hieman etukäteen jotain siitä, mitä tulee tapahtumaan ohjelmaa ajettaessa. Projektissani käytin tietenkin tuttuja (Javan valmiita)luokkia ja looppeja. For-lauseesta tuli suosikkini ja ArrayList oli esiintynyt jo niin monta kertaa, että ne olivat selvät valinnat, kun mietin eri silmukka- ja kokoelmavaihtoehtoja.

Nyt kun sain projektinikin tehtyä ja sen myötä huomattua, kuinka paljon loppujen lopuksi itseasiassa osaa koodata, (paljon olisi tietysti opeteltavissa vielä, jos haluaisi) on käsitys koko kurssia kohtaan hieman muuttunut. Projektin aikana koodin kirjoittaminen ei tuntunut hirvittävän ylivoimaiselta paria poikkeusta lukuunottamatta. Luulenpa, että asiaan vaikutti eniten juuri se näkyvän tuloksen aikaansaaminen. Helpompi ajatella, keksiä uusia ideoita ja korjata virheitä, kun lopputulos on nähtävissä. Itseluottamus oli myös kova tekijä tässä, oli paljon mukavampi tehdä jotain, kun tiesi, että siinä voi myös onnistua!

Kyllä näin lopuksi on pakko sanoa, että on se kivaa kun sen osaa :). Kaverit ja sukulaiset ovat innoissaan pienistäkin ohjelmista, mitä on saanut aikaiseksi. Monta tilausta olen saanut koodattavaksi, mutta katsotaan nyt, avaanko Eclipseä enää tänä vuonna, niin mukava kaveri kun siitä onkaan tullut.

-Meri

Kurssin aikana tuli käytettyä monenlaisia ohjelmia. Aivan uutta olivat koodieditorit, tai jos nyt vähän hienostuneemmasta ohjelmasta puhutaan, kehitysympäristöt. Ensimmäiset ohjelmointitehtävät tuli paahdettua läpi Xemacsia käyttäen. Xemacs tuntui todella näppärältä ohjelmalta, se pystyi jopa korostamaan tekstiä tuoden suuren avun koodausarkeen.

Liikkui kuitenkin huhuja vielä hurjemmasta sovelluksesta. Eclipse pystyisi näyttämään suoraan virheitä reaaliaikaisesti kääntävällä virtuaalikoneella. Se sisältäisi myös sisäänrakennetun API-hakemiston, jolloin varsinaista Sunin API-sivustoa ei tarvitsisi aivan jatkuvalla syötöllä selailla.

Kokeillessani Eclipseä ensimmäisen kerran olin jonkun verran epäluuloinen: se tuntui vähän monimutkaiselta kaikkine pikkuikkunoineen ja pikanäppäimineen. Epäluulot haihtuivat kuitenkin nopeasti: Eclipse nopeutti ja helpotti koodausurakkaa suuresti. Ei tarvinnut enää leikkiä komentorivin kanssa vaan Eclipse laittoi classit huutamaan hoosiannaa yhdellä hiirenklikkauksella.

Projektin jälkeen Eclipsestä oli tullut jo niin kiinteä osa koodausprosessia, että ihan helpolla en sitä vaihtaisi takaisin XEmacsiin. Toisaalta saattoi olla ihan hyvä asia, että ensimmäiset Java-kotitehtävät tuli tehtyä Xemacsilla. Se pakotti miettimään todella oikeaoppista Java-syntaksia - näin ainakin assareiden mielestä.

Sun Microsystemsillä on myös oma vastineensa Eclipselle: NetIde Javabeans. Tätä ohjelmaa ei tullut koskaan käytettyä (ei ollut varmaan tarpeenkaan).

Käsitekarttojen teossa tuli tutustuttua myös uuteen ohjelmaan – CmapToolsiin. Se oli kaikenkaikkiaan positiivinen yllätys. Käyttöliittymä oli yksinkertainen ja ohjelma teki nättiä, antialiasoitua jälkeä. Tutustuimme myös dialogikarttaohjelmaan, joka jäi vaisuksi tähdenlennoksi Sitä käytettiin ainoastaan yhdessä OLO-sessiossa.

Käytin myös omia grafiikkaohjelmia blogikirjoituksissa ja teoriatehtävien viimeistelyssä. Parhaan lopputuloksen sai usean eri ohjelman parhaita puolia hyödyntämällä.

Syksyn aikana tuli vietettyä (liian) paljon aikaa tietokoneen ääressä. Myös IRC:n käyttö juurtui selkäytimeen. En nyt tiedä onko se kovin hyvä asia...  Laadukkaat ohjelmat auttoivat huomattavasti syksyn urakkaa. Eclipse saa nyt kuitenkin levähtää jossakin syvällä kiintolevyn uumenissa – ainakin hetken.

- Teemu

Perinnän tarkoituksesta selvisi minulle eniten viidennessä Java-tehtänässä, jossa luotiin Sikoban luokka, joka siis peri JFramen ja sai näin käyttöönsä kaikki JFramen ominaisuudet ja metodit. Koin elämyksen kun joku assareista harjoituksen aikana neuvoi käyttämään this-sanaa JFramen metodeja kutsuttaessa. Ensin näitä päästiin tietysti etsimään JavaAPIsta ja "How to use" -kohta oli äärettömän valaiseva. Tässä vaiheessa tajusin, että tämähän itseasiassa tarkoittaakin sitä, että Sikoban-luokka on JFrame ja olisi sama kuin jos Sikoban-luokka pitäisi sisällään kaikki JFramen metodit. Ja taas tunnelmia: oli vain mahtava fiilis kun ikkuna aukeutui näytölle, ja tällä kertaa ihan itse aiheutettuna!

Jos minun nyt pitäisi selittää tärkeimmät asiat perinnästä, sen hyödyt ja käyttötarkoitukset sun muut siitä mitään tietämättömälle puhuisin varmasti ja luottavaisesti, en epäröisi asiassani. Aloittaisin kertomaan luokista ja niiden aliluokista, jotka "periytetään" näistä yliluokista, ja siitä kuinka aliluokat saavat yliluokkiensa ominaisuudet. Luokalla voi siis olla vain yksi yliluokka, kuten ihmiselläkin vain yksi äiti (isää ei nyt saa ottaa mukaan), mutta monta aliluokkaa, kuten äidillä lapsia. Koetilanteessa joutuisin kuitenkin miettimään sana- ja lausevalintojani, niin selvää perintä kokonaisuudessaan ei minulle vielä ole.

Selittäisin varmasti eläimistä, kissoista ja koirista, ja näiden ilmentymistä eli Mirristä ja Turresta. Luodaan siis luokat Eläin, Kissa ja Koira. Luokat Kissa ja Koira laitetaan perimään luokka Eläin. Eläin-luokan ilmentymät saavat luomisvaiheessa nimen ja painon. Näin on täten myös Kissa ja Koira -luokkien kohdalla. Näille voi kuitenkin antaa nyt jotain uusia ominaisuuksia ja määritellä metodeja, jotka tekevät näiden kahden ilmentymistä eläintä tarkempia ja toisistaan eroavaisia. Koira-luokan ilmentymät voisivat nyt nimen ja painon lisäksi saada ominaisuuden "uskollisuus" ja metodin "hauku". Kissat taas omiaisuuden "hännän pituus" ja metodin "kehrää". (Tämähän alkaa kuulostaa jo ensimmäisissä OLO-sessioissa käydyltä keskustelulta tai lähinnä assarin selitykseltä suu auki ja silmät pyöreinä katsoville phukseille).

Mielesstäni perinnän suurin hyöty tulee esille siinä, kun halutaan pitää samantyyliset, mutta kuitenkin erilliset asiat/ilmentymät/jotainihanmuuta(?) erillään, mutta silti kytkettyinä toisiinsa. Luokkien kokoa voidaan pienentää, kun jokaiseen ei tarvitse erikseen kirjoittaa samoja ominaisuuksia ja metodeja. Samalla hahmottuu kokonaisuus paremmin, kun nähdään, mitkä luokista kuuluvat yhteen. Peli-ikkunaakaan luodessani minun ei tarvitse kirjoittaa luokan sisälle viittäkymmentä metodia, erikseen koon asettamiselle, värin vaihdolle jne. vaan voin käyttää valmiita JFramen metodeja tähän.

Kurssin aikana olen oppinut paljon, ja niinkin yksinkertainen asia kuin tämä perintä oli käsitteenä ja kaikkine ominaisuuksineen suhteellisen vajaa. Näkyvyysmääreen protected tarkoitus selvisi minulle käytännössä koodatessa, ja osoittautuikin varsin näppäräksi ratkaisuksi. Toisaalta käytännössäkään en sisäistänyt super.:n käyttöä tai lähinnä sen eroa this.:seen. This:iä käytetään kun kutsutaan jotain luokan metodia ja superia kun kyseessä on yliluokan metodi. Kuitenkin yliluokankin metodeja voi käyttää suoraan this. Tämä hämmensi täysin.

Projektissakin, nyt innostuneena tästä perinnästä loin ensin uokalle Esine viisi alaluokkaa, ja nämä toteuttamaan samat metodit. Sittemmin muutin luokan Esine abstraktiksi ja ylikirjoitin sen metodit jokaisessa sen aliluokassa. Huomasin kuitenkin kaikkien luokkien olevan niin identtisiä, että viisi luokkaa yhden enumeraation sijaan olisi ehkä sittenkin aika huono vaihtoehto. Muuten en perintää sitten hyödyntänytkään "omilla" luokilla. Sen sijaan periytin luokkia Javan valmiista luokista kuten JFrame, JPanel ja Thread.

-Meri

Studio1:n periaatteena on: jos et osaa, opettele ja jos et tiedä, hanki tietoa. Kukaan ei tarjoa luentoa aiheesta "miten saada aikaan eeppinen taistelu" eikä edes aiheesta "miten listaan tallennetaan tietoa, ja mihin sitä voi hyödyntää". Alussa tiedon haaliminenkin oli varsin hankalaa, kun kyse oli aiheesta, josta minulla ei tosiaan ollut mitään käsitystä. Tuntui, ettei kirjaa voi lukea, kun en tiedä mistä siinä puhutaan ja toisaalta tuntui, ettei koodia voi kirjoittaa, kun ei ole lukenut kirjaa.

Vaikeinta aluksi olikin oppia ymmärtämään, mitä ohjelmointi on. Olisin kaivannut jonkinlaista alkuinfoa, jossa olisi kerrottu, että on olemassa erilaisia valmiiksi luotuja ohjelmointikieliä, joita tarvitsee vain hyödyntää, ja että java, tämän kurssin aihe, on yksi tällainen kieli muiden joukossa. Sen jälkeen olisi voitu esittää, miten jokin helppo asia toimii eri koodikielillä kirjoitettuna. Näiden opasteiden jälkeen olisin ollut paremmin valmis vastaanottamaan tietoa return-käskyistä ja konstruktoreista. Nyt kurssin alku meni itseltäni hieman ohi, kun en todellisuudessa ymmärtänyt, mitä minun haluttiin oppivan.

Ymmärrettyäni kielikysymyksen vastassa oli edelleen tiedon hankkimisen vaikeus. API vaikutti melko hämärältä miljoonine luokkineen, ja kaikki englanninkieliset tutoriaalitkin  kannustivat lähinnä vain koodinpätkien kopioimiseen. Kalakirjakaan ei houkutellut ainakaan ulkoasullaan. Tässä vaiheessa olo-sessiot  ja porukalla pohtiminen tuntuivat loistavalta vaihtoehdolta.

Ensimmäinen olo-sessio meni kuitenkin samaan kastiin aloitusluennon kanssa. Oli ihan kivaa pohtia vompatin syvintä olemusta, mutta se ei juurikaan auttanut alkuun javan oppimisessa. Olenkin sitä mieltä, että aluksi olisi voitu opettaa raa'asti vain javan perustoiminta, ja vasta myöhemmin laittaa opiskelijat pohtimaan, mistä tässä juuri opitussa asiassa on kyse. Myöhemmissä olosessioissa käsiteltävät asiat kuitenkin konkretisoituivat, ja tapaamisista alkoi oikeasti olla hyötyä oppimisessa. Ollisin tosin kaivannut oloiluihin vielä "kyselyvartti"-osiota, jossa olisi vapaasti voitu pohtia ohjelmoinnissa eteen tulleita ongelmia. Nyt sessioiden rakenne oli kuitenkin melko rajattu valmiiksi annetun virikkeen ja purun ympärille.

Kokonaisuudessaan voin sanoa, että vaikeinta ohjelmoinnissa on uuden kielen opettelu. Osatehtävät olivat suuria kokonaisuuksia ja niiden aikataulu oli varsin tiukka. Kertaukseen ei juurikaan ollut aikaa, mikä ei millään lailla parantanut tilannetta. Itseäni olisi helpottanut, jos olisi ollut mahdollisuus suorittaa jonkinlaisia pieniä osatehtäviä, jotka olisivat toistaneet oletetusti edellisessä tehtävässä opittua asiaa ja näin vahvistaneet oppimisjälkeä.

Kovin laajaa kokemusta ohjelmoinnin oppimisesta minulla ei ole, joten kaikki tilittämäni mielipiteet perustuvat täysin yhden kurssin antimiin. On sekin kurssi asiansa kuitenkin hoitanut, kun kykenen jonkinlaista koodia itsenäisesti tuottamaan.

Kokonaisuutena kurssi on järjestelyineen yltänyt kiitettävälle tasolle ja näin jälkeenpäin ajateltuna opetusmenetelmät tuntuvat suorastaan nerokkailta vietettyäni kaksi viikkoa firman palveluksessa tutustuen kohtalaisen alkukantaiseen opetus- ja koulutusjärjestelmään..

Mielestäni eniten parantamisen (tai vähintäänkin uuden arvoinnin tekemisen) varaa on kurssin aloituksessa. Oppimiskynnys oli mielestäni hyvin jyrkkä. Pari luentoa eivät avanneet kovinkaan paljon ovea Java-ohjelmoinnin mystiseen maailmaan. Toisaalta olen huomannut syksyn aikana, että Java-ohjelmointi vaati mielettömän määrä "alkutietoa" ennen kuin voi edes pienen oman ohjelman toteutusta. Jo pelkästään Javan main-metodin ( public static void main(String args[]) )

ymmärtäminen määreineen vaati itseltäni useamman ohjelmointikierroksen verran työtä. Niinpä mielestäni kurssin alussa tulisi olla joko hieman enemmän luentoja aivan Javan perusteista, tai sitten yksi tai kaksi lapio-harkkoihin verrattavaa tietokoneharjoitusta, jossa jokainen opiskelija yksinkertaisesti tekee saman kuin harjoituksen vetäjä (tämän näyttö näkyy projektorista).

Toinen asia, joka minua myös hiukan ihmetyttää on kurssin arvosanan muodostuminen. Lähinnä blogin yllättävän suuri painoarvo ja esseiden suhteellisen pieni painoarvo tuntuvat nurinkuriselta. Myöskin blogin arvosanan muodostuminen tuntuu näin etukäteen myös hiukan epäselvältä, kun yhtään ennakkotapausta ei toistaiseksi ole olemassa.

Viimeinen pieni käytännön asia, jossa on parantamisen varaa, joka tulee näin nopeasti mieleen on ohjelmointiharjoitusten palautus. Etenkin kurssin alussa oli välillä erittäin vaikeaa metsästää omaa koodiaan kun ei tiennyt kenellä assarilla se oli. Onneksi tähän ongelmaan tuli helpotusta kurssin loppupuolella. Esimerkiksi yhden pakollisen "opetuskerran" lisääminen viikko-ohjelmaan, jossa assarit palauttavat koodin ja käyvät sen läpi saattaisi olla hyvä idea.

Kaiken kaikkiaan kurssi oli kuitenkin toteutettu vähintäänkin kiitettävästi. Toki kurssi oli työläs ja välillä tuskainenkin, niin apua ei ollut koskaan kaukana; pahimmillaan irssi-screenin päässä :)

Täytyy sanoa että liike-elämän ohjelmoinnista enemmän tai vähemmän kaupallisiin tarkoituksiin, ei ole vieläkään selkeää kuvaa. En oikein vieläkään ole täysin varman millaista työtä esim. jonkinlainen Java-developer tekee. Onko se sitten puhdasta java-koodia eclipsellä, vai onko siinä jotain muitakin työkaluja. Lähinnä käsitykseni itse ohjelmakoodista on ”hieman” parantunut.

Tajusin kuinka loogista ja loppujenlopuksi jopa tietyllä tavalla helppoa ohjelmointi voi parhaimmillaan olla. Ymmärrän myös sen että ohjelmointi vaatii erittäin hyvää loogista päättelykykyä ja kokonaisuuden hallintaa, jos ohjelmakoodit ovat yhtään kompleksisempia. Tavallaan kunnioitukseni perus nörttiä kohtaan on kasvanut. Pitäisihän 99% ikätovereistani minua nörttinä, jos kertoisin mitä olen koko syksyn tehnyt.

Tajusin myös, ettei se koodin syntaksi mitään täysin älytöntä matrix-sekamelskaa ole. Onhan koodi loppujenlopuksi täysin ihmisten kehittämä asia. Tämä tekee siitä erittäin rationaalisen ja loogisen. Tietenkin puhun tässä nyt pelkästään javaa ohjelmoineen äänellä. Minulla ei ole käsitystäkään kaikista abstrakteimmista kone-ihminen-kielistä. Edelleen on siis joitakin asioita hämärän peitossa kun alkaa miettiä, että mitenköhän se tietokone nyt lopulta toimiikaan. Uskon kuitenkin että edes yhden ohjelmointikielen opettelu oli erittäin hyvä asia. Avarsi se ainakin minun maailmaani ja käsitystä ohjelmien toiminnallisuudesta huomattavalla tavalla.

Projektia tehdessä tajusin kuinka rajattomat mahdollisuudet ohjelmoijalla voi olla. Lähes kaikki mitä haluat ohjelmaasi liittyen tehdä on toteutettavissa. Uskoisin ohjelmoinnilla olevan varsinkin taiteen saralla vielä erittäin paljon annettavaa. Ihmiset jotka haluavat toteuttaa itseään kaikilla mahdollisilla keinoilla, saisivat ohjelmoinnista lähes rajattomia mahdollisuuksia tarjoavan työkalun, jota voisi hyödyntää täysin uudella tavalla. Nyt sinne TAIK:iin vaan pakolliset ohjelmointikurssit huippuyliopiston myötä, jotta saadaan innovatiivista taidetta!

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.

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.

Ensimmäinen kosketus Javaan on hyvä aloittaa, kuten tehtiinkin, Hello World -tyyppisellä miniohjelmalla, jossa vasta-alkajat saavat heti jotain konkreettista aikaiseksi ja lyhyen esimerkin siitä, miltä koodinpätkä näyttää, varsinkin silmällä pitäen Javan kielioppia. Tuleva ohjelmointilupaus saa esimaun Javan yksinkertaisimmista rakenteista.

Muistan kurssin seuraavana askeleena hyvin lennokkaat ja filosofiset luennot, sekä olo-tapaamiset, joissa perehdyttiin olio- ja luokkamaailmaan. Näistä ei kuitenkaan vielä tässä vaiheessa kostu paljoakaan. Vaikka luennoilla asiat vaikuttivat sinänsä järkeenkäyviltä ja kirjan opetukset selkeiltä, todellisuus oli karu. Kun piti käydä käsiksi itse harjoituksiin, osoittautui, ettei paljoakaan ollut mukaan tarttunut.

Aivan ensimmäiseksi luokan rakennetta olisi voinut terävöittää korostamalla entisestään luokan rakenteen kahtiajakoa metodeihin ja attribuutteihin. Konstruktorin ja pääohjelmametodin voi esitellä myöhemmin.

Seuraavaksi voisi valottaa tiedon varastoimista ja tietotyyppejä. Tietotyypit voisi kannattanee esitellä ikään kuin muoteiksi varastoitavalle tiedolle ja selittää, että useimmat näistäkin ovat olioita. Näillä tietopalikoilla metodit sitten leikkivät. Myös metodin puumerkki tulee pilkkoa osiin (näkyvyysmääre, palautusarvo, nimi ja parametrit) ja selventää näiden merkitystä. Legendaarinen, mutta aluksi hyvin kryptinen public static void main(String[] args) käy esimerkistä. Metodin erikoistapaukset, konstruktori ja pääohjelmametodi, täytyykin opettaa jossain näillä main.

Jotta metodeja osaa käyttää, on seuraavaksi tuotava mukaan sitä filosofiaa ja määrittää ohjelma olioiden vuorovaikutukseksi. Tämä on kriittinen vaihe ja rinnakkainen edellisen kappaleen aiheiden kanssa. Se, että ymmärtää, että luokka on vain olioiden resepti, josta näkee mistä ne on tehty, miten ne tehdään ja mitä niillä voi tehdä, on tärkeää. Vasta luokan ohjeiden perusteella tehty olio voi kutsua luokkaan koodattuja metodeja. Pisteoperaattori ja sen rakenne meni omalta osaltani ohi, ja tuskailin sen kanssa vielä kolmannessa Java-harjoituksessa. Kuten sanottu, vasta tässä kohtaa valottuu konstruktorin ja pääohjelmametodin tarkoitukset ja eksistentiaaliset viittaussuhde konseptit.

Käytännön opetuksissa korostettiin voimakkaasti oikeaoppista koodin jäsennystä ja muotoa, mitkä iskostuivatkin takaraivoon. Kielioppiongelmia ja kääntövirheitä, joiden suossa itse tarvoin viikkoja, ei pitäisi liiemmin ilmetä, jos alkeet opittiin tehokkaasti.

Näiden perusasioiden jälkeen laajennetaan toistorakenteisiin kuten, if-lauseisiin ja for-luuppeihin ja esitellään lisää esimerkiksi tiedonvarastoijaolioita (listat, mapit, joukot, jne.) sekä tyypillisimmät poikkeukset. Asiakokonaisuus kerrallaan tiedot ja taidot karttuvat ja tästä eteenpäin homma sujunee mallikkaasti myös itseopiskeluna. Itsenäistä työskentelyä ajatellen voisi Eclipsen deduggauksen sisällyttää ohjelman luentoon, ja Eclipseen voisi siirtyä aikaisemmin. Näitä isompia paloja ei kuitenkaan kannata haukata, ennen kuin perusteet ovat hallinnassa.

Helppo tehtävä tämä kaikki ei ole, varsinkin kun kurssi lähtee käyntiin varsin vauhdikkaasti ja vieläkin hankalamman tehtävästä tekee kaltaiseni tahvot, joilla ei ole minkäänlaista aiempaa kokemusta ohjelmoinnista. Jokin ydin pitää määritellä, jonka pohjalta ohjelmointityö aloitetaan, ja jonka ympärille lisätieto voi kertyä. Tällaisen lähtöpisteen pelkkä määrittely on pulmallista, kun sen pitäisi olla madollisimman suppea, mutta yksinkertainen ja samalla siihen ei saisi jäädä epäselvyyksiä. Suuri vastuu on myös ohjelmoijalle itsellään, ja kärsivällisyyttä kysytään aina kun tutustutaan uuteen.

Käytännön kannalta voisi ajatella myös harjoituksiin tasoryhmiä, niin kuin muistan eräässä olosessiossa esitettäneen. Näin voidaan puuttua usein toistuviin ja vallitseviin ongelmiin ja niiden syihin henkilökohtaisella tasolla, sekä luoda miellyttävämpi työskentely-ympäristö.

Alussa ei ollut hajuakaan. Missään lyhyen elämäni vaiheessa en ollut edes kurkistanut minkälaiselta valmis ohjelmakoodi oikein näyttää. Itse asiassa pidin ohjelmointia sinä yhtenä harmaana pilvenä Informaatioverkostojen tutkinto-ohjelman taivaalla. Alta pois vain, tuumin. Ainoa, joskin surkea, lähtökohta oli koodaajan stereotyyppi, jossa sosiaalisesti rajoittuneet nörtit tuhlaavat aikaansa näytön takana. Jälkikäteen oikein itkettää, miten vääristynyt irvikuva tämä on.

Olin kurssin alkaessa pihalla kuin lumiukko, enkä saanut otetta oikein mistään. Räpiköin Java tehtävistä läpi oikeastaan ymmärtämättä, mitä niissä luokissa oikein tapahtui. Vasta kolmannen harjoituksen aikana Javan perimmäinen logiikka avautui, mutta olin jo auttamattomasti jäljessä.

Kaikki tuo aika oli turhauttavaa, mutta vielä vähemmän ymmärsin omaa suhtautumistani ohjelmointiin. Ilmeisesti se, että verhon takaa ei paljastunutkaan sitä finninaamaista, näppäimistöä monotonisesti hakkaavaa teiniä, vaan jokin paljon seesteisempi ja ylevämpi maailma, sai minut kiinnostumaan ja pakotti kirimään takaisin muiden rinnalle. Totta kai, ohjelmoimaan istahtaminen pelotti aina hieman, (tuleeko tästä mitään!) mutta itse työ oli varsin mielekästä ja inspiroivaa. Suuri kiitos tästä viehätyksestä kuuluu hauskoille harjoitustehtäville.

Erityisesti yllätyin ohjelmoinnin loogisuudesta. Siisteyttä ja minimalismia arvostavana minua huojensi, kun aluksi ruma merkkien sekamelska jäsentyi hyvin järkeviksi palasiksi, joita voi kuvitella pystyvänsä tuottamaan itsekin. Ei ohjelmointiin turhaan liitetä suffiksia ”kieli”.

Kielistä puheen ollen, englannissa on mainio sana grind, jonka yksi merkitys viittaa raskaaseen, läpensä tylsään ja kehityksellisessä umpikujassa riutuvaan työhön. Suurin ero ennakko-odotusteni ja todellisuuden välillä oikeastaan kulminoituu tähän sanaan. Ohjelmointi ei ollutkaan grindaamista. Päinvastoin se vaatii luovuutta. Se vaatii ongelmanratkontaa ja suunnittelua. Se esittelee ohjelmoijalle jatkuvasti uudenlaisia haasteita ja alati muuttuvan työskentely-ympäristön. Syyskuun loppupuolella olin siis sekä kaikesta pihalla, että ällikällä lyöty.

En toisaalta ihmettele edellä mainitun stereotypian olemassa oloa. Ulkopuoliselle tarkkailijalle, jonkalainen itsekin siis olin, voi todella muodostua mielikuva elämättömästä koodaajasta, kun raukka viettää tyytyväisenä perjantai-illat koneen äärellä APIja selaillen tai jännittyneesti debuggaillen. Sivustakatsojalla ei tietenkään ole aavistustakaan, mistä on jäänyt paitsi.

Tuskin tästä kaikesta mitään leipätyötä tulee, mutta ohjelmoinnin peruskurssin jälkeen pystyn suhtautumaan huomattavasti rennommin siihen, mitä opinto-ohjelma tuo seuraavaksi tullessaan. Ohjelmoinnin kanssa tekemisissä oleminen ei enää pelota; möröt on kohdattu – jopa voitettu, onneksi heti näin alkuvaiheessa, joka oli sekin liian myöhää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.

Parin harjoituskierroksen jälkeen alkoi korviin kantautua huhuja jostain toisesta ohjelmasta, joka helpottaisi koodausta entisestään. Ohjelman nimeksi paljastui Eclipse ja pakkohan sitä oli sitten heti kokeilla. Mitä pidemmälle tehtäväkierrokset etenivät, sitä useampi phuksi oli vaihtanut Emacsin Eclipseen. Lopulta kun tehtävissä alettiin tarvitsemaan swingiä, meille pidettiin luento Eclipsestä ja meitä kehoitettiin viimeistään siinä vaiheessa vaihtamaan siihen. Kun kokeilin Eclipseä ensimmäistä kertaa oli järkytys suuri. Se osasi kertoa melkein virheestä kuin virheestä, heti kun sen oli kirjoittanut. Muutenkin Eclipse oli yhtä juhlaa Emacsin jälkeen.

Vaikka ymmärränkin mihin sillä, että alkukurssilla suositaan Emacsia, pyritään, olen useampaankin kertaan miettinyt onko siitä oikeasti niin paljon hyötyä, että sen käyttö kannattaa. Tottahan se on, että Emacsia käyttäen oppii tietyt asiat kunnolla kantapään kautta, mutta toisaalta sitä käyttäessä menee aikaa luvattoman paljon hukkaan monen turhan asian kanssa. Esimerkiksi kirjoitusvirheiden metsästys koodin seasta on mielestäni täysin turhaa touhua. Lisäksi Emacs ei ole käytettävyydeltään mikään maailman loistavin ohjelma, joten onko sen käytön opetteleminen muutamaa harjoitustehtävää varten kovin mielekästä.

Kurssin mittaan tuli tarvetta myös monille muille ohjelmille pelkän tekstieditorin lisäksi. Kaikennäköisiä ssh-, tiedostonsiirto-, tekstinkäsittelyohjelmia, jne... on tullut kurssin aikana käytettyä. Ja tietenkin, ah niin ihanat, käsitekartta ja dialogikarttaohjelmat. Lähes kaikkien tarvittavien ohjelmien käyttö on käyty läpi joko lapiokurssilla tai Studio1:llä. Mielestäni olisi kuitenkin hyvä lisätä kurssin kotisivuille linkkejä tai pieniä ohjeia esimerkiksi kuvankäsittelyyn ja äänitiedostojen muokkaukseen liittyen, sillä useat niitä kuitenkin tarvitsevat viimeistään projektia tehdessä.

Joukot ovat tuttuja otuksia Java-kotitehtävistä. Javassa joukoilla on joskus varsin näppäräksi osoittautuva ominaisuus: ne ottavat alkiokseen vain yhden identtisen alkion, joten ne sopivat hyvin vaikkapa mallintamaan sienikoria. Eihän kukaan sienestäjä nyt kahta saman sienilajin sientä poimisi, eihän? Mikäli joukko sisältää jo alkion ”kanttarelli”, ei toista samannimistä alkiota ”kanttarelli” huolita enää mukaan. Tietysti jos näiden herkullisuus-arvo on eriävä, niin silloin tarkkasilmäinen sienestäjä huomaa eron ja kelpuuttaa tämän henkilökohtaiseen sienikori-joukkoonsa.

Samassa joukossa ei siis voi olla alkioita a ja b siten että a.equals(b); on tosi [2]. Kaksi joukkoa ovat ekvivalentit (samat) jos ne sisältävät samat alkiot.

Java.util.Set on rajapinnan Collection<E> alirajapinta. Itse asiassa Set on kokoelma, joka toteuttaa ainoastaan Collectionin metodit sisältäen samalla tupla-alkioiden eston [2]. Set-rajapinnan toteuttavia joukkoja ovat mm. TreeSet, HashSet ja LinkedHashSet. Set-rajapinta ei määrittele joukolle mitään tiettyä järjestystä. Jos on tarve käyttää joukkoa ja järjestää alkiot tiettyyn järjestykseen, tarvitaan SortedSet-rajapinnan toteuttava joukko. Joillakin Setin toteutuksilla on tietynlaisia rajoitteita lisättäville alkioille, esim. jotkut joukot eivät ota alkioikseen null-arvoja[2].

HashSet on monipuolinen tietorakenne. Jos nyt haluaisimme luoda vaikkapa tällaisen HashSetin, voimme lausua taikasanat:

Set<NoJaa> blaa = new HashSet<NoJaa>();

Tämä joukko ottaa alkioikseen ainoastaan NoJaa-luokan (ja sen jälkeläisluokkien) ilmentymiä.

Koska Javan joukko toteuttaa Collection-rajapinnan, kaikki tutut tietorakenne-metodit ovat käytössä. Voidaan lisätä (add) tai poistaa alkioita (remove) tai tarkistaa, sisältääkö joukko tietyn alkion(contains). Joukon läpikäymiseen tarvitaan erillinen iteraattori-olio, mutta se on pieni miinus ottaen huomioon joukon helppokäyttöisyyden ja monipuolisuuden tietorakenteena.

- Teemu

[1] Joukko-oppi, Wikipedia
[2] Java API SE 5.0: Set

Studio1-kurssilla opetuksessa keskityttiin lähinnä käytännön harjoitteluun. Luentoja oli syksyn mittaan hyvin vähän, mutta muuta tekemistä sitäkin enemmän. Itse kaipasin lisää luentoja vain aivan kurssin ensimmäisille viikoille, jolloin työskentely oli vasta aluillaan ja kaikki aivan perusasiatkin olivat vielä täysin hukassa. Loppukurssista luentoja ei enää oikeastaan kaivannut ollenkaan ja nekin luennot, joita oli, tuntuivat vähän väkisin väännetyiltä ja turhilta. Samat asiat oppi paremmin seuraamalla netistä löytyviä tutoriaaleja.

Tärkeintä ohjelmoinnin opettamisessa on opettaa opetettavalle mistä hän voi etsiä tietoa ja ratkaisuja ongelmiin. Koska ongelmia on niin paljon eri tyypisiä, että on mahdotonta opettaa ratkaisuja niihin kaikkiin, on tärkeämpää opettaa mistä ratkaisuja voi etsiä. Kirjoista löytyy kattavasti tietoa lähes asiasta kuin asiasta, mutta tiedon etsiminen on usein hidasta ja työlästä. Niinpä opetuksessa kannattaa painottaa sähköisten tietolähteiden merkitystä tiedon etsimisen välineinä. (En haluaisi mainostaa, mutta...) Google on ohjelmoijan paras kaveri. API tulee heti perässä hyvänä kakkosena.

Assarivetoiset harjoitukset ovat elintärkeitä osia ohjelmointikurssin järjestämisessä. Kun itsenäinen harjoitusten vääntäminen tyssää johonkin ylimaalliseen ongelmaan on tärkeää, että viikottain on mahdollisuuksia konsultoida assareita, jottei yksi ongelma kaataisi koko tehtävän tekemistä. Näitä ohjelmointiharkkojakin voi vetää monella eri tavalla. Joillakin ohjelmoinnin peruskursseilla harjoitukset ovat (kuulemma) hyvin assaripainoitteisia: assari käy läpi kädestä kiinni pitäen kuinka asiat tulee tehdä. Itse olen kyllä vahvasti itsenäisemmän työskentelyn kannalla, jossa assarit ovat vain ongelmatilanteita varten.

Olen kaikinpuolin erittäin tyytyväinen kohta loppuvaan Studio1-kurssiin ja sen käytännön järjestelyihin. Muut kurssit voisivat hyvin ottaa mallia siitä miten hommat Studio1:llä on hoidettu. Kurssi on pakottanut tekemään itsenäistä työtä ja raitkaisemaan ongelmia omin neuvoin, mutta ei ole kuitenkaan jättänyt ketään hätään vaan aina on ollut apua saatavilla tarpeeksi. Tämä itsenäiseen tiedonhakuun ja ongelmanratkaisuun ohjaaminen on se asia mihin kaikessa ohjelmoinnin opetuksessa tulisi pyrkiä. Ohjelmoinnissa tärkeintä on, että osaa hakea ja soveltaa uutta tietoa erilaisista tietolähteistä, koska lähes ongelmaan kuin ongelmaan löytyy ratkaisu kaikille avoimista tietolähteistä, jos vain sitä osaa etsiä.

Ennen kurssia luulin ohjelmoinnin suurimpien haasteiden olevan useiden kielten osaamisessa ja niiden laajuudessa. Osoittautuikin, että vajaan puolen vuoden javailun jälkeen pystyy saamaan enemmän tai vähemmän selkoa muidenkin ohjelmointikielten syntaksista, vaikkei välttämättä kyseisellä kielellä osaisikaan ohjelmoida. Suurin haaste ohjelmoinnissa onkin järkevän ohjelmointilogiikan opetteleminen. Sellaisen, että asiat
pyritään tekemään mahdollisimman yksinkertaisesti, mutta silti selkeästi. Niin, että muutkin saavat koodista selvää.

Hyvä ohjelmointitekniikka kehittyy yhä satojen ja satojen koodaustuntien tuloksena. Aivan kuten matematiikassakin: saman ongelman ratkaisemiseksi on tarjolla useita, jopa kymmeniä, ratkaisutapoja. Osa niistä on elegantteja ja tehokkaita - toiset kovin kömpelöitä tai vaikeaselkoisia. Järkevämmät ratkaisutavat säästävät resursseja, joka tietokonemaailmassa tarkoittaa sitä, että ongelman ratkaisemiseen tarvitaan vähemmän laskukapasiteettia. (Vrt. esim piin laskeminen Monte Carlo -menetelmällä ja monikulmiometodin käyttö)

Keskustelin muutamia vuosia sitten erään suomalaisen ohjelmoijan kanssa ja esitin pari toivetta, jotka olisin nähnyt mielelläni softan seuraavassa versiossa. Hän totesi, että nykyiseen versioon on vaikea koodata edellä mainittuja lisäominaisuuksia, mutta kertoi olevansa koodaamassa uusiksi softaa - kakkosversiota, johon kyseiset ominaisuudet olisivat tulossa. En käsittänyt, miksei vanhaa softaa voinut tai kannattanut enää laajentaa. Kunhan koodaisi vaan puuttuvan osan ja liittäisi sen kokoonpanoon?

Ei siis riitä, että ohjelmakoodi pelkästään toimii ja on selkokielistä. Sen tulisi olla myös helposti laajennettavaa. Kenties siten, että muutkin
pystyvät lisäämään ohjelmaan haluamiansa toiminallisuuksia. Ohjelmoinnissa, kuten muuallakin elämässä, hyvä pohjustus ja suunnittelu on puoli voittoa.

Aloittelevana koodarina tuli tehtyä monia "virheitä". Koodiin tuli helposti overheadia - ajattelin asioita paljon monimutkaisemmin, kuin ne oikeastaan olivat. Seuraavana päivänä saattoi miettiä, mitä ihmettä oikein koodasi. Silti se toimi, vaikka neljä sisäkkäistä if-lausetta ei välttämättä ole järkevin tapa. Silmä kuitenkin kehittyi ja kurssin edetessä oppi uusia tapoja, millä koodista saa entistä esteettisempää.
Malliratkaisujen lukeminen auttoi runsaasti oman ohjelmointityökalupakin laajentamisessa. Vanhojen menetelmien tilalle tuli uusia ja tehokkaampia keinoja.

Ennen kurssia en myöskään uskonut, että hyvän ohjelmakoodin tekeminen vaatii niinkin draamattista määrää testausta. Metodin ei tarvinnut olla edes kovin monimutkainen ja silti sillä sai NullPointerExceptionin aikaan ainakin viidellä eri tavalla. Kun pelkästään tällä kurssilla tehdyt ohjelmat vaativat useiden tuntien eksplisiittistä testausta, en enää ihmettele, miksi Ubuntunikin kyykkää joskus!

Kaikki kunnia niille jotka ammatikseen koodaavat, sillä itse joudun sanomaan: "Ei kiitos."