Rühmatöö juhend

Üldine

• Rühma suurus on 3 inimest.
• Rühm valib projekti idee ja arendab selle valmis.
• Töö esitatakse kolmes etapis, iga etapp kestab kolm nädalat.
• Töö eesmärk on õppida paremini programmeerima ja omandada uusi oskusi.

Graafik

• 2020-03-10 rühmatööde algus
• 2020-03-29 etapp #1 tähtaeg
• 2020-04-19 etapp #2 tähtaeg
• 2020-05-10 etapp #3 tähtaeg
• 2020-05-14 praksis demo

Projekti planeerimine

• Enne projektiga alustamist tuleb esitada juhendajale projektiplaan. Plaan sisaldab lühikokkuvõtet projekti ideest ja nimekirja planeeritavast funktsionaalsust.
• Projekt peab kõigile rühma liikmetele kõigiks etappideks piisavalt tegevust pakkuma. Soovitame planeerida pigem rohkem funktsionaalsust, kui vähem. Kõik planeeritu ei pea valmis saama. Tulemus ei pea olema lõpliku lihvi saanud müügivalmis toode, vaid enamvähem kasutuskõlblik programm, mille loomise käigus saite palju õppida.
• Projekti sisu võib vajadusel muuta. Aruta seda vajadusel juhendajaga.

Punktide teenimine

Iga etapi eest on võimalik saada 10p (kokku 30p). Etapi eeldatav töömaht inimese kohta on 3 keskmist kodust tööd. Hindamine on individuaalne. Punktide teenimiseks korda järgnevaid samme, kuni oled jooksva etapi 10p täis kogunud.

1. Otsusta, mille kallal soovid töötada. Ülesande sisu peaks olema kasutajale vajaliku funktsionaalsuse lisamine või olemasoleva funktsionaalsuse märgatav muutmine.
   1. Punkte saab ainult kirjeldatud funktsionaalsuseks vajaliku koodi eest. Dokumentatsiooni, heli/videot/graafikat, planeerimistegevusi jms ei arvestata.
   2. Valima peaks peamiselt selliseid ülesandeid, et saaksid õppida uusi tehnikaid ja vahendeid, mis sulle väljakutset pakuvad. Põhiline eesmärk on õppida.
2. Veendu, et olemasolev kood toetab planeeritud funktsionaalsust. Pole mõtet proovida lisada kasutaja registeerimist, kui serverit veel pole. Sellisel juhul võiks võtta ülesandeks hoopis serveri lisamise. Vali selline ülesanne, et sul poleks vaja kellegi teise järel oodata.
3. Lisa oma projekti koodirepos issues listi uus issue, kus on ülesande kirjeldus.
   1. Kirjeldus peab sisaldama, mida kasutaja töö tulemusena teha saab. Kui muudatus kasutatavat funktsionaalsust ei mõjuta, siis see ei sobi eraldiseisvaks issue'ks.
   2. Kirjeldus võiks paari sõnaga vihjata, kuidas asi toimima hakkab ("andmed pannakse faili" vs "andmeid hoitakse mälus"). Pikka juttu pole vaja.
   3. Määra iseennast issue täitjaks.
   4. Näita issue't juhendajatele ja rühmakaaslastele.
4. Realiseeri kirjeldatud funktsionaalsus. Checklist:
   1. Kasutajal on võimalik kirjeldatud funktsionaalsust kasutada.
   2. Teiste varasemalt lisatud funktsionaalsus toimib ootuspäraselt.
   3. Uus kood on vanaga integreeritud ja ei dubleeri olemasolevat koodi. Kui midagi kattuvat oli juba varem olemas, siis uus kood kasutab sobivates kohtades olemasolevat loogikat.
5. Saada issue juhendajatele hindamiseks. Punkte saab vastavalt lahendatud ülesande mahule ja keerukusele. Kiire tagasiside saamiseks ära jäta esitamist etapi viimastele päevadele.

Issue trackeri efektiivsest kasutamisest:

1. Näidis repo https://github.com/mbakhoff/grading-template/issues
2. Iga issue'ga seotud commiti commit-message peaks algama vastava issue numbriga kujul #number. Niimoodi on kõik issue'ga seotud commitid issue vaatel nähtavad ja juhendajal ei jää sinu töö märkamata.
3. Issue pealkiri peaks kirjeldama issue sisu
4. Kui issue on tehtud ja punktid käes, siis klõpsa issue vaatel "Close issue".
5. Kui ootad kellegi teise issue taga, siis ootamise asemel võiks proovida seda issue't endale napsata ja ise ära teha. Selle jaoks tuleb jõuda kokkuleppele issue omaniku või juhendajaga.

Tehnilised nõuded

• Kirjutatakse java koodi ja kasutatakes objektorienteeritud programmeerimise tehnikaid.
• Koodi hoitakse normaalses versioonihaldussüsteemis (git või hg). Koodi kõige uuem versioon on igal hetkel avalikus koodirepos üleval (github/gitlab/bitbucket) ja kõlbab käima panna.
• Projekti ehitamiseks peab kasutama mavenit või gradle't (alates sellest etapist, kus me maveniga tutvume). Projekt peab järgima standardset projektistruktuuri.
• Programm peab olema lihtsasti käivitatav - peaks piisama versioonihaldusest viimase versiooni downloadimisest ja main meetodi käivitamisest. Vältida olukorda, kus enne peab installima erinevaid andmebaase, määrama seadistust jne. Kui rakenduse käivitamine on mittetriviaalne, siis peaks selle koodirepo readme failis dokumenteerima.
• Kood peab järgima häid tavasi ja ühtset koodi stiili - suure tähega klassinimed, lowerCamelCase meetodi ja muutujanimed, normaalne indentimine.

Rühmatöö survival guide

Mõnikord ei lähe õnneks ja satud rühma inimestega, kes ei saa/taha/oska tööd teha või aega planeerida. Siin on praktilisi näpunäiteid, kuidas ka sellises olukorras endale head punktid garanteerida. Mure korral aruta olukorda juhendajaga.

Soovitused

Esimene etapp on kõige kriitilisem. Alusta varakult, proovi projekti idee paika saada ja ots lahti teha. Proovi varakult aru saada, kui töökad su rühmakaaslased on, kui kiirelt nad sõnumitele reageerivad ja kas nad on suutelised iseseisvalt projekti panustama.

• Eelista rühma slacki channelit, kus on ka juhendajad. Siis ei saa keegi väita, et sinuga ei olnud võimalik suhelda.
• Tee oma töö varakult ära, sihi viimased asjad hiljemalt 48h enne tähtaega. Siis ei saa keegi väita, et tegid kõik viimasel minutil.
• Kui tahad teha suuremat muudatust, siis kirjuta enne rühmale oma ideest ja anna neile vähemalt 12h aega reageerida.
• Kui hakkad millegi kallal tööle, siis kirjuta rühmale kahe lauseline kokkuvõte, mis plaanis on. See aitab vältida olukorda, kus mitu inimest teevad sama asja. Kui sa seda ühe hooga valmis ei saa, siis jätkates kirjuta uuesti rühmale, mis seis on.
• Pane oma muudatusi varakult ja tihti üles. Siis on väiksem tõenäosus, et muudad rühmakaaslasega sama koodi. Pane üles ainult terviklikke muudatusi (muudatus peaks eraldiseisvalt vaadatuna toimiv ja loogiline olema). Väldi olukorda, kus sa oled terve päeva tööd teinud, aga mitte midagi üles pannud.
• Kui sul tekib funktsionaalsuse osas mõtteid ja plaane, siis kirjuta sellest rühmale. Kui planeerid midagi teha, kirjuta sellest ka. Kirjuta rühmale isegi siis, kui nad ei reageeri ega midagi tee. See hoiab neid seisuga kursis ja võimaldab neil hiljem liituda.
• Kui üritad midagi valmis teha, aga pole kindel, kuidas kõige parem oleks, siis küsi rühmalt ja juhendajatelt. Juhendajad on kõigist küsimustest vaimustatud. Kasuta võimalust arutada.
• Saage rühmaliikmega kohvikus kokku, kirjutage mõni koodijupp ühiselt valmis. Niimoodi õpib üksteiselt kasulikke nippe ja saab teadmisi jagada. See võte on väga kasulik ka siis, kui su ülesanne nõuab keerulisema loogika valmis kirjutamist ja/või ei oska tööga kusagilt pihta hakata.
• Kui sa oled teinud kvaliteetset tööd, teisi oma tegevusega kursis hoidnud, mitte venitanud ega blokeerinud ja sellest hoolimata sõidetakse sinu koodist üle (nt etteteatamata suurte muudatustega), siis see pole okei. Küsi juhendajalt nõu.

Probleemse rühmakaaslase välimääraja

• Homme programmeerija. Lubab, et tal on see kood, mille taga sa juba mitu päeva ootad, peaaegu valmis. Täna õhtul kindlasti paneb üles. Tavaliselt ei ole isegi etapi lõpuks mitte midagi valmis.
• Viimase õhtu programmeerija. Ei tee terve etapi jooksul mitte midagi või triviaalseid muudatusi. Kaks tundi pärast tähtaega paneb üles suure portsu koodi, mis olemasoleva koodiga kuidagi kokku ei sobi.
• Sabotöör. Töötab aktiivselt kaasa ja on üsna entusiastlik. Kahjuks enamus ideed teevad rohkem kahju kui kasu. Paneb muudatused varakult üles, aga need ei tööta ja võibolla isegi ei kompileeru. Parandab mitu päeva hiljem.
• Juhataja. Töötab efektiivselt ainult siis, kui kõik on koosolekuks kokku tulnud. Tahab kõik asjad peensusteni ette planeerida ja ära dokumenteerida. Kasulikku koodi kirjutab ise väga vähe.

Rühmatöö teemad

Iga rühm võib välja mõelda oma idee või implementeerida mõnda välja pakutud ideed. Idee ja etappideks valmiv funktsionaalsus tuleb enne töö alustamist kooskõlastada praksijuhendajaga. Soovitame tungivalt vältida graafilisi kasutajaliideseid - nende debuggimine on oluliselt keerulisem ja layoutidega võitlemise peale läheb palju rohkem aega, kui võiks arvata. Soovitame tungivalt kirjutada rakendus tavalise arvuti jaoks (mitte raspberry-pi, telefoni, satelliidi, drooni vms jaoks).

Järgnevad näidisprojektid on inspiratsiooniks. Neid võib vastavalt oma soovile muuta, kombineerida ja funktsionaalsust lisada/eemaldada.

Näidisprojekt: mini-git

Ehitada programm, mis suudab koodi ajalugu hallata. Funktsionaalsuse ideed:

• suudab salvestada projektis olevate failide hetkeseisu
• suudab soovitud vana seisu taastada
• suudab soovitud faile ignoreerida
• suudab failides tehtud muudatusi analüüsida ja ainult muutunud ridu näidata
• suudab üle võrgu teiste repository'dega sünkroniseerida
• muudatusi salvestades saab kirjeldava sõnumi lisada (commit message)
• muudatusi saab kommenteerida (code review)
• toetab failide ja muudatuste otsingut

Näidisprojekt: veebiserver

Ehitada veebiserver, mis suudab vastu võtta browserilt tulevaid päringuid ja neile adekvaatselt vastata. Funktionaalsuse ideed:

• suudab browseri saadetud päringute sünktaksist aru saada
• suudab vastuseks ketta pealt faile serveerida
• suudab vastu võtta browseris täidetud ankeetide andmeid (html forms; tekstilüngad ja uploaditud failid)
• suudab mitu päringut parallelselt töödelda
• suudab päringutele dünaamiliselt vastuseid koostada (vastavalt ankeeti sisestatud andmetele / aadressi lisatud parameetritele)
• võimaldab pluginaid kirjutada, nii et dünaamiliselt vastuste koostamise funktsionaalsust saab kergelt lisada
• toetab lehele parooliga sisselogimist

Näidisprojekt: todo app

Kirjutada programm, kus kasutaja saab endale ülesandeid lisada ja neid teistega jagada. Funktsionaalsuse ideid:

• ülesandeid saab vaadata, lisada, muuta ja lõpetatuks märkida
• ülesandele saab tähtaja määrata ja tähtaja lähenedes saadetakse e-mail
• kõiki andmeid hoitakse keskses serveris, kuhu saab üle võrgu ühenduda
• kasutajad logivad sisse ja nende tehtud muudatused seotakse nende kontoga
• ülesandeid saab omavahel linkida, mis võimaldab seotud asju kergelt leida
• ülesannete külge saab kommentaare lisada
• ülesandeid saab otsida - sisu järgi, omaniku järgi, tähtaja järgi jne
• ülesannet saab jälgida - muutumisel / kommenteerimisel saadetakse jälgijatele e-mail.
• ülesande looja ja täitja on eraldi. kasutajad saavad üksteisele ülesandeid määrata

Näidisprojekt: online chat

Kirjutada programm, mille kaudu kasutajad suhelda saavad. Funktsionaalsuse ideed:

• saab luua ja ühineda channelite / chat roomidega
• saab üksteisele private message saata
• sõnumeid ja kasutajakontosi hoiab keskne server, kuhu saab üle võrgu ühenduda
• server hoiab kõigi channelite ja private chatide ajalugu. kasutajad näevad oma vestluste ajalugu.
• saab üksteisele faile saata
• saab sõnumeid sisu ja aja järgi otsida
• saab saadetud sõnumeid muuta
• offline kasutajale private message saatmisel saadab server e-mail teavituse

Mängude tegemisest

Me ei soovita teha mängu. Mängu puhul on keeruline tööd jaotada ja tükke eraldiseisvalt testida. Kui otsustate teha mängu, siis soovitame mitte teha graafilist mängu ega real-time mängu. Pigem siis midagi turn-based. Hea mõte on teha midagi, mida saavad mitu mängijat koos üle võrgu mängida.