Miksi eri näkyvyysmääreitä tarvitaan?

Eri näkyvyysmääreitä käytetään eri tilanteissa: Määre public näkyy kaikille. Private näkyy vain sen luokan sisällä, missä sitä on käytetty. Protected näkyy luokassa ja sen jälkeläisissä. Lisäksi on oletusmääre, joka on voimassa, jos mitään muuta määrettä ei anneta. Oletus näkyy saman pakkauksen luokissa sekä luokan jälkeläisissä.

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ä.

Miksi tarvitaan metodeja? Eikö riittäisi, että on yksi luokka ja siinä main-metodi?

Metodeja tarvitaan ensinnäkin selkeyttämään koodia. Jos olisi yksi metodi, niin olisi vaikeaa tietää, missä kohtaa sitä mikäkin asia hoidetaan. Asian helpottuminen monimetodisessa koodissa edellyttää sitä, että antaa metodeille kuvaavat nimet. Näiden nimien avulla on paljon helpompi pysyä kärryillä siitä, mitä missäkin tehdään.

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.

Mikä ohjelmoinnin oppimisessa on vaikeinta? Miten tätä asiaa voisi helpottaa?

Kahdentoista edellisen kouluvuoteni aikana tarvittavat tiedot aseteltiin tarjottimella eteen oppituntien aikana, ja kotitehtäviä sekä projekteja tehdessä näitä tarjottimen antimia piti vain osata hyödyntää. Harvinaisen helppoa. Tämän opiskelutavan omaksuneena yliopistomaailma tarjosi jos nyt ei kylmää niin ainakin viileää kyytiä.

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.

Kuinka kurssia voisi parantaa

Neljäntoista opintopisteen suuruisena Studio1 on todella merkittävä kurssi kenelle tahansa, ohjelmointia jo hiukan taitaville että myös niille jotka tutustuvat siihen ensimmäistä kertaa fuksisyksynään. Niinpä kurssista on varmaankin hyvin vaikea saada yksinkertainen toimiva paketti, joten parantamisen varaa varmasti löytyy.

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ä

Rekursio – ja taas mennään!

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.

Portfolio – Ohjelmoimaan oppiminen

Alussa aina mahdotonta, tuntui syyskuun puolivälin tuntumilla. En saanut mistään oljenkorresta kiinni ennen syöksykierrettä alas. Näin jälkiviisaana, kaiken kantapään kautta oppineena on helppo pohtia, mitkä ohjelmoinnin apukeinot ja opetusmenetelmät olisivat kantaneet hedelmää nopeammin, ainakin omalta kohdaltani.

 

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ö.

Portfolio – Ohjelmointiin suhtautuminen ja sen muutos

Tämä katkelma purkaa suhtautumistani ohjelmointiin ja kirjoitankin siitä, mikä minua kouraisi kaikkein syvimmältä menneen syys-talven aikana.

 

 

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.

Kurssin työkalupakki

Kurssin alkajaisiksi meidät ohjattiin käyttämään koodauspuuhissa Emacs-tekstieditoria. Silloin ei vielä tiennyt paremmasta ja niinpä se tuntuikin silloin varsin hyvältä ohjelmalta. Ainakin itse ajattelin, että onpas hienoa kun tekstieditori helpottaa työskentelyä värjäämällä koodista javaksi tunnistamiansa sanoja. Kurssin mittaan ajatukset kyseisestä ohjelmasta ovat kuitenkin muuttuneet “hiukan”.

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ä.

Kuinka opettaa ohjelmoimaan?

Ohjelmointi on hankala asia opettaa. Ohjelmointi on loppupeleissä aika pitkälti käytännön työskentelyä, jota oppii vain tekemällä, mutta kuitenkin jo pelkästään alkuun pääseminen vaatii paljon pohjatietoa, mitä on pakko opetella jotenkin muuten. Tämä asettaa paljon haasteita ohjelmoinnin opettamiselle. Opetuksessa pitäisi löytää se sopiva tasapaino käytännön harjoituksien ja teoripohjaisen opetuksen kuten luentojen ja kirjan pänttäyksen välille.

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ä.