[OSy] Informace k odevzdani semestralek

[Martin Decky]

Vazeni kolegove,

vzhledem k tomu, ze datum pro definitivni odevzdani semestralnich praci 
z OSu se rychle blizi, posilam nekolik informaci pro pripomenuti a 
upresneni:


a) Deadline pro odevzdani je nedele 21. unora 2010. O pulnoci musi
    repository obsahovat vsechno, co chcete, aby bylo hodnoceno, tedy
    funkcni zdrojove kody, rucne psanou dokumentaci, funkcni skript pro
    vygenerovani referencni dokumentace atd.

    Az na oduvodnene vyjimky nebudeme akceptovat zadne dalsi materialy
    commitnute do Vaseho repository pozdeji nebo odevzdane extra.
    Dokumentaci neni potreba tisknout.


b) Upozornuji, ze nedele 21. unora 2010 je take termin pro odevzdani
    milestone vyberovych zadani (nejsme-li explicitne domluveni na jinem
    datu). V takovem pripade zaslete vse potrebne na muj email.

    Pod terminem "milestone" se rozumi primerene mnozstvi kodu,
    dokumentace a podobnych zalezitosti, ze ktereho je patrne, ze na
    zadani aktivne pracujete a postupujete kupredu spravnym smerem.
    Nemusi se jednat o reseni na urovni betaverze, ale zaroven by to
    melo byt neco vic nez jen soubor trivialit, ktere lze "spichnout" za
    par hodin. Milestone by mel predstavovat neco, co se "da spustit",
    tedy ne jen slovni specifikaci.


c) Soucasti udevzdani semestralek i milestonu vyberovych zadani je take
    osobni predvedeni, ktere zabere typicky 20 - 30 minut na jednu
    skupinu. Behem predvedeni se Vam pokusime take rict priblizny odhad
    bodu, ktere pravdepodobne za sve reseni dostanete. Presne bodove
    ohodnoceni dostanete potom v nasledujicich tydnech pote, co Vase
    reseni dukladne prostudujeme.

    Prosim, bude-li to jen trochu mozne, prihlaste se pro predvedeni na
    jeden z techto casovych slotu v pondeli 22. 2.

    10:00
    10:30
    11:00
    11:30
    12:00
    12:30
    13:00
    13:30

    Pokud Vam ani jeden z techto casu nevyhovuje, muzeme se domluvit na
    individualnim terminu.


d) Pokud vite o nejake vazne okolnosti, ktera Vam zasadne brani
    dodrzet termin odevzdani, dejte nam zavcas vedet. Za objektivni
    duvod pro odlozeni terminu odevzdani povazujeme napriklad delsi
    nemoc clena tymu (musi byt dolozena neschopenkou od lekare) a
    podobne.


e) Doporucuji znovu se podivat na slajdy z uvodniho cviceni pro
    pripomenuti kriterii, podle kterych budeme semestralky hodnotit.
    Myslim, ze nyni muzete diky nabytym zkusenostem lepe chapat nektere
    poznamky, ktere Vam nemusely byt na zacatku semestru zcela jasne.

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

    Velmi strucne shrnuto:

    * 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 odevzdavany kod byl
      prehledny, upravy, vhodne komentovany, konzistentni 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), vhodne oddeleni ruznych urovni
      abstrakce v kodu atd.

    * Dokumentace je potreba v zasade dvojiho druhu. Nezbytkou je rucne
      psana dokumentace popisujici vlastnosti reseni, celkovou
      architekturu, pouzite algoritmy z pohledu "z prvniho patra",
      informujici ctenare o tom, kde ve zdrojovych souborech nalezne
      implementovane ktere casti apod. Soucasti hodnoceni teto
      dokumentace je i Vase drivejsi ustni prezentace na cviceni.

      Doplnujici je referencni dokumentace, tedy dokumentace
      vygenerovana automaticky primo ze zdrojovych kodu. Aby byla tato
      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.

      Obe casti dokumentace neni nutne striktne oddelovat. Naopak je
      vhodne vyuzit nastroj pro generovani referencni dokumentace k
      propojeni obou casti (rucne psana i referencni dokumentace by mela
      byt idealne provazana hyperlinky).

    * Pokud je soucasti Vaseho rozsireneho zadani take povinnost
      vypracovat nejake porovnani, je potreba vysledky (tabulky, grafy,
      slovni komentar) uvest v dokumentaci. Nestaci, ze jste meli
      vysledky v prezentaci.

    * Je asi take jasne, ze rucne psana dokumentace je to spravne misto
      pro explicitni uvedeni faktu, ze jste ve Vasem reseni
      implementovali neco nad ramec zadani. (Pokud nam to reknete jen
      ustne pri predvadeni, hrozi, ze na to zapomeneme a v kodu to
      prehledneme.)


f) Prakticka poznamka: Pokud pouzivane nastroj pro generovani referencni
    dokumentace (napr. Doxygen), tak prosim do repository necommitujte
    vystup tohoto nastroje v podobe tisicu malinkych HTML souboru a
    obrazku. Zbytecne to zdrzuje pri checkoutu a pritom smysl generovane
    dokumentace je prave v tom, ze ji lze vzdy vygenerovat.

    Pokud opravdu nutne chcete mit v repository vystup z dokumentacniho
    nastroje, pouzijte nejaky kompaktni format (napr. PDF).


Pokud jsem snad na neco zapomnel nebo mate nejakou nejasnost ci dotaz 
tykajici se odevzdavani nebo hodnoceni, prosim nevahejte vyuzit tento 
mailing list k polozeni dotazu.

Preji hodne zdaru pri dokoncovani Vasich reseni!


M.D.