[OSy] Odevzdani 3. zakladniho a rozsireneho zadani

[Martin Decky]

Vazeni kolegove,

blizi se datum 18. 1., tedy standardni termin pro odevzdani 3. 
zakladniho zadani semestralek z OSu. Po tomto terminu bude nasledovat 
standardne 5 tydnu pro dokonceni rozsireneho zadani a odevzdani cele 
semestralky.

Vetsina skupin ma vsak harmonogram odevzdavani nejak individualne 
posunuty. Proto posilam informace uz nyni s predstihem a prosim 
necekejte, az Vam terminy vyprsi a nekdo Vas kontaktuje, ale v okamziku, 
kdy Vase semestralka jiz bude pripravena na odevzdani 3. zakladniho nebo 
rozsireneho zadani, tak naopak kontaktujte me a dohodneme se na 
konkretnim datu odevzdani.

Odevzdani 3. zakladniho zadani bude probihat stejnym zpusobem jako v 
pripade predchozich zakladnich zadani. Verim tedy, ze nemusim podrobne 
instrukce jiz opakovat.

Odevzdani rozsireneho zadani bude probihat osobne (tj. za pritomnosti 
alespon jednoho clena resitelskeho tymu). Behem osobniho odevzdani 
projdeme spolecne stav Vaseho repository (k dohodnutemu terminu 
dokonceni) a dozvite se hruby odhad bodoveho hodnoceni. Finalni podrobne 
hodnoceni obdrzite pote behem nekolika tydnu, jakmile Vasi praci 
dukladne prostudujeme a take kvalitativne porovname s vysledky ostatnich 
skupin.

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, ale budeme
    prihlizet k ruznym aspektum.

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

4) Pokud pouzivate nejaky nastroj na 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) Pokud naopak 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 v zadnem pripade potreba tisknout.
    Setreme nase lesy :)

8) Doporucuji, abyste si dukladne znovu prosli slajdy z uvodniho
    cviceni a pripomneli si, podle jakych kriterii budeme Vase
    semestralky hodnotit. Troufam si tvrdit, ze teprve nyni docenite
    smysl a vyznam nekterych poznamek ze slajdu:

 
http://d3s.mff.cuni.cz/teaching/operating_systems/download/20141006-nswi004-agenda.pdf

    Velmi strucne shrnuji zakladni kriteria:

    * Pruchod testy neni pro rozsirene zadani nutna podminka hodnoceni,
      ale stale jde o jedno z kriterii pro hodnoceni Vasi semestralky
      (zapocitava se do kategorie kvalita implementace). Proto 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 a
      dalsich "estetickych" nedokonalosti.

    * 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.

    * Kvalitni 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 konkretni
      implementace atd. Snazte se vyuzit pravidla, ze jeden obrazek
      muze nahradit 1000 slov. Soucasti hodnoceni dokumentace je
      samozrejme i Vase drivejsi ustni prezentace na cviceni.

    * Referencni dokumentace ma doplnujici roli. Aby vsak byla referencni
      dokumentace vubec k necemu uzitecna, musi byt v kodu dusledne
      a vsude pouzivany dokumentacni komentare a to u vsech dulezitych
      entit (souboru, datovych typu, globalnich promennych, funkci,
      maker atd.). Neni mnoho zbytecnejsich veci nez "derava" referencni
      dokumentace, ktera obsahuje popis jen casti veci ze zdrojaku.

    * Pokud je soucasti Vaseho rozsireneho zadani take povinnost
      vypracovat nejake mereni/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 a interpretace).

9) Pokud jste v ramci Vaseho reseni implementovali neco nad ramec
    zadani nebo pouzili nejaky zajimavy postup, urcite se nebojte
    pochlubit se v dokumentaci -- i pri podrobnem prochazeni zdrojaku
    muze totiz hezka myslenka zapadnout, coz by byla jiste skoda.

10) Plati to i obracene: Pokud vite, ze jste neco ze zadani nestihli,
     neco jste trochu "osidili" nebo neco nechodi tak, jak by melo,
     uvedte to prosim v dokumentaci. Pomuze nam to lepe zhodnotit rozsah
     takoveho "problemu" a lepe poznat, zda to, co vidime ve zdrojaku,
     je vedomne nedokoncena implementace 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.