User:Jpoolak

Erialatutvustuse aine arvestustöö

Autor: Jarmo Poolak

Essee

Õppeaine I020 Õpingukorraldus ja erialatutvustus loengutes käivad õppejõud, ITK lõpetanud ja personal tutvustamas õppe- ja kooluelu ning ka jagamas kogemus IT alal.

Esimeses loengus räägiti põhiliselt õpingukorraldusest ja soovitati tutvuda kooli eeskirjade ja juhenditega. Probleemide ja küsimustega julgustati pöörduda kooli personali poole.

Täpsemalt õppimisest, õppimise valupunktidest ja enesemotivatsioonist rääkis magister Margus Ernits. Samuti tutvustas antud aine läbimisest. Kuigi mul on teatav IT alane töökogemus otsustasin siiski kirjutada ülevaatlikku essee aine raames toimunud loengutest. Kuigi võiks kirjutada essee kirjutada ka näiteks Signal R-st ja Web Socketitest aga jätan selle järgmiseks korraks.

Järgmises loengus rääkis dotsent Margus Ernits robootikast. Robotid on mulle huvi pakkunud juba lapsepõlvest saati. Minu mõistes oli robotitel inimese kuju: pea, kaks kätt ja kaks jalga. Nad pidid olema väga tugevad ja peaaegu hävitamatud. Just nagu tihti filmides näidatakse. Arvasin, et robotid on inimestest targemad, kuna neil on erakordne mälu ja jätavad kõik meelde mida kuulevad ja näevad.

Robootika jõudis minu teadvusse hiljem, kui kuulsin TTÜ korraldatud minirobotite võistlusest. Muidugi need robotid ei sarnane minu lapsepõlveaegsete kujutlustega suurtest võimsatest masinatest. Siiski need võistlusrobotid olid päris robotid, mis täitsid oma ülesannet, ülesannet milleks nad üleüldse eksisteerivad - pallide kogumine või näiteks õige raja leidmine. Nad tulid oma ülesannetega täiesti ise toime. Populaarne sõna selle kirjeldamiseks on "automaatselt". Mida kõike sellega ei mõelda.

Võime muidugi arutleda nende võistlusrobotite praktilise väärtuse üle. Samas olen mõistnud, et need samad peaaegu mängurobotid on automatiseeritud masinate ehk robotite hulgast vaid väike osa.

Tänapäeval on kasutuses väga palju erinevaid roboteid alustades tarkades mänguasjadest, võistlusrobotitest jätkates tööstus- ja allveerobotitega ning lõpetades inimesi teisel kontingendil opereerivate robotitega.

Mis neid roboteid ehk seadmeid ühendab? Neid ühendab mehhaanika, elektroonika ja (loogika) tarkvara. Robootika teeb põnevaks just need kolm komponenti, mis peavad sümbioosis töötama, et täita oma eesmärki ja põhjendada oma olemasolu. Robotite välja mõtlemine ja ehitamine on igaühele paras väljakutse, kuna vaevalt igaüks on kõva käsi nii jõuülekande, mikroskeemide koostamises kui ka programmeerimises. Isegi kui eelnevalt on olnud palju kogemusi robotite ehitamisel, leiab alati keerukama projekti, kui oli eelmine ja panna mängu kõik oma teadmised ja oskused. Tuleb vaid tõdeda, et robot on justkui Püha kolmainsus, millest saab õiget aimu vaid sellega reaalselt tegeledes.

Minu elus pöördus küll uus lehekülg, kui kirjutasin koodi reaalsetele seadmete, et neid juhtide. See on võimas tunne anda käske, mis täidetakse täpselt nii heas kui halvas. Tore asi see robootika ja häkkimine.

Ühes loengus Janika Liiv räägib, kuidas temast sai IT Kolledži õpilane ja veebiarendaja. IT süsteemida arendamist sattus ta õppima juhuslikult, mitte huvist tehnika või tehnoloogiate vastu. Ta ise ei teadnud mida infosüsteemi (IS) arendaja erialal õpetatakse. Ta asus kolledžisse õppima sundseisus, kuna ei saanud ühtegi teisi kõrgkooli sisse. Tema tegelik soov oli saada dramaturgiks, kes oleks hakanud kirjutama tsenaariume. Paraku leidis ta ennast kinnise loomuga inimesena selleks sobimatuna aga programmeerijaks... sobilikuna.

Õpingute ajal töötas IS analüütikuna ja mõistis, et see amet ei ole meeldiv, kuna kliendi ja tööandja ootusi on raske samaaegselt täitta. Seepärast Janika tundis, et ühel pool on klient oma soovidega, teisel pool on tööandja jälle oma eesmärkidega. Olen täiesti nõus, et siia on konflikt juba sisse "programmeeritud". Kliendiga ei saa olla liiga paindlik või lubada teha rohkem, kui võimalik või mõistlik. Samas ei saa olla liiga jäik, mille tulemuseks on kliendivajadustele (enam) mittesobiv infosüsteem või tarkvaralahendus.

Prl. Janika jutustab veel kuidas ta kasutas ära majanduslikku buumiaega, et kaubelda endale paremat palka luisates teise firma väljamõeldud parema pakkumise kohta. Kusjuures kandideeris esimest kohrda programmeerija ametikohale ega omanud mingit varasemat kogemust. Soovitaksin talle (veelkorra?) tulla kuulama dotsent Kaido Kikkase "IT sotsiaalsed, eetilised ja professionaalsed aspektid", kus on muuseas teemaks ka eetika.

Programmeerijana töötades ta mõistab, et programmeerimine sarnaneb (filmmi)tsenaariumiga - see peab olema selge, kompaktne ja mõttega. Üldjoontes olen prl. Janikaga väidetega nõus aga ma selgitaksin oma arusaamist. Koodi kirjutamise "mõtteks" oleks mingi probleemi lahendamine. Kood peab olema kompaktne ehk lühike, et see oleks kergesti hoomatav ja lihtsam. Just nimelt lähtekood peab olema mitte vaid lühike vaid ka lihtsam. Teinekord on otstarbekam asjad pikemalt lahti kirjutada, kui et järgmine kord lugedes koodirida pool tundi dešifreerida. Siit tuleb ka kolmas soovitus, et kood peab olema selge. Minu jaoks tähendab see, et kood on lihtsalt loetav - loetav nagu juturaamat. Segane või pikk kood põhjustab mittemõistmist, pendeldamist koodi eri osade vahel, selge loogika puudumist jne. Objektorienteeritud programmeerimist (OOP) kasutades on kood üldjuhul spaketikoodist loetavam ja mõistetavam, kuna kasutatakse objekt-andmestruktuure ja teisi võtteid, mis lubavad keskenduda andmetele, mitte protsessidele. OOPS-s on kood justkui juppideks võetud ja siis uuesti kokku tagasi sobitatud. Kusjuures "jupid" on täpselt nii suured, et igaühel neist oleks mingi konkreetne eesmärk ja funktsioon. Samuti peab kord kirjutatud funktsioon olema kasutatav hoopis teisis kohas, et vältida nt koodi dublitseerimist ehk SOLID.

Väide, et kasutaja tahab valikuid, mitte piiranguid ei pea minu arvates paikka. Liigseid valikud võivad eksitada kasutajat ja aeglustada tarkvara õppimist ja kasutamist. Käisin kunagi ühes reisibüroos, et broneerida laevakruiis Rootsi. Klienditeenindajal oli monitoril laevapiletite broneerimise programm, mis täitis arvuti terve ekraani. Seal oli palju teksti sisestamise kaste, valikute tegemise komponente jne. Tundus, et kõik võimalikud funktsioonid olid surutud ühele ekraanitäiele. Öeldes, et soovin laevas õhtusööki, hakkas teenindaja seda õiget kohta programmist otsima, kus on õhtusöögi optsioon. Peale 10 minutit otsimist võttis ta laua alt paksu A4 formaadis kiirköitja, milles oli välja prinditud broneerimissüsteemi kasutusjuhend. Peale järjekordse 10 minutilist kasutusjuhendi lappamist andis ta alla ja lubas selle broneeringu hiljem ära teha, kuna ta on seal firmas suhteliselt uus.

Kokkuvõttes peab tarkvara olema võimalikult lihtne kasutada, kui et omada funktsioone, mida ei osata kasutada. Seega olen ka Janikaga nõus, et programmide kasutamine peab olema intuitiivne ja lihtne. Siis pole kasutusjuhendit vaja lugedagi ja kasutaja ei tunne ennast rumalana.

Edasi tuli juttu Ruby programmeerimiskeelest jms. aga mulle meeldis, et preili mainis lähtekoodi versioneerimisest, Gitist ja Subversionist ehk SVN-st. Lähtekoodi versioonihaldust ei saa tarkvaraarenduses alatähtsustada. Versioneerimine tähendab, et lähtekoodi hetkeseis jäädvustatakse andmekogusse (ingl. k. repository), kust on hiljem võimalik taastada esialgne olek. Kui seda peaks vaja minema. See on väga oluline, kuna arenduse käigus muudetakse mitmeid faile ja kui juhtub, et midagi läheb katki, on võimalik lähtestada soovimatud muudatused esialgsesse seisu tagasi. See hoiab kokku palju aega, käsitööd ja närvirakke. Samuti on võimalik vaadata, kuidas koodifail läbi aja muutub.

Loengus tuleb juttu ka stereotüübist, et naised on kehvemad programmeerijad. Mina ei tea millele see väide põhineb aga minul on konkreetne tõestus, et see väide on väär. Kunagi sattusin lugema ühe neiu inglisekeelset blogi, mille autor oli aeroobikatreener ja toittumisspetsialist. Nüüd huvitas teda väga aga programmeerimine ja tal oli sellel teemal ka palju küsimusi. Ta esitas igal päeval ühe küsimuse, millele ta oli otsinud või proovinud otsida vastust ala spetsialistidelt ja tegi selle kohta "Stupid" question of the day blogipostituse. Tema suur huvi programmeerimise vastu motiveeris palju inimesi teda aitama ja ta otsustas lausa 365-le küsimusele sel viisil vastused saada. Ta tegi seda kõikke selleks, et saada programmeerijaks. Tema nimi on Iris Classon ja ta elab Rootsis. Alguses tema küsimused olid loomulikult elementaarsemad, siis jälle põhimõttelised ning lõpuks väga spetsiifilised, millele ta oskas juba ise vastata. Ta õppis sisuliselt aastaga .NET arendajaks ja sai sellel alal ka kohe tööd.

Lõpetuseks tõstatab prl. Janika küsimuse, et mis on programmeerija elutöö tulemus, millele ta paraku ise vastust ei anna. Mina küsiksin, mis on aga katlakütja elutöö tulemuseks kui ta vaatab kuidas puuhalg puuhalu järel tuhaks põleb?

IT süsteemide administraatori loengust jäi mulle meelde see, et asju õpib põhjalikult tundma läbi katsetuste. Just probleemide lahendamine õpetab sisemist hingeelu olgu tegu ükskõik millega. Skypis töötedes õppis, et asju tuleb teha õigeaegselt. Nii näeb tööandja, et oled tööse pühendunud. Üle töötada muidugi ei maksa ja väga pikad tööpäevad peavad olema põhjendatud. Taastumiseks kulub muidu lihtsalt rohkem aega ja töö effektiivsus väheneb. Olen prl. Carolyniga nõus, et nii ülemuste kui kolleegide tagasiside on oluline. See parandab suhtlust ja enesekindlust ning ekstreemsetes olukordades on see väga oluline, kuna siis keskendutakse konkreetsele probleemile ega nähta "suurt" pilti. IT maailma ekstreemsete olukordadeta pole õige IT maailm. Isegi automatiseerimine siin ei aita aga sihikindlus viib sihile.

Kuuendas loengus võttis Kristjan Karmo läbi tarkvara testimise põhitõed: testplaanid, testlood, süsteemi kaetus testidega. Kokkuvõttes võin öelda, et tuleb testida võimalikult palju ja varakult. Muidu lähevad koodivead kalliks maksma nii ajas või ka rahas. Vea parandamise hind sõltub muidugi projekti juhtimise metoodikast: waterfall võrdub suurema raha kaotamisega hilises projekti faasis või TDD, kus tarkvara/koodi vead tulevad kiiremini esile ja neid on ka sellepärast lihtsam parandada. TDD puhul testimine algab enne koodi kirjutamist programmeerija poolt ja jätkub integratsiooni- ja süsteemitestideni välja. Sealt maalt võtab testimise üle testija, kes testib nt funktsionaalsust või sooritab nn manuaalteste.

Andres Septer käis seitsmendas loengus rääkimas ilustamata IT tööturust. Kõige energilisem loeng antud aines, mida oli huvitav kuulata just tänu mõnusale keelepruugile. Mõned tsitaadid antud loengust, mis tõid muige näole: "Peteri printsiip - Iga inimest edutatakse senikaua, kuni ta jõuab oma ebakompententsuse tasandile", "töö läheb sinna, kus see ära tehakse", "riigiettevõttes jõuab molutamine kohe erilisele kunstilisele tasemele".

See viimane loeng oli kui kirss tordile ja tõmbas mõnusalt humoorikalt selle aine kokku.

Õpingukorralduse küsimused

Õppekorralduse eeskiri asub siin.

Küsimus A

Kukkusid eksamil läbi. Kaua on võimalik eksamit järele teha? Kellega kokkuleppida, et järeleksamit teha? Kuidas toimub järeleksamile registreerimine? Mis on tähtajad? Palju maksab, kui oled riigi finantseeritaval (RF) õppekohalkohal? Palju maksab, kui oled tasulisel (OF) õppekohal kohal?

Vastus

Kui õppur ei saanud eksamil positiivset tulemust, võib ta sooritada korduseksami kahe semestri jooksul pärast aine õpetamissemestri lõppu.

Korduseksam tuleb registreerida ÕISis. Akadeemilisel puhkusel olles tuleb aga õppeosakonnale esitada avaldus. Registreerumise ja soorituse vahele peab jääma vähemalt 2 tööpäeva.

Kordussoorituse tasu nii omafinantseeritud kui ka REV õppekohal on 20€.. Riigifintantseeritaval õppekohal kordussoorituse tasu puudub.

Küsimus 3

Millised võimalused on minna akadeemilisele puhkusele esimesel õppeaastal? Mis tegevused tuleb selleks teha? Kui pikk on maksimaalne puhkuse aeg? Kuidas toimub puhkuse lõpetamine? Kas puhkuse ajal saab deklareerida õppeaineid? Kas saab teha järele eksameid ja arvestusi?

Vastus

Selleks, et minna akadeemilisele puhkusele, tuleb kirjutada avaldus rektori nimele. Esimesel õppeaastal saab mitte akadeemilisele puhkusele, kas:

• Tervislikel põhjustel kuni kaheks aastaks;
• Aja- või asendusteenistuse läbimiseks kuni aastaks;
• Lapse hooldamiseks – kuni lapse kolmeaastaseks saamiseni.

Puhkuse lõpetamiseks tuleb kirjutada avaldus enne järgmise semestri punast päeva. Kui üliõpilane pole õigeaegselt esitanud akadeemilise puhkuse lõpetamise või pikendamise avaldus, lõppeb see automaatselt ja üliõpilane eksmatrikuleeritakse õpingutest mitteosavõtu tõttu.

Akadeemilisel puhkusel olles saab deklareerida õppeaineid (al. 2013/14 õppeaastast immatrikuleeritutel) kuni semestri punase joone päevaks ja osaleda õppetöös (sh. teha järele eksameid ja arvestusi), kui on tegemist:

• keskmise, raske või sügava puudega isikuga;
• alla 3-aastase lapse või puudega lapse vanema või eestkostjaga;
• akadeemilisel puhkusel viibimisega seoses aja- või asendusteenistuse läbimisega.

Ülesanne

Kui mitme EAP ulatuses tuleb õppekulud osaliselt hüvitada aasta lõpuks, kui esimese semestri lõpuks on olemas 26 EAPd ja teise semestri lõpuks 23 EAPd? Kui suur on teile esitatav arve?

Vastus

2013/14 õppeaastal on õppekava täies mahus täitmise määr 27 EAP. Ühe EAP hüvitamise määr on 50€. Esimesel semestri eest tuleb hüvitada 1 EAP (50€) ja teise semestril eest 4 EAP-d (200€). Aasta lõpiks tuleb osaliselt hüvitada 5 EAP-d ehk 250€.