Archive | lokakuu 2011

Tenttiviikon jälkeen

Lauantai

Mikä olisikaan parempi tekemisen aihe lauantai-illalle kuin kirjoitella blogipostausta tänne? Henkisesti valmistaudun ensi viikon maanantaihin: tenttiviikon ansiosta harjoituskierrokset ovat olleet tauolla ja tiistaina on taas kierros sulkeutumassa — ja, tuolla on aikaisempien vuosien haastavempiin tehtäviin kuuluva Spoonerismi opiskelijoiden iloksi.

Käytännössä meidän tilastot eivät vaikuta kovinkaan lupaavilta: ensimmäistä tehtävää ei ole aloittanutkaan 242 opiskelijaa, toista tehtävää 285 ja tuota Spoonerismiä 347. Yhteensä kurssilla on 447 opiskelijaa, nämä luvut sisältävät jo aikaisemmin keskeyttäneet toki — mutta, kierroksen tehtäviä ei ole vielä aloittanut noin puolet siis. Katotaan, kuinka hyvin sunnuntai korjaisi tätä tilannetta, ja mihin tilanteeseen sitten maanantaina päädytään.

Tosin, tilastoista paljastuu myös jotain positiivista: pistejakauma tehtävissä on tällä hetkellä kuuluisa U-jakauma, eli ne, jotka ovat tehneet tehtävän ovat saaneet siitä erittäin hyviä pisteitä. Vaikka tehtävät voivatkin olla hankalia, ne eivät ole mahdottomia.

Sunnuntai

Ja tarina jatkuu sunnuntai-yönä. Tehtävien osalta tilastot ovat 222, 263 ja 321. Käytännössä siis sunnuntain saldo on noin 20 opiskelijaa, jotka saivat aloitettua tehtävien tekemisen, ja luultavasti saivat ne täysillä pisteillä loppuun saakka.

Lisäksi irkissä on ollut koko päivän päivystystä, mistä kiitos elämättömille assareille. Normaaleja kysymyksiä ollut aika paljon, usein vastaukseksi on jäänyt tehtävänannon kummastelu yhdessä. Odottamaani vähemmän mystisiä ongelmia Spoonerismistä, eli ihmiset olivat lähteneet ratkaisemaan sitä ihan mielekkäällä tavalla, tai sitten osasivat ainakin kysellä fiksuja siitä.

Nyt alkaa tulemaan vastaan myös ohjelmoinnin kumulatiivinen luonne, eli aikaisemmin opittuja juttuja täytyy vain soveltaa rohkeasti — mutta, aina ei ole muistissa, miten aiemmin tehtiin asioita. Kertaus on opintojen äiti. Nyt nukkumaan, niin maanantain koitoksen jaksaa!

Maanantai

Hyvien yöunien jälkeen heräsin virkeänä seitsämältä, pakkasin tavarani ja suuntasin kohti Otaniemeä. Sivuhuomautuksena, nukkumaan tekee elämästä kivempaa, kannattaa kokeilla. Varustukseni on suttupaperia, kyniä ja juomapullo ja valmistauduin koitokseen. Jo ennen kymmentä väki oli valunut pohtimaan tehtäviä — uusi kävijäennätys aamuryhmään. Kymmeltä hiljeni hieman — luultavasti luento.

Iloksemme IT infra kaatui kahden aikaan. Odottamamme täällä Maarilla tilanteen kehitystä, mutta tämä taitaa olla tältä päivältä: 12-14 välillä kävi 26 opiskelijaa ohjattavana. Luonnollisesti kierroksen sulkeutumista on jatkettu keskiviikkoon, koska tämä ei ole opiskelijoista kiinni oleva asia.

Tiistai

Viimeinen ilta ennen kierroksen sulkeutumista. Irkkiä on taas tullut seurattua ja siellä autettu ihmisiä. Tehtävien osalta 122, 169 ja 260. Edellisellä kierroksella tippuneita oli noin 90, eli vielä ollaan vähän koholla tuossa määrässä, katsotaan kuinka huominen laskarisessio auttaa tilannetta.

Keskiviikko

Vihdoinkin kierros päättyy. Loppulukemaksi jäi 98, 118 ja 208. Kolmas tehtävä tosiaan oli normaalia vaikeampi, kuten etukäteen tiedettiin. Mielestäni kuitenkin kurssilla kannattaa olla muutama vähän haastavempi tehtävä, jotka saavat ihmiset miettimään, että mistäs tässä on kyse. Ja, tuo tehtävä oli tosiaan tarpeen vain niille, jotka tavoittelevat parhaimpia arvosanoja, joten siinä kohtaa vaatimustaso saakin olla vähän korkeampi.

Kaikin puolin tuo kuitenkaan ei näytä mielestäni kriisiltä, vaan on normaalia kurssiarkea — keskeyttäviä opiskelijoita on aina jonkun verran, eikä tuo nyt vaikuta mitenkään poikkeukselliselta piikiltä keskeyttäneiden määrässä. Lisäksi tilastojen valossa keskiviikko oli varsin rauhallinen laskaripäivä, eli varmaankin kaikki, jotka halusivat apua, saivat sitä.

Jahas, unohtakaa tilastojen lukeminen mun osalta: todellisuudessa noin kymmenen keskeyttäneen sijaan puhuttiinkin 23 opiskelijasta. Se onkin jo vähän enemmän, ja herättää kysymyksiä: mihin meidän opiskelijat vuotavat?

Seuraavaksi pitäisi taas paimentaa omat paimennettavat.

Mainokset

Kynä ja paperia

Olemme nyt siirtyneet ohjelmointikurssilla siihen vaiheeseen, että opiskelijoiden kysymykset ovat syvällisempiä: ne käsittelevät keskeisten algoritmien toimintaa, ratkaisutekniikkaa ja käsitteitä. Esimerkiksi tällä hetkellä olion ja olion kentän välinen ero on suurimpia esiin nousevia ongelmia.

Ongelmanratkaisun selostamista Kallinin, Kampparin ja Sihton Fortran-oppikirjassa (1974). Kurssilla valumme hitaasti ja varmasti siihen, että autamme opiskelijoita enemmän teoreettisessa puolessa, eli ongelmanratkaisun hahmoittelussa

Nykyisin olenkin varustautunut laskareihin aina kynä ja paperin kanssa, ratkaisun luonnostelu ja hahmottelu paperille on minulle luonnollinen tapa selittää, mitä kannattaisi tehdä. Myös koodin lukeminen yhdessä rivi riviltä on tärkeä osa työkalupakkia.

Mutta, mitä laskareissa sitten tapahtuu käytännössä? Ehkä harmikseni voin sanoa, että ei kovinkaan paljon, me pyöritetään siellä peukaloita ja irkataan. Maanantai on päivä ennen kierroksen sulkeutumista, ja meillä on varattu peräti kolme assaria sinne – mutta suurta yleisöryntäystä ei ole ollut ja asiakasjono on pysynyt hallussa.

Kierrän siis ihmiseltä toiselle, kuuntelen, mitä opiskelija on tehnyt ja sitten kyselen asioita. Sitten koetan ymmärtää, mikä on ongelma, onko jokin ohjelmoinnin perusrakenne hukassa, onko ratkaisutapa hassu vai onko tehtävänanto vain luettu pintapuoleisesti. Ja sitten suherran paperille epämääräisiä kuvioita ja nuolia, jopa pseudokoodia. Ja, kyllä se tehtävä yleensä siitä avautuu myös, pala palalta.

Tunnelmia Helsingin yliopistolta

Helsingin yliopiston tietojenkäsittelytieteen laitoksen blogissa on juuri tarina ohjelmoinnin peruskursseista siellä. Meillä* Aalto-yliopistolla on tietenkin vähän erilaista, mutta silti kirjoittelen muutaman ajatuksen ylös.

Ratkaisu, jota tuolla kutsutaan kisällioppimiseksi, on omien kokemuksieni valossa varsin hyvä ja samankaltaisia piirteitä on meidän laskuharjoituksissa — jotka siis vastaavat pajatoimintaa: tulla ja mennä saa, kuten haluaa — me olemme paikalla, vastaamassa kysymyksiin ja kommentteihin. Sen lisäksi tärkeä auttamisen foorumi on kurssin irkkikanava, josta kirjoittelin jo aikaisemminkin. Irkissä se kiintoisa piirre on, että laskuharjoitustilaisuuksiin verrattuna kaverien apu (peer-support) on yleisempää, koska kaikki kuitenkin pohtivat samoja ongelmia. Laskuharjoitustilanteessa varsin normaalia on kiertää neuvomaan ihmisiä saman ongelman kanssa, yleensä peräkkäin. Ehkä tästä myöhemmin lisää.

Mutta, tekstissä kysytään monia hyviä kysymyksiä, joita kannattaa pohtia:

Kuinka monta kertaa olet kysynyt pajassa neuvoja vieressä istuvalta, sen sijaan että odottaisit ohjaajaa apuun? Kuinka usein olet huomannut, että jo pelkkä kysymyksen muotoilu jollekin toiselle ja koodin ääneen lukeminen auttaa vastauksen löytämiseen? Autolla ajaessa puhutaan vauhtisokeudesta — mikä termi sopisi siihen, ettei kovaa koodatessa huomata pulmia omassa koodissa? Koodisokeus?

Ainakin itse olen monta kertaa koodatessa hoksannut tuon ääneenpuhumisen merkityksen debuggauksessa, ja siksi yksi yleisin kysymykseni kun saavun assaroitavan luokse onkin ottaa selkoa siitä, mitä ohjelma tekee: tarvittaessa simuloimalla yhdessä, usein vain siten, että assaroitava kertoo nopeasti yleiskuvan siitä, mitä on tapahtunut, ja itse pystyn koodia lukemalla katsomaa, että onko kuvaus suunnilleen oikein: välillä se bugi löytyy ihan tällä sanallisella kuvailulla.

PS. Toivon kovasti, että joku päivä täällä kuulisi myös aitojen paja-assareiden näkemyksiä maailman menosta; aika monia olen koittanut jo lirkutella — mutta, aina saa myös tarjoutua vapaaehtoiseksi.

* Meillä on tässä kohtaa huvittava termi — olen Helsingin yliopiston opiskelija, ja assarijoukkomme on muutenkin hakenut vahvistuksia tietotekniikan opiskelijoiden ulkopuolelta.

Viisi ohjetta prujaajalle

Akateemisessa maailmassa yksilön ajatustyötä pidetään perinteisesti tärkeänä. Siksi prujaus, eli kopiointi tai vakavammalla tasolla plagiointi, on vakava asia. Mielelläni en edes blogaisi tästä, mutta ehkä on rehellisempää avata salaisuuksien kammiota ja myös niitä assarin työn vähemmän maineikkaita kohteita: mekin törmäämme ja joudumme käsittelemään näitä asioita.

Kokemuksieni valossa annan muutaman ohjeen niille jotka haluavat prujata, koska selkeästi aina asioita ei ole mietitty loppuun asti tai ne on tehty kiireessä.

1. Älä mainitse kommenteissa, että ratkaisualgoritmin toteutus on kopioitu suoraan Wikipediasta

Tämä on vähän veteen piirretty viiva, koska todellisuudessa pyörää ei kannata keksiä uudestaan, vaan käyttää niitä valmiiksi tehtyjä pyöriä. Näin siis todellisuudessa, akateemisessa työskentelyssä on erilaisia periaatteita. Riippuen kurssista ja ihmisistä, ulkoisten koodien käyttö voi olla joko täysin kiellettyä tai täysin sallittua ja suositeltavaa, tarkasta ensiksi heidän näkökulmansa asiaan. Ja tosiaan, jos tehtävänannossa keskeinen osa on algoritmin toteutuksella, ei sitä algortimia toteutuksena kannata välttämättä kopioida suoraan Wikipediasta ja merkitä sitä lähteeksi — se algoritmi saattaa olla juuri se ainoa asia, mitä tehtävän teossa piti ratkaista.

2. Tarkista, ettei koodiisi jää toisen tekijän nimeä

Varsin monet editorit lisäävät tiedoston alkuun tietoja tekijästä, esimerkiksi @author-tagilla. Tarkista, että siinä ei ole kaverisi nimeä.

3. Pohdi, tuleeko koodiasi lukemaan ihminen

Kuten aiemmin kerroin, kurssillamme on käytössä fuksipaimennus. Suomeksi siis, meillä on ihmisiä, jotka lukevat osan koodia läpi: kopioidessa tarkista, ettei teidän koodi päädy samalle ihmiselle arvioitavaksi. Ihminen kyllä tunnistaa liiallisen samankaltaisuuden.

4. Älä erotu joukosta

Mieti tarkkaan, vastaako toteutustapasi sitä, mitä kurssilla on opetettu: erilaiset ja poikkeavat rarkaisut kiinnittävät huomiota ja jäävät siksi helposti mieleen. Ainakin alkuvaiheessa kurssin tehtävät ovat sellaisia, että koodit tuppaavat olemaan hyvin samanlaisia, tälläisessä tilanteesssa prujaus on jopa melko helppoa, kunhan toteutustapasi on vain samanlainen toisten kurssilaisten toteutustapojen kanssa.

5. Mieti vielä kerran

Halutko todella tehdä sen? Kyllä, tiedän, että kiire hönkii niskaan ja helpot nopat on kivoja. Kuitenkin, prujaamista vastaan on kaksi isoa argumenttia.

Ensimmäinen argumentti on oppiminen. Prujaaminen aivottomasti tarkoittaa, ettet opi sitä kurssilla opetettavaa asiaa. On toki mahdollista, ettet koskaan elämässäsi tule tarvitsemaan sitä tietoa, mutta varsinkin peruskursseilla väitän, että näihin samoihin käsitteisiin ja konsepteihin törmäilee ennemmin tai myöhemmin kuitenkin.

Toinen argumentaatiolinja taas on ensisijaisesti keppiin perustuva: seuraukset kiinnijäämisestä voivat olla yllättäviä ja ikäviä, varsinkin akateemisissa yhteyksissä — tosin, myös teollisuudessa kopionnilla voi olla ikäviä seurauksia.

Seuraukset yliopisto-opiskelijalle voivat olla epämiellyttäviä: kurssin suoritus voi keskeytyä prujaamiseen ja kurssi uusitaan — eli, ei helppoja noppia. Opiskelijarekisterikin voi ottaa vähän damagea tälläisestä harrastuneisuudesta, ja tahra pysyy siellä valmistumiseen saakka. Ja, ainakin pääsee juttelemaan kivoille ihmisille; mikä olisikaan loistavampi tapa saada oma naama tutuksi laitoksella?

— — —

Ja näin, ohjeet päättyvät tähän. Todellisuudessa meillä on arsenaalissa käytössä vielä muitakin aseita, joista ei ehkä ole syytä puhua enempää. Se ikävin juttu minulle ainakin on, että tästä aiheesta tarvitsee edes puhua, tai että tästä sai helposti melko pitkänkin tekstin. Olemme kuitenkin yliopistolla ennenkaikkea opiskelemassa ja oppimassa uusia taitoja, emme suorittamassa kursseja.

Eli, jos oikeasti päädyit lukemaan tätä tekstiä, koska tarvitset apua prujaamiseen, mitäpä jos kävisitkin huomenna laskareissa?

Kiitokset Teemulle kommenteista ja ajatuksista tekstiin liittyen.

Very human touch

Eräs mielenkiintoinen idea täällä Aalto-yliopistossa on fuksipaimennus. Eli, koneellisesti tehtävän tarkastuksen lisäksi ihmissilmä lukee, arvioi ja kommentoi ohjelman läpi. Mielestäni tämä ei ole vain tarpeellista, vaan myös välttämätöntä.

Luvan kanssa käytän erään toisen kurssin esimerkkiä:

public class Esimerkki {

public static void main(String[] args){

    int valinta = Pop.valitseNappula("Valitse:", "kivi", "paperi", "sakset" );
    double vastaus = Math.random();

    if (vastaus < 1.0/3.0 ){
        vastaus = 0;
    } else if (vastaus < 2.0 / 3.0){
        vastaus = 1;
    } else {
        vastaus = 2;
    }

// aloita tarkastelu!
    if(valinta == 0){
        if(vastaus == 0){
            Pop.tell("Valitsen kiven. Tasapeli.");
        } else if (vastaus == 1){
            Pop.tell("Valitsen paperin. Voitin.");
        } else {
            Pop.tell("Valitsen sakset. Voitit.");
        }
    } else if(valinta == 1){
        if(vastaus == 0){
            Pop.tell("Valitsen kiven. Voitit.");
        } else if (vastaus == 1){
            Pop.tell("Valitsen paperin. Tasapeli.");
        } else {
            Pop.tell("Valitsen sakset. Voitin.");
        }
    } else {
        if(vastaus == 0){
            Pop.tell("Valitsen kiven. Voitin.");
        } else if (vastaus == 1){
            Pop.tell("Valitsen paperin. Voitit.");
        } else {
            Pop.tell("Valitsen sakset. Tasapeli.");
        }
    }
}
}

Spagettisuudeltaan koodi on varmasti nyt al dente, juuri sopivalla tavalla tahmaista. Koneellinen tarkastus kuitenkin toteaa, että toteutus on hyvä, se suorittaa tehtävänannon, kun taas ihmissilmä näkee, että ohjelman ratkaisulogiikkaa voisi parantaa — ja voikin sitten antaa tästä vinkkejä opiskelijoille: ”Oletko miettinyt tätä toteutusta ihan loppuun asti?” tai ”Huomaatko, että tämän voisi esittää myös tällä tavalla?”

Toinen syy ylevän koodin parannuksen — mistä toivottavasti jäi mieleen jotain sellaisia periaatteita ja kikkoja joita voi soveltaa sitten itse — lisäksi on tuoda sosiaalista kanssakäymistä (niin, jopa teekkareiden kanssa) opiskelijoiden ja henkilökunnan välille; näyttää että tuolla jossain on joku, jolle palautuksesi merkisevät jotain.

Tämä on ehkä vaikeampi näistä kahdesta tavoitteesta, koska viestien pitäisi kuulostaa luonnollisilta, mikä on ainakin minulle hankalaa. Kyllä sitä katsoo, että miten kierros on mennyt — ja veikkaan, että me kaikki assarit haluamme, että ne menisi ihmisillä hyvin. Mutta, miten saada tämä yhteydenotto kuulostamaan vielä enemmän inhimilliseltä, sellaiselta, että se oikeasti ei vain auttaisi sen tietosisällön kanssa, vaan ottaisi huomioon sen sosiaalisen tukemisen puolen paremmin?

Ehkä tästä päästään siihen suurimpaan kysymykseen. Minkälaisena opiskelijat sitten tuntevat nämä viestit: onko niistä apua ja tukea omaan oppimiseen — vai onko ne vain turhaa spämmiä? En tiedä. Vaikka kovasti pidän ajatuksesta, että koneellisen tarkastuksen lisäksi myös ihminen arvioi koodin, onko se sitten kuitenkaan vaivan väärtti?