[OSy] Deadline a odevzdavani rozsireneho zadani

[Martin Decky]

Vazeni kolegove,

pro lepsi prehlednost jsem pro jednotlive tymy vypocital presny deadline 
pro odevzdavani rozsireneho zadani. Vychazel jsem z casovych bonusu 
pridelenych panem Martincem za ucast ve studii, predchozich penalizaci a 
dalsich ulev.

V praxi to znamena, za budeme hodnotit stav Vaseho Subversion repository 
ve stavu k casu N+1 00:00 CET (kde N je den uvedeny nize v tabulce).

DaMa:   4. 4.
DrHaUr: 18. 3.
HlLiVa: 26. 2.
MaSkZa: 4. 3.

Po uplynuti deadline jednotlive oslovim kazdou skupinu a domluvim se s 
ni na terminu osobniho odevzdani semestralky, kdy spolu Vase reseni 
kratce interaktivne projdeme a dozvite se hruby odhad bodoveho 
hodnoceni. Finalni bodove ohodnoceni obdrzite v nasledujicich tydnech po 
odevzdani pote, co Vasi praci dukladne prostudujeme.


Zaverem strucne nekolik rad k zaverecnemu odevzdani:

1) Soucasti repository musi byt k casu odevzdani vse, co si prejete 
zahrnout do Vaseho finalniho reseni. Na cokoliv, co nam napriklad 
poslete emailem nebo commitnete do repository po deadline, nebudeme brat 
zretel (az na mimoradne a explicitne povolene vyjimky).

2) Jako obvykle pri odevzdavani dila tohoto rozsahu je vhodne vyvarovat 
se zasadnich zmen a prepisovani tesne pred odevzdanim. I v pripade, ze 
Vam neco trochu nefunguje, radeji se to nepokousejte zurive na posledni 
chvili opravit, protoze muzete nechte rozbit neco jineho. Hodnoceni 
finalniho reseni nebude rozhodne binarni, takze se v nem mohou pozitivne 
odrazit dobre minene zamery, ale bohuzel negativne i nesmysly, ktere jen 
shodou okolnosti nahodou funguji.

Nekolik poslednich zbyvajicich dnu pred deadline je vhodne venovat 
uprave a unifikaci zdrojovych kodu (aby cela semestralka mela jednotny 
coding style), dopisovani dokumentace atd.

3) Pokud pouzivate nejaky nastroj pro referencni dokumentaci (napr. 
Doxygen), prosim necommitujte do repository vystup tohoto nastroje. 
Typicky se totiz jedna o stovky malinkych HTML a PNG souboru, ktere 
jednak nema valny smysl samostatne verzovat a jednak to zdrzuje pri 
checkoutu repository. Bohate postaci, kdyz bude mozne referencni 
dokumentaci snadno ze zdrojoveho stromu vygenerovat.

Naopak, pokud budete mit nejakou rucne psanou dokumentaci vytvorenou 
nejakym nezavislym prostredkem (napr. v beznem word processoru), potom 
je samozrejme na miste, abyste do repository commitnuli treba export ve 
formatu PDF pro pohodlne cteni.

Pripominam, ze mnohdy je velmi uzitecne, aby rucne psana a generovana 
dokumentace spolu byly vhodne hypertextove provazany (aby ctenar mohl 
snadno prechazet od "high-level" popisu k "low-level" dokumentaci a 
pripadne i zpet). Proto byva velmi caste, ze i rucne psana cast 
dokumentace je soucasti vstupu pro generovani referencni dokumentace a 
tvori s ni jeden celek.

Dokumenaci samozrejme neni potreba tisknout, chranme nase stromy :)

4) Doporucuji projit si znovu slajdy z uvodniho cviceni, abyste si 
pripomneli, podle jakych kriterii budeme Vase semestralky hodnotit. 
Verim, ze nektere veci z tech slajdu Vam teprve ted budou davat smysl.

http://d3s.mff.cuni.cz/~ceres/sch/osy/download/20111004-NSWI004-Agenda.pdf

Velmi strucne shrnuji:

* Pruchod testy jiz neni nutna podminka, ale pouze jedno z kriterii pro
   hodnoceni rozsireneho zadani (zapocitava se do kvality implementace).
   Presto je vhodne, aby Vase finalni reseni proslo idealne vsemi testy
   vsech zakladnich zadani a pripadne i testy rozsireneho zadani,
   jsou-li k dispozici.

* Kvalita zdrojovych kodu ma stejnou vahu jako funkcnost a kvalita
   dokumentace. Snazte se tedy o to, aby odevzdavane zdrojaky byly
   prehledne, upravene, vhodne komentovane, konzistentni, bez
   zakomentovanych "marnych pokusu", pomocnych ladicich funkci atd.

* Snazte se take dodrzet pozadavky na pouziti vhodnych programatorskych
   prostredu, tedy vhodnou volbu algoritmu a datovych struktur
   (predevsim z hlediska efektivity pro nejtypictejsi pripad pouziti v
   danem kontextu), vhodne oddeleni ruznych urovni abstrakce v kodu atd.

* Rucne psana dokumentace je v zasade nezbytna. Mela by popisovat
   obecne vlastnosti Vaseho reseni, celkovou architekturu, pouzite
   algoritmy z "high-level" pohledu, mela by informovat ctenare o tom,
   kde ve zdrojovych souborech nalezne jejich konkretni implementace
   atd. Soucasti hodnoceni dokumentace je samozrejme i Vase drivejsi
   ustni prezentace na cviceni.

   Doplnujici je referencni dokumentace. Aby byla referencni
   dokumentace vubec k necemu uzitecna, musi byt v kodu dusledne
   pouzivany dokumentacni komentare a to u vsech dulezitych entit
   (souboru, datovych typu, globalnich promennych, funkci, maker atd.).
   Neni mnoho horsich veci nez "derava" referencni dokumentace, ktera
   obsahuje popis jen poloviny veci ze zdrojaku.

* Pokud je soucasti Vaseho rozsireneho zadani take povinnost vypracovat
   nejake porovnani, je potreba vysledky (tabulky, grafy) uvest v
   dokumentaci a je potreba pripojit Vas slovni komentar nebo
   vyhodnoceni (tedy nestaci jen surova data bez dalsiho zpracovani).

5) Pokud jste v ramci Vaseho reseni implementovali neco nad ramec zadani 
nebo pouzili nejaky mimoradne zajimavy postup, urcite je vhodne uvezt to 
v dokumentaci -- i pri podrobnem prochazeni zdrojaku muze totiz hezka 
myslenka snadno zapadnout.

Plati to ovsem i obracene: Pokud vite, ze jste neco ze zadani nestihli 
nebo neco nechodi tak, jak by melo, uvedte to v dokumentaci. Pomuze nam 
to lepe ohodnotit rozsah takoveho "problemu" a lepe poznat, zda to, co 
vidime ve zdrojaku, je jen nedokonceny pokus o implementaci a ne neco, o 
cem si chybne myslite, ze by vlastne melo fungovat.


V pripade libovolnych nejasnosti, dotazu nebo pripominek prosim 
nevahejte vyuzit tuto konferenci. Preji vsem hodne zdaru pri odevzdavani!


M.D.