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.

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!

Eräs infolle ennen minua loikannut naapurini kuvaili phuksisyksyn ohjelmaa edellä mainitulla tavalla alkusyksystä. Viimeistään loppusyksystä havaitsin sen varsin osuvaksi. Kurssilla pääpaino on ollut todellakin enemmän romaanin kirjoittamisessa kuin kieliopissa.

Rajallisen Java-kokemukseni perusteella on vaikea arvioida, mikä tapa opetella ohjelmoimaan olisi paras. Sen sijaan, että uuden kielen opiskelu olisi alkanut luennoilla kieliopista, meidät heitettiin lyhyiden tutustumisleikkien jälkeen suoraan kielikylpypäiväkotiin. Teorian ja käytännön järjestys lienee kasvatustieteiden ikuisia ongelmia ja molemmassa on etunsa. Kuten blogin kirjoituksissa ja muissa loppupuheenvuoroissa on jo käynyt ilmi, esseiden tai käsitekarttojen vääntäminen täysin tuntemattomasta aiheesta koettiin usein turhauttavaksi. Uskon kuitenkin, että olisin hajonnut pienemmiksi palasiksi ja paljon kivuliaammin, jos uuden asian soveltamisessa käytäntöön ei olisi ollut taustalla edes esseen kirjoittamisen antamaa pohjatietoa. Tottahan toki parasta oppimista olisi opiskella ensin asia, opetella se sitten käytännössä ja kirjoittaa vasta tämän jälkeen, mutta kuinka moni uskoo oikeasti tekevänsä näin?

Loppupuheenvuoroista voi lukea myös harvinaisen yhteneväisistä tunnelmista. Phuksisyksy näyttää lähes kaikille olleen yhtä kuin studio1, kenelläkään ei näytä olevan juuri mitään itse javaa vastaan, mutta kukaan ei ole tunnustanut haluavansa tehdä sitä työkseen. Konsensuksesta tekee mielenkiintoisen se, että juuri studiolla erot oppimisessa olivat suuria. Vaikka kaikki olivat periaatteessa samanlaisessa veneessä, toiset paahtoivat jo kohti Bahama-saaria, kun toiset vielä katkennein airoin yrittivät päästä pois Hanasaaren piipun varjoista. Tästä huolimatta koin studion hyvin yhteisöllisenä kurssina enkä pelkästään olo-sessioiden takia. Vaikka eettiset säännöt kielsivät prujaamisen, toisten neuvominen ja auttaminen oli usein paras tapa oppia itsekin. Solidaarisuus voi syntyä Puolan satamakaupunkien lisäksi myös Paniikissa. Phuksien neuvonpitoja tietokoneluokissa ei siksi mielestäni pitäisikään nähdä epäilyttävänä kopioimisena, vaan olo-sessioiden luonnollisena jatkeena.

Liityn ryhmän blogi-merkintöjen valtavirtaan myös siinä, mitä tulee käsityksiin ohjelmoinnista ja niiden muuttumisesta. Kesällä en tiennyt ohjelmoinnista juuri muuta kuin että se vaatii paljon kahvia ja öitä, mutta odotin sitä kuitenkin varautuneen kiinnostuneesti. Olinhan kuitenkin nähnyt niin monen humanistin muuttuneen päivänsäteestä menninkäiseksi, joka aamulla ryömiessään ulos tietokoneluokasta alkaa silmät hehkuen innostuksesta selittämää aiheesta, josta ymmärrän vain sanat “tietokone” ja “ohjelma”. Ainoa ohjelmointiin edes kaukaisesti viittaava kokemukseni oli html- koodin kirjoittaminen, joten kurssin alkaessa tiesin etukäteen kaksoispilkkujen lisäämisen jokaisen rivin loppuun olevan joskus ylitsepääsemättömän vaikeaa. Tämä ei johtunut pelkästään siitä, että lukion äidinkielen opettajan mielestä kaksoispilkkuja sai käyttää vain Ressussa tai Norssissa.

Olemattomat esitiedot huomioiden voitaneen sanoa käsitykseni ohjelmoinnista syntyneen kurssin aikana, sen sijaan käsitykseni luovuudesta muuttui, koska toisin kuin edellinen, se oli olemassa jo ennen kurssia. Tähän saakka olen yhdistänyt luovuuden enemmän mahdollisimman vapaisiin muotoihin kuin tiukkaan kielioppiin, vapaan improvisaatio-soolon katsoin vaativan huomattavasti enemmän luovuutta kuin matemaattinen barokki-musiikki, jossa jokainen tapa kuljettaa ääntä ja purkaa riitasointu voidaan käytännössä nimetä. Sitten ohjelmointi osoittautuikin mahdollisuuksien taiteeksi. Rajallisten mahdollisuuksien, joiksi tässä voidaan ajatella tietokoneen laskukyky ja ohjelmointikielen yksinkertaiset perusominaisuudet, soveltaminen lukemattomiksi variaatioiksi on erilaista kuin rajattomien sovellusten rakentaminen rajattomista mahdollisuuksista, mutta kummatkin vaativat luovuutta, työtä ja harjoittelua yhtä paljon.

Yhteneväiset kokemukset saattoivat olla merkittävä syy siihen, ettei blogissa juuri syntynyt keskustelua. Toinen syy on vaihtoehtoisten foorumeiden olemassaolo: keskustelua, jota blogiin ehkä odotettiin, käytiin irkissä ja ruokapöydässä. Pidän kuitenkin ryhmä-blogia hyvänä ratkaisuna kurssin täydentäjänä. Verrattuna siihen, että jokainen olisi koonnut omaan portfolioonsa omat kirjoituksensa, blogin ansioista omia tuntemuksia saattoi nyt verrata muihin ryhmän jäseniin. Myös ylimääräisenä avautusmisfoorumina se oli käytännöllinen ja tarpeellinen. Irkkiin verrattuna blogihajoilusta jää muisto pidempään. En tarkoita, että olisi kovin imartelevaa tai edes miellyttävää lukea asioita, joita on ajatellut ensimmäistä palautusta seuranneena yönä, mutta ainakin ne antavat autenttisen kuvan sen hetken tunnelmista. Blogimme on todellakin matka javailun maailmaan, ei pelkästään maaliin päässeiden hehkutusta.

Toisaalta blogiin tallennetut muistot matkan varrelta jopa vaikeuttavat tämän loppuraportin kirjoittamista. Ajatellessani kurssia, lopputulos on jotain, mistä James Joycekin olisi todennäköisesti ollut kateellinen. En todellakaan enää tiedä, mikä olin kurssin alkaessa, mutta uskon käyneeni läpi jonkin asteisin metamorfoosin. Kun viikko sitten sunnuntain ja maanantain välisenä yönä kävelin kotiin projektin palauttamisen jälkeen, tunsin itseni menninkäiseksi enemmän kuin koskaan. Minulla ei kuitenkaan ollut mitään sitä vastaan.

Olisi liioittelua sanoa kurssin muuttaneen maailmankuvaa ja identiteettiä, mutta se opetti paljon ajattelusta, jota tulemme tarvitsemaan jatkossa. Ja ennen kaikkea se sai meidät tuntemaan itsemme insinööreiksi.

Swing oli tullut jo edes jotenkin tutuksi viidennessä tehtävässä, ja graafinen toteutus oli huomattavasti mukavampaa, kuin edelliset sieni-tehtävät.

Ajastimen käyttöä olin henkilökohtaisesti testaillut jo bottia tehdessä, joten swing Timer-osio meni erittäin nopeasti. Tulosten tallentamisessa Comperable-rajapinta ei aluksi oikein auennut, mutta loppujenlopuksi parin google-esimerkin jälkeen asia valkeni. Itse tiedostoon tallentaminen ei oikean

esimerkin jälkeen ollut myöskään vaikea tehtävä. Kokonaisuudessaan ehdottomasti nopein ja vaivattomin harjoitus. Oli myös hauska nähdä kuinka assarit eivät onnistuneetkaan enää neuvomaan tehtävien suhteen, vaan ongelmanratkaisu tapahtui yhdessä pohtimalla ja API:a lukemalla.

Bonustehtävät olivat erittäin hyödyllisiä projektia ajatellen. Varsinkin wav-tiedostojen soittaminen oli ehdottomasti projektini kannalta hyvä juttu. Tehtävänanto vaikutti erittäin hämärältä, mutta käytettyäni rutkasti aikaa asian tutkimiseen, tajusin mistä oli kyse. Opin avaamaan linjoja ja käyttämään DataLine.info-tiedostoja. Opin jopa säikeistä jotain tekemällä äänistä säikeen. Projektia ajatellen äänien tekeminen oli ehdottomasti hyödyllisin osio.

Sikoban oli mielestäni loistava harjoitus ja viimeiset kaksi harjoitusta olivat ehdottomasti mielenkiintoisimmat ja kevyimmät. Oli kiva pelata täysin omaa tuotosta, varsinkin kun sai itse tehdä kaikki grafiikat. Swing alkoi tässä kuudennessa pikkuhiljaa tulemaan tutummaksi ja omia kokeiluja oli kiva tehdä. Mielestäni omasta Sikobanistani (Juustoban) tuli hyvin onnistunut kokonaisuus, varsinkin itse lisäämieni lisäominaisuuksien osalta. Oman koodin näki konkreettisesti heti kirjoittamisen jälkeen näytöllä ja se antoi paljon motivaatiota. Samanlaiset tuskalliset, pitkät ja epätoivoiset koodaus-sessiot puuttuivat tästä viimeisestä tehtävästä. Projektiin oli ehdottomasti kiva lähteä ennakkoluulottomalla mielellä ja erilaisia swing-ideoita täynnä.

Päätin kurssin alussa että yritän hillitä itseni ryhmäprojekteissa vaikka ohjelmointia osaankin ja ajoittain jopa nautin siitä. Ajattelin että seuraisin sivusta muiden puuhastelua ja auttaisin ehkä ongelmien ratkaisuissa ja suuremmissa kokonaisuuksissa. Toisin kuitenkin kävi ja ensimmäisessä projektissa oli pakko virittää turhankin monimutkainen algoritmipaketti kasaan. Ryhmän kesken yhdessä päädyttiin valittuihin tietorakenteisiin ja algoritmiin, mutta muut antoivatkin minun sitten toteuttaa itse algoritmin ohjelmakoodin. Enpä varmaan olisi kenenkään antanut siihen edes koskea :p Näin jälkikäteen katsottuna olihan se ehkä turhan monimutkainen ratkaisutapa. Kaikki kuitenkin olivat mukana kehittämässä ja ohjelmoimassa projekteja ja yhteistyö oli yllättävänkin helppoa ja toimivaa. Projektit olivat myös mielenkiintoisia ja niillä oli joku tarkoitus (voiton toivo) joka sai niistä innostumaan.

Koulutusohjelmamme kokonaisuutta ajatellen tällainen studio 1:en tapainen intensiivinen ja raskas johdatus ohjelmoinnin maailmaan on mielestäni kaikesta ilmeisestä tuskastaan riippumatta välttämätön. Se auttaa niitäkin opiskelijoita, jotka suuntautuvat omissa opinnoissaan mahdollisimman kauaksi ohjelmistoliiketoiminnasta ja ohjelmoinnista ymmärtämään mistä ohjelmistokehityksessä on kyse . Nykypäivänä tulee usein törmääneeksi erilaisiin IT-projekteihin ja onkin hyvä tietää esimerkiksi mikä on helppoa ja toisaalta mikä taas lähes mahdotonta toteuttaa. Kun sillä ns. ”toisella puolella” pöytää on joku joka tietää mitä vaaditaan mm. ohjelmistojen määrittelyssä, jottei tehtäisi turhaa työtä, voi lopputulos olla huomattavati onnistuneempi kuin tilanteessa jossa vaatimukset muuttuvat jatkuvasti tai ovat epämääräisiä.

Noinniinkuin tiivistettynä sanoisin, että oli kivaa, toivottavasti muillakin. Toivottavasti ette hajonneet liikaa kurssiin, ohjelmointiin tai minuun Nyt onkin sitten Studio 1 vihdoin pulkassa, vaikka alitajunnassa kummitteleekin että olen jotain unohtanut palauttaa. Nyt juhlistan saavutustani pirtelöllä – siihen tulee kuulemma mansikoita.
}

Vaikka ohjelmoinnin perus-perusasiat ovat iskostuneet hyvin pysyvästi mieleen (silmukat, ehtolauseet, taulukot jne.) On yllättävää huomata miten nopeasti hienommat detaljit oikeasti unohtuvat, ellei niitä aktiivisesti käytä pian oppimisen jälkeen. Hermann Ebbinghausen mukaan unohtaminen tapahtuu eksponentiaalisesti ajan suhteen, ja muistettujen asioiden määrän puoliintumisaika ei ole kovin pitkä. Joten lohdutukseksi kaikille joita java ahdisti: unohdatte väistämättä miten toimiva ohjelma kirjoitettiin Javalla, ja pääsette vielä opettelemaan Javan uudestaan! =)

Tärkeintä mielestäni on, että ymmärtää ohjelmoinnin perusteet, ja saa hyvän pohjan opetella yksityiskohdat vaikka uudestaan. Ohjelmoinnin opiskelusta on ehkä ollut suurin konkreettinen hyöty mistään käymästäni tkk:n kursseista, silä se on tuonut aina kesätyöpaikan. Olen onnekseni välttänyt Java-koodauksen ja ohjelmointikokemukseni työelämässä on rajoittunut monimutkaisiin Excel-taulukoihin, Office-pohjaiseen työkalukehitykseen ja Matlab-laskelmiin. Tuoreesta ohjelmointitaidosta on valtava kilpailuetu työmarkkinoilla: Javaa on aina jossain tilaisuus koodata, ja toisaalta taas keskijohdossa kukaan ei osaa koodata, jolloin heillä on tyypillisesti tarve ohjelmointia osaaville kesäharjoittelijoille. Pienten algoritmien vääntäminen on hyvin yleinen vastaan tuleva ongelma, joilla parhaimmillaan säästää aikaa ja käsityötä valtavasti, ja voi tehdä helposti suunnattoman vaikutuksen esimiehiin. Muita vastaan tulleita hyödyllisiä tarpeita ja koulussa opeteltavia asioita ovat perusteet kuvauskielistä ja esim. SQL-kyselyt. Näiden ymmärtäminen helpottuu huomattavasti kun ohjelmoinnin perusteet ovat hallussa.

Itse jatkan Javan opettelua vielä jonkin verran, Eclipsen käytön tehokkuudessa on vielä parantamisen varaa. Ohjelmointi itselleni merkitsee työn tehostamista, mutta ydinosaamista se ei minulle ole. Kuitenkin asenteeni on muuttunut melkoisesti oman peruskurssini jälkeen, kun taidon näyttämisen mahdollisuudet ovat tulleet esille. Tsemppiä kaikille ohjelmointiin!

Studio1 on kurssina ainutlaatuinen, ja mielestäni parhaimmillaan juuri phuksisyksynä. Eri puolilta Suomea tulleet, hieman orvot phuksit löytävät yhteishengen varsin äkkiä, kun toisten apuun vain on pakko turvautua silloin kun assareita ei ole käsillä. Ryhmäkoodaus, jota varsinkin alussa tuli harrastettua enemmänkin, opetti kyllä paljon sekä koodauksesta että kohtalotovereista, jotka ympärillä ahersivat. Joskus tämä aktiviteetti oli niin hauskaa, että saattoi viettää yhden viikonlopun aikana enemmän aikaa koodin ääressä kuin kotona.

Aivan kurssin alku oli kyllä yhtä tuskaa, kun ei ymmärtänyt ollenkaan miten koko homma toimii. Mikä olio? Mikä luokka? Ja vielä pitäisi kirjoittaa essee tästä, mahdotonta! Mutta kun pari ensimmäistä, työlästä, erittäin assarivetoista harkkaa oli käynyt läpi, alkoi tajuamaan mistä on kyse, ja siitä eteenpäin koodaus olikin vain yhtä ylämäkeä. 

OLO-sessiot, infolaisten rakkain opiskelumetodi, tuntui minusta ihan aluksi vähän turhalta selitykseltä, mutta muutaman ensimmäisen viikon sessiot olivat kyllä näin jälkeenpäin katsottuna varsin hyödyllisiä, ne avasivat hieman sitä koodauksen kummallista ajatusmaailmaa, johon on niin vaikeaa päästä sisään. Ja voipahan kehuskella tietotekniikkakauhuisille kavereilleen, että meillä tätä aihetta lähestytyään Platonin filosofian kautta. Myöhemmässä vaiheessa OLO-sessioiden hyödyllisyys vähän laimeni, mutta ihan mukavaa puuhastelua se oli silti, ja pidän ryhmätyöstä opiskelumuotona, joten en kokenut sessioissa käymistä turhana.

Ryhmätyö ei silti sovi kaikkiin tehtäviin, ja tämä ongelma tuli vastaan robottia ja bottia tehdessä. Koodaus ei mielestäni vain toimi ryhmässä, ja siitä seuraa että jokainen tekee tahollaan jotain omaa, joka sitten yhdistetään ryhmätyöhön. Kaikki siis koodaavaat itsekseen eri paikoissa, eikä ryhmätyön idea oikein toteudu. Lisäksi tehtävät jakaantuvat usein epätasaisesti, ja varsinkin tässä tapauksessa ryhmän paras koodari joutuu usein yksin tekemään sen vaikeimman työn. Lisäksi kahden koodityön tekeminen päällekkäin ei ole mitään herkkua, varsinkaan jos sattuu olemaan välikoe siinä vielä aikataulua sotkemassa. Robotti ja botti ovat silti ideana mielestäni äärimmäisen hauskoja, enkä haluaisi poistaa niitä kurssista, vaikka ryhmätyö saattaakin aiheuttaa käytännön ongelmia.

Esseeissä/käsitekartoissa työmäärä-hyöty suhde ei mielestäni ollut oikein kohdallaan. Kaksi päivää jotain tekstiä väännettyäni saattoi olla etten tajunnut aiheesta oikein mitään, mutta heti kun aihe tuli seuraavan viikon harkoissa vastaan, asia kirkastuikin yhtäkkiä. Tietysti osa ihmisistä oppii paremmin kirjoittamalla, mutta esim. säikeistä ja swingistä olisin toivonut aihetta alustavia luentoja. Netistä löytyy tietoa aika vähän ja suurimmassa osassa sen luotettavuus on aika epävarmaa. Tästä seuraa, että esseiden tekijät päätyvät lukemaan aikaisempien vuosien studiolaisten esseitä, ja tieto jää kiertämään kurssin sisälle. Luento saattaisi ehkä vähän pelastaa tältä, tai sitten opiskelijoille voisi antaa hyviä linkkejä luotettaville sivustoille, joilta uskaltaisi ottaa tietoa aiheesta.

Muutamista vioista huolimatta en yhtään ihmettele, että Studio1 on saanut sellaisen statuksen infolaisten keskuudessa ja maineen, joka kiirii muihinkin tutkinto-ohjelmiin asti. Ei varmaan mihinkään koulukurssiin tai tehtävään ole ikinä kehittynyt sellaista sidettä, kuin minulla ja myös muilla phukseilla tuntuu olevan Studio1:een. Kaikki se hiki ja veri ja työ on kuitenkin hyödyksi, ja nyt jälkeenpäin voi tyytyväisenä katsella syksyn aikaansaannoksia ja tuntea ylpeyttä niistä sadoista tunneista, mitä Eclipsen ääressä istuminen on vienyt. Viime kesänä suhtauduin epäilyksellä Studio1-esitteen väitteeseen, jonka mukaan osaisin jouluun mennessä koodata yksinkertaisen tietokonepelin. Nyt tuntuu huvittavalta ajatella tuota täysin kooditonta aikaa, kun en vielä edes tiennyt, mitä on Java. Tästä on hyvä jatkaa.

Suoraan asiaan. Yksi ärsyttävimmistä käyttöliittymistä on mikroaaltouunissani. Lämmitysajan säätö tapahtuu isosta pyöreästä säätöruuvista kääntämällä – tai niin ainakin luulisi. Todellisuudessa säädin ei tee mitään, ennen kuin on”aktivoinut” sen painamalla MW-nimistä painiketta. TIME-nappula on kutsuvasti säätöruuvin vieressä, mutta se säätää mikron kelloaikaa, ja tarpeeksi remppaamalla se ajastaa mikron. Näytön teksti 3:00 saattaa tarkoittaa joko pieleen asetettua kelloaikaa, 3 min lämmitystä tai sitä, että mikro käynnistyy itsekseen aamulla klo 3. START/STOP nappula ei tee mitään ennen kuin aika on asetettu, AUTO-nappula käynnistää mitään varoittamatta mikron oletusajaksi, antamatta kuitenkaan itse asettaa aikaa. Kun lopulta nyt esimerkiksi tuo 3 min on kulunut, pillastuu mikron palohälytintä muistuttava äänimerkki, jonka piipitys jatkuu ja jatkuu ja jatkuu… siitäkin huolimatta, että lämmitys on tässä vaiheessa jo loppunut, mikron ovi avattu, ja suljettu ja ruoka nostettu ulos uunista.

Hyvä esimerkki on myös eräs työssäni käyttämä piirustusohjelma, jossa fontin vaihtamiseen tarvitaan alueen aktivoimisen ja tekstin valitsemisen lisäksi sekä vasenta että oikeaa hiirinäppäintä, yhteensä kahdeksan klikkausta.

Käyttöliittymäsuunnittelussa puhutaan usein heuristiikoista, nyrkkisäännöistä. Tässä mielestäni parhaat ideat, joita voi soveltaa vaikkapa omiin javasovelmiin: Käyttöliittymän tulisi olla mahdollisimman yksinkertainen, ei mahdollisimman hieno. Käyttöliittymä tulisi suunnitella paperilla eikä antaa sen muodostua itsekseen. Dialogien ja painikkeiden ulkonäössä, asettelussa, ikoneissa, teksteissä jne. tulisi mukailla surutta jo yleisesti käytössä olevia ratkaisuja (jotain rajaa tietysti , esim. Windows ja Mac sovelluksiin löytyy tyylioppaat ja valmiit käyttöliittymäkomponentit. Jos työ menee laajempaan levitykseen, se pitäisi testauttaa käyttäjillä ja iteroida palautteen pohjalta. Ohjelman rakenteen pitää luonnollisesti pitää käyttöliittymä erillään, jolloin käyttöliittymän muuttaminen aiheuttaa vain triviaaleja muutoksia koodissa.

Käyttöliittymässä pitäisi lisäksi tavoitella yhdenmukaisuutta, antaa informatiivista palautetta toiminnoista, estää virheitä (esim. valikot komentojen sijaan) tarjota opastavat virheilmoitukset, tarjota mahdollisuus perua komentoja (undo, cancel) ja huolehtia ohjelman käyttäjän lyhytaikaisesta muistista eksyttämättä tätä dialogien viidakkoon.

Mikroaaltouuniani voisi parantaa seuraavilla piirteillä: samanlaiset toiminnot ryhmitellään yhteen, ja rajataan toisistaan kehyksillä. Tärkein nappula (ajan asetus, ja käynnistys) näkyvimmälle paikalle ja vierekkäin. Älyttömät ruokatyyppinappulat (höyryävä kuppi, vihannes, kalkkuna..?) pois ja tilalle tavallinen tehonsäätö. kellonajan asetus syrjään lähelle kellonäyttöä ja ajastustoiminta kokonaan pois. Mutta ehkä tämä olisi valmistajan mielestä vähentänyt mikron esteettistä arvoa. Huoh…

Vaikka Studio 1 oli työläin, oli se myös palkitsevin syksyn fuksikursseista. Kuten monella muullakin myös allekirjoittaneella aika, mitä matematiikkaan ja tuotantotalouteen kului, oli korkeintaan kolmasosa ajasta, joka kului javailun parissa. Välillä koodaus tapahtui porukalla Paniikissa sekä Maarintalolla, mutta useimmiten kotona kavereina ainoastaan 30 Firefoxin Java API -välilehteä, kasa kahvikuppeja ja verestävä silmäpari.

Kurssin omaleimaisinta antia olivat OLO-sessiot, joita ei tapaa kuin Studio-kursseilla. Maanantai-aamujen terapiasessioissa virittyi mielenkiintoista keskustelua aina rekursiosta hakualgoritmeihin ja ohjelmistoarkkitehtuuriin saakka. Välillä toki lipsuttiin laivanupotuspelin sääntöjen nyansseihin, mutta hauskaa oli joka tapauksessa. OLOilun merkitys ei enää lopussa tuntunut ihan samalta, mitä se oli alussa, joka näkyy myös gonahtamisessa bloggaamisen suhteen. Joulukuussa kasaan saatiin enää huimat 3 postausta!

Hätäisimmät phuksitoverit ovat ehtineet poistaa jo Eclipsen koneiltaan, mutta itselläni on tarkoitus toteuttaa vielä eräs loppusyksystä asti hautunut omaan käyttöön tuleva yksinkertainen ohjelma. Kenties sen jälkeen on aika sanoa Eclipselle hyvästit.

</studio1>

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