Archive | marraskuu 2011

Saako opiskelijaa itkettää?

Me kaikki assarit kohtaamme tilanteita, kun eteemme tulee purkkapallo. Epämääräinen viritys-säätö, joka melkein toimii. Vaihtoehtoja voisi olla koko ratkaisustrategian uudelleenpohdinta yhdessä opiskelijan kanssa tai pyrkiä setvimään ja selvittämään, miksi koodi ei toimi. Molemmissa näissä on etunsa ja haittansa, luonnollisesti.

Mutta, miten tämä liittyy itkemiseen? Ei, en ole siirtynyt iltapäivälehtimaiseen otsikointiin, vaan taustalla on tarina, jonka olen kuullut.

Ohjelmointikurssilla oli opiskelija, joka oli useamman tunnin vääntänyt omaa koodiaan toimintakuntoiseksi. Laskareissa assari kohteliaasti suositteli, että ohjelman voisi aloittaa koodaamaan tyhjästä, uudella paremmalla ratkaisualgoritmilla. Tästä seurauksena oli itkureaktio, olihan siihen omaan koodiin käytetty runsaasti aikaa ja vaivaa — nyt se oli arvotonta.

Seuraavana aamuna sama opiskelija ilmestyi laskareihin. Hän tuli kiittämään assaria tästä voimakkaasta kehoituksesta.

Ja, kukapa ei ymmärtäisi opiskelijan näkökantaa tässä: kaikki valvotut tunnit ja työ onkin mennyt hukkaan. Mutta, ymmärrän myös ohjaajaa — epämääräisen purkkapallon debugaaminen ei ole helppoa eikä kivaa.

Mielellään sitä auttaisi ongelman ratkaisussa tavalla, jonka opiskelija on ihan itse keksinyt, mutta aina se ei ole niin helppoa. Ihmiset ampuvat itseään jalkaan tai tekevät muita jännyyksiä. Seuraava esimerkki varmaankin valaisee, mitä tarkoitan (erään kurssilaisen suoritus, luvan kanssa täällä):

if self.is_open():
   i = 0
   for i in range(len(self.buyers)):
     if amount >= self.buyers[i].get_limit():
       if i == len(self.buyers) - 1:
         if amount == self.buyers[i].get_limit():
           self.price = amount
           return False
         x = 0
         for x in range(len(self.buyers)):
           highest_limit = self.buyers[0].get_limit()
           if highest_limit highest_limit = self.buyers[x].get_limit()
             x += 1
             self.price = highest_limit + 1
       else:
         i += 1
    elif amount < self.buyers[i].get_limit():
      return False
  self.buyer = bidder
  self.buyers.append(Bid(bidder, amount))
  return True
else:
  return False

Vaikka kovasti yritin ymmärtää, mitä tämä koodi tekee, se jäi minulle nopealla katsauksella epäselväksi. Onneksi tarkistusjärjestelmämme antoi tuosta täydet pisteet, muuten olisi pitänyt kaivaa tuostakin selvyys esille — luultavasti aidossa ohjaustilanteessa olisin lähtenyt muokkaamaan tuota koodia lähemmäksi malliratkaisun tyyliä.

Niin, jopa siinä tilanteessa, että tämä tuote on opiskelijan itsensä tekemää ja pohtimaa, niin pitäisi arvokkaana sitä, että istuisimme hetken aikaa alas ja miettisimme erilaisia ratkaisutapoja tähän ongelmaan ja niiden eroja toteutustavoissa. Toisaalta, joskus opiskelijat kehittävät hyvin luovia ratkaisuja ongelmiinsa, joista näkee sisäisen logiikan hyvin selvästi. Toisen kurssilaisen toteutus (jälleen luvan kanssa) ongelmaan oli seuraava.

if self.is_open() and self.get_minimum_bid_amount() <= amount:
  self.bid_list.sort()
  self.highest_bid = self.bid_list[-1]
    if len(self.bid_list) == 1:
      self.bid_list.append(amount)
      self.highest_bidder = bidder
      return True
    else:
      self.bid_list.append(amount)
      self.highest_bidder = bidder
      return True
else:
  return False

Tuossa on piilossa yksi virhe, minkä takia se ei toimi kuten oletettua. Jätettäköön tarkempi virheen etsiminen harjoitukseksi. Kuitenkin, tässä kohtaa olisin luultavasti erottanut tämän virheen erikseen ja selostanut, mistä se johtuu ja sitten olisimme ratkaisseet vain tämän yksittäisen ongelman.

Mikä sitten erottaa nämä kaksi tapausta toisistaan? Ensimmäisen opiskelijan kohdalla minun on vaikea seurata ratkaisua, siellä on myös mukana ohjelmointikikkoja, joita ei normaalisti haluaisi nähdä. Toisen opiskelijan ratkaisu taas on melko suoraviivainen ja sen logiikan ymmärtää heti.

Ideaalissa maailmassa molempia tapauksia olisi tietenkin autettaisiin samalla tavalla, koska on aina hyvä rakentaa opiskelijan oman ajattelun ja ongelmanratkaisun päälle asioita. Käytännössä, opiskelijan omat ratkaisut voivat olla ongelman luonteeseen sopimattomia tai hyvin vaikeita toteuttaa, jolloin on helpompi vääntää ratkaisua oikeanlaiseen suuntaan. Erityisesti, jos opiskelijan koodi aiheuttaa mielenkiintoisia (lue: vaikeita) erikoistilanteita, joiden hallinta sitten muuttuu suoksi.

Opiskelijoiden itkettäminen ei välttämättä ole paha asia. Erilaiset ratkaisutavat toivottavasti myös laajentavat opiskelijan kykyä ratkaista ongelmia tulevaisuudessa, varsinkin jos pystyy kriittisesti arvioimaan omaa ratkaisuaan. Ainakin minulle kriittinen arviointi ja vaihtoehtojen puntarointi on keskeinen osa ammattiosaamista. Ehkäpä The Daily WTF tulisi ottaa pakolliseksi lukemistoksi kurssille…

Mainokset

Milloin tehtäviä tehdään?

Kurssimme automaattinen tarkistusjärjestelmä Goblin tarkistaa tehtäviä väsymättä viikon jokaisena päivänä kellon ympäri. Tähän mennessä palautuksia on tullut yhteensä yli 25 000 kappaletta. Määrä on niin suuri, että tilastojen tekeminen Excelillä ei sujunut enää kovin jouhevasti, vaikka lopulta sitten homma onnistuikin…

Jakautuvatko palautukset tasaisesti eri viikonpäiville tai kellonajoille? Entä voisiko huoltokatkon järjestää helposti johonkin tiettyyn aikaan, jolloin se ei haittaisi opiskelijoita?

Vastaus molempiin kysymyksiin on ei. 24/7 toimivaa tarkistusjärjestelmää hyödynnetään kaikkina päivinä ja kaikkina aikoina. Luonnollisesti tiistaina klo 12:00 oleva tehtävien määräaika näkyy jakaumassa selkeästi, mutta sellaista hetkeä ei juuri ole, että palvelin saisi levätä.

Tarkastellaan ensiksi, mihin vuorokauden aikaan palautuksia tehdään eniten:

Palautusten jakautuminen vuorokauden aikoina

Kuvaajasta näkee selvästi, että palautuksia tehdään eniten iltapäivällä. Toisaalta käyttäminen on vilkasta noin kello kymmenestä eteenpäin aina pitkälle yöhön saakka. Teekkarit nukkuvat tilaston perusteella todennäköisimmin klo 4-8, vaikka silloinkin tehdään joitakin palautuksia. Lounasaika taas laskee käyttöastetta merkittävästi juuri ennen pahimman ruuhkahetken alkua.

Entäpä sitten viikonpäivät, mitä sieltä voidaan havaita:

Tehtävien palauttamisen jakautuminen eri viikonpäiville

Ei liene mitenkään yllättävää, että maanantai erottuu noinkin selkeästi muista päivistä. Suurin osa opiskelijoista tekee tehtäviä siis vasta edellisenä päivänä. Lauantai näyttää olevan se päivä, jolloin koulutöitä tehdään vähiten. Sunnuntaina tehtäviä kuitenkin tehdään innokkaammin kuin perjantaina.

Jos maanantai on vilkkain päivä, niin kuinka aikaisin opiskelijat sitten tekevät tehtäviä noin yleensä? Tutkitaan seuraavaksi, milloin palautuksia tehdään viikon aikana ennen DL:ää:

Eri kierrosten palautusaktiivisuus viikon aikana ennen määräaikaa. Y-akselilla on vuorokausien määrä ennen määräaikaa ja X-akselilla kierroksen numero. Määräaika on kuvaajan yläreunassa.

Kuvaajassa on esitetty, milloin palautuksia on tehty. Havaitaan selkeästi, että viimeinen vuorokausi on varsin tiivistä aikaa tehtävien tekemiseen. Viiden ensimmäisen kierroksen määräaika on ollut klo 12, mutta kierrosten 6 ja 7 määräaika oli klo 20. Tästä johtuen yön vaikutus näkyy hieman eri tavalla. Eri kierrosten välillä ei ole juurikaan eroa, milloin palautuksia on tehty.

Tutkitaan viimeistä vuorokautta vielä tarkemmin:

Palautukset viimeisen vuorokauden aikana

Tästä kuvaajasta voidaan nähdä, että tehtäviä on tehty tiiviisti edellisenä iltana ja yönä sekä sitten juuri ennen kierroksen sulkeutumista tulee vielä viimeinen palautussuma. Kuudennen ja seitsemännen kierroksen osalta koko päivää on hyödynnetty ahkerasti, kun kierros sulkeutui illalla.

Meidän assareiden näkökulmasta on periaatteessa samantekevää, milloin tehtäviä tehdään, mutta luonnollisesti tämä näkyy myös kurssin harjoitusryhmien kävijämäärissä. Jos porukkaa on paljon, niin avun saaminen kestää pidempään ja aikaa neuvoa on vähemmän. Eri harjoitusryhmien ruuhkaisuus näkyy seuraavassa kuvassa:

Eri harjoitusryhmien ruuhkaisuus

Maanantain kohdalla on aivan selvä piikki ja loppuviikon harjoitusryhmissä on selvästi hiljaisempaa. Kahden viimeisen kierroksen DL:n siirtyminen keskiviikkoon ja torstaille näkyy myös siten, että parina viime viikkona myös keskiviikon ryhmissä on ollut enemmän opiskelijoita.

Mitä tästä kaikesta voisi siis sanoa? Jos et tee tehtäviä klo 4-8 aamuyöllä, niin on varsin todennäköistä, että jokin muukin tekee tehtäviä samaan aikaan. Ilmiö näkyy myös kurssin IRC-kanavalla: noihin aikoihin on hiljaista, mutta muuten keskiyön jälkeenkin kanavalla on vielä suht aktiivista keskustelua.

Mikäli tehtäviin kaipaa neuvoja, niin on suositeltavaa aloittaa hyvissä ajoin, jolloin assareilla on harjoituksissa enemmän aikaa neuvoa. Maanantaina aloittaminen ei ole muutenkaan hyvä idea, jos esimerkiksi Aallon tietokoneet hajoavat tai tehtävien kanssa tulee vastaan muita ongelmia. Jos taas olet ihan varma, että kaikki sujuu suunnitelmien mukaan, niin tehtävät saa kyllä kasaan, vaikka aloittaisi vasta tiistaina aamulla. 🙂

Crash!

Huono tuuri tietojärjestelmissä jatkuu edelleen. Aallon tietojärjestelmät kyykkäsivät kauniisti maanantaina, ensksi kymmenen aikaan ja sitten totaalisesti kahdelta.

Tunnelmia Maarilta kello neljän aikaan

Voin vain todeta, että tämä on turhauttavaa. Kurssilla on maanantaille laitettu iso kasa laskuharjoitusryhmiä sekä ylimääräisiä assareita, koska ohjelmointikierrokset menevät kiinni tiistaina.

Mutta, koska tietokoneet eivät toimi, ohjelmoinnin neuvominen on hankalaa — ellei ihmiset kanna omia läppäreitä mukana. Ikävänä seurauksena opiskelijat siirtyvät ongelmiensa kanssa ryhmiin, joissa ei ole erityistä ruuhkavarautumista.

Kierrosaikatauluja voidaan onneksi siirtää melko rauhallisesti, vaikkakin siihen liittyy oma hitautensa. Lähinnä pitää saada aikaan päätös siitä, että tilanne on oikeasti niin vakava, että aikataulua on syytä rukata. Tästä tulee ikävä epätietoisuus hetkeksi aikaa.

Mutta, ehkä sitten ensi viikolla asiat toimivat hyvin!