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 (esialgne)

• 2022-03-06 rühmatööde algus
• 2022-04-03 etapp #1 tähtaeg
• 2022-04-24 etapp #2 tähtaeg
• 2022-05-15 etapp #3 tähtaeg
• 2022-05-19 praksis demo

Hindamine

• Iga etapi eest on võimalik saada 10p (kokku 30p).
• Hindamine on individuaalne. Teiste rühmaliikmete tegevus ei mõjuta sinu punkte.
• Hinde määrab etapis tehtud töö maht ja keerukus.
  • Oodatav töö maht on selline, et igas etapis saab kolm nädalat jooksvalt tööd teha. Kui kogu töö tehakse etapi viimasel õhtul, tekib kahtlus, kas see on kolme nädala maht.
  • Oodatav keerukus on selline, mille käigus õpib paremini programmeerima. Eelkõige ootame, et kirjutatakse mitte-triviaalset koodi, mille käigus peab probleeme analüüsima ja lahendama. Head näited:
    • Andmestruktuuride kombineerimine ja mõistlikult kasutamine
    • Andmete efektiivne ja korrektne salvestamine / edastamine üle võrgu
    • Klasside/interface'de disain ja implementeerimine
    • Kasutajale vajalike algoritmide leiutamine
    • Uute libraryde mõistlik kasutamine
  • Eesmärk on õppida. Suures mahus triviaalsete muudatuste tegemine pole sama, mis väiksemas mahus keeruliste muudatuste tegemine ja selle eest saab vähem punkte. Lahenda enda jaoks väljakutset pakkuvaid ülesandeid.
• Hinnatakse kasutajale vajaliku toimiva funktsionaalsuse lisamist või olemasoleva koodi ümber struktureerimist, mis lihtsustab koodi ja/või on vajalik täiendava funktsionaalsuse lisamiseks ja vigade parandamiseks.
• Hinnatakse ainult seda koodi, mida on etapi lõpuks kasutajal võimalik reaalselt kasutada. Programmi põhiosaga integreerimata eraldiseisvad komponendid ei lähe arvesse (sh eraldi git branchid). Komponendid, mis on programmi lisatud, aga ei mõjuta kuidagi mõistlikult kasutajale pakutavat funktsionaalsust ei lähe arvesse.
• Hinnatakse ainult programmi koodi. Täiendavad lisad, nagu planeerimisdokumendid, dokumentatsioon, graafilised elemendid, heli-video, animatsioonid jne ei lähe arvesse.

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.
• Täpne tööjaotus ja igapäevane koordineerimine on rühma enda teha. Omalt poolt soovitame tungivalt:
  • Tööd peaks jaotama funktsionaalsuse kaudu, st "rühmaliige X vastutab, et kasutajal on võimalik teha Y". See rühmaliige kirjutab kõik vajaliku koodi, sh muudab vajalikke klasse ja testib oma lahendust. Ülesanne pole valmis enne, kui kasutaja saab funktsionaalsust kasutada. Soovitame tungivalt vältida spetsialiseerumist, kus nt üks rühmaliige tegeleb ainult andmebaasiga ja teine ainult kasutajaliidesega. Kogemus näitab, et siis toimub pidev üksteise järel ootamine ja lõpuks on ikka asjad valesti.
  • Tööd peaks planeerima nii, et ühe rühmaliikme töö hilinemine ei blokeeri teiste tööd. Kui pead ootama teise rühmaliikme koodi järel, siis võta kohe teine ülesanne või võta teise liikme töö üle (kokkuleppel teise liikmega). Kui see pole võimalik, siis konsulteeri kohe juhendajaga. Punkte antakse individuaalselt - kaitse oma võimalust tööd teha!

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

Näidisprojekt: command-line e-pood

Kirjutada e-pood. Funktsionaalsuse ideed:

• Server hoiab laoseisu ja tellimusi.
• Sisselogitud töötajad saavad laoseisu muuta ja tellimusi vaadata.
• Külastajad saavad laoseisu vaadata ja kaupa tellida.
• Külastaja saab oma ostude ajalugu vaadata.
• Tellimuse tegemisel saadetakse e-mail töötajale ja tellijale.
• Tooteid saab nime ja kirjelduse järgi otsida.
• Pood kogub toodete vaatamise kohta statistikat ja näitab, mis tooteid kõige rohkem vaadatakse / tellitakse.

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.