[OSy] Odevzdavani rozsireneho zadani

[Martin Decky]

Vazeni kolegove,

protoze se pro vetsinu skupin pomalu blizi termin dokonceni rozsireneho 
zadani semestralky z OSu, rad bych Vas poprosil, abyste mi napsali, 
jakmile budete mit hovoto, abychom se domluvime na konkretnim case 
osobniho odevzdani Vaseho reseni.

Behem osobniho odevzdani projdeme stav Vaseho repository (k terminu 
dokonceni) a dozvite se hruby odhad bodoveho hodnoceni. Finalni podrobne 
ohodnoceni obdrzite v nasledujicich tydnech po odevzdani, jakmile Vasi 
praci dukladne prostudujeme.

Zaverem strucne nekolik rad k zaverecnemu odevzdavani:

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 schvalene vyjimky).

2) Jako obvykle pri odevzdavani dila tohoto rozsahu je dobre 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 rozhodne nebude binarni.

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

4) 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 verzovat a jednak to repository zbytecne 
zvetsuje. Bohate postaci, kdyz bude mozne referencni dokumentaci snadno 
ze zdrojoveho stromu vygenerovat.

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

6) Pripominam, ze 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.

7) Dokumenaci samozrejme neni potreba tisknout, chranme nase stromy :)

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

http://d3s.mff.cuni.cz/teaching/operating_systems/download/20131003-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
   prostredku, 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) zahrnout do
   dokumentace a je take potreba pripojit Vas slovni komentar nebo
   vyhodnoceni (tedy nestaci jen surova data bez dalsiho zpracovani).

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

10) Plati ovsem totez i obracene: Pokud vite, ze jste neco ze zadani 
nestihli nebo neco nechodi tak, jak by melo, uvedte to prosim 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 napsat do teto konference. Preji vsem hodne zdaru pri odevzdavani!


M.D.