
Společná část zadání projektu ISA
Vytvořte komunikující aplikaci podle konkrétní vybrané specifikace pomocí síťové knihovny BSD sockets (pokud není ve variantě zadání uvedeno jinak). Projekt bude vypracován v jazyce C/C++. Pokud individuální zadání nespecifikuje vlastní referenční systém, musí být projekt přeložitelný a spustitelný na serveru merlin.fit.vutbr.cz pod operačním systémem GNU/Linux. Program bude přenositelný. Hodnocení projektů může probíhat na jiném počítači s nainstalovaným OS GNU/Linux, včetně jiných architektur než Intel/AMD, distribucí či verzí knihoven. Pokud vyžadujete minimální verzi knihovny (dostupnou na serveru merlin), jasně tuto skutečnost označte v dokumentaci a README.

Varianty zadání projektu

    Varianty zadání projektu jsou uveřejněny v systému IS VUT. Přihlašování na varianty bude možné přes IS VUT od 19.9.2025 do 3.10.2025.
    Konzultace k zadání bude probíhat přes fórum v systému Moodle, viz níže.


Pokyny k odevzdání projektu

    Vypracovaný projekt uložený v archívu .tar a se jménem xlogin00.tar odevzdejte elektronicky přes IS VUT. Soubor nekomprimujte.
    Termín odevzdání je 17.11.2025 (hard deadline). Odevzdání e-mailem po uplynutí termínu, dodatečné opravy či doplnění kódu nejsou možné.
    Odevzdaný projekt musí obsahovat:
        soubor se zdrojovým kódem - dodržujte jména souborů uvedená v konkrétním zadání, v záhlaví každého zdrojového souboru by mělo být jméno autora a login,
        funkční Makefile pro překlad zdrojového souboru,
        dokumentaci ve formátu PDF (soubor manual.pdf), která bude obsahovat uvedení do problematiky, návrhu aplikace, popis implementace, základní informace o programu, návod na použití, popis testování aplikace a výsledky testů. Struktura dokumentace odpovídá technické zprávě a měla by obsahovat následující části: titulní stranu, obsah, logické strukturování textu včetně číslování kapitol, přehled nastudovaných informací z literatury, popis zajímavějších pasáží implementace, použití vytvořených programů a literatura. Pro dokumentaci je možné použít upravenou šablonu pro bakalářské práce.
        soubor README obsahující jméno a login autora, datum vytvoření, krátký textový popis programu s případnými rozšířeními či omezeními, příklad spuštění a seznam odevzdaných souborů,
        další požadované soubory podle konkrétního typu zadání. 
    Pokud v projektu nestihnete implementovat všechny požadované vlastnosti, je nutné veškerá omezení jasně uvést v dokumentaci a v souboru README.
    Co není v zadání jednoznačně uvedeno, můžete implementovat podle vlastního uvážení. Zvolené řešení popište v dokumentaci.
    Při řešení projektu respektujte zvyklosti zavedené v OS unixového typu (jako je například formát textového souboru).
    Vytvořené programy by měly být použitelné a smysluplné, řádně okomentované, formátované a členěné do funkcí a modulů. Program by měl obsahovat nápovědu informující uživatele o činnosti programu a očekávaných parametrech. V případě neočekávaného vstupu by měl  vypsat chybové hlášení, případně help.
    Aplikace nesmí v žádném případě skončit s chybou SEGMENTATION FAULT ani jiným násilným systémovým ukončením (např. při dělení nulou).
    Před odevzdáním svůj program důkladně otestujte, viz návod níže. Výsledky experimentů (spuštění aplikace s různými parametry) by měly být součástí dokumentace.
    Pokud přejímáte krátké pasáže zdrojových kódů z různých tutoriálů či příkladů z Internetu (ne mezi sebou), tak je nutné vyznačit zřetelně vyznačit převzaté části v kódu a uvést jejich autory dle autorského zákona vč. uvedení licenčních podmínek, kterými se distribuce daných zdrojových kódů řídí. V případě nedodržení bude na projekt nahlíženo jako na plagiát. 
    Za plagiát se považuje i kód, který byl vygenerován externím nástrojem a kde student není autorem kódu ve smyslu autorského zákona. To zahrnuje i různé generátory kódu typu ChatGPT. Student není hodnocen za kód, který vytvořil někdo jiný (osoba či stroj).
    Konzultace k projektu podává vyučující, který zadání vypsal. Pro své otázky můžete využít diskuzní fórum k projektům.
    Sledujte fórum k projektu, kde se může objevit dovysvětlení či upřesnění zadání.
    Před odevzdáním zkontrolujte, zda projekt obsahuje všechny potřebné soubory a také jste dodrželi jména odevzdávaných souborů pro konkrétní zadání. Zkontrolujte před odevzdáním, zda je projekt přeložitelný na cílové platformě.


Hodnocení projektů

    Hodnocení projektu bude zveřejněno  v IS VUT.
    Maximální počet bodů za projekt je 20 bodů.
        Maximálně 15 bodů za plně funkční aplikaci.
        Maximálně 5 bodů za dokumentaci. Dokumentace se hodnotí pouze v případě funkčního kódu. Pokud kód není odevzdán, nefunguje dle zadání, jedná se o plagiát apod., dokumentace se nehodnotí.
    Příklad hodnocení projektů:
        nepřehledný, nekomentovaný zdrojový text: až -7 bodů
        nefunkční či chybějící Makefile: až -4 body
        nekvalitní či chybějící dokumentace: až -5 bodů
        nedodržení formátu vstupu/výstupu či konfigurace: -10 body
        odevzdaný soubor nelze přeložit, spustit a odzkoušet: 0 bodů
        odevzdáno po termínu: 0 bodů
        nedodržení zadání: 0 bodů
        nefunkční kód: 0 bodů
        opsáno: 0 bodů (pro všechny, kdo mají stejný kód), návrh na zahájení disciplinárního řízení. 

    Doporučení ověření funkcionality při řešení a před odevzdáním projektu:
        Zapnout a zkontrolovat varování překladače (volba -Wall).
        Ověřit práci s pamětí a striktní využívání inicializovaných proměnných a datových struktur - např. lze využít nástroj valgrind.
        Používání debuggeru pro ověření cest programu.
        Používejte další pomocné nástroje, které vám pomohou zobrazit komunikaci vašich programů. V závislosti na konkrétním zadání se může jednat např. o program Wireshark, dig, openssl a další specializované nástroje.
        Vytvoření opakovatelných a automatizovaných testů, které ověří, že nový kód nerozbije dříve napsané a ověřené části programu (např. testy jednotkové, integrační a systémové).
        Časté chyby v odevzdaných projektech zahrnují chybně použité regulární výrazy (často použité zbytečně). U každého regulárního výrazu (regexu) si položte otázky:
            Je v tomto místě vhodné a účelně regulární výraz použít?
            Pokud ano, je napsaný regex správně? (Např. v dřívějších letech se objevily regexy, které v URL vyžadovaly jen malá písmenka, zakazovaly některé povolené znaky, předpokládaly doménová jména o určitém počtu částí apod. Takové programy pak na testovaných URL nemusí vůbec fungovat.)
        Je odevzdaný soubor správně pojmenován?
        Je odevzdaný soubor správného typu a tedy na referenčním stroji rozbalitelný utilitou tar? (Vizte také man 1 file.).
        Je možné program přeložit programem make?
        Vytvoří program make správně pojmenovaný soubor v adresáři projektu.
        Funguje program na testovacích datech? Nekončí na nějaké chybě, nebo dokonce porušením ochrany paměti?
        Je v odevzdaném souboru přiložen soubor README a soubor s dokumentací?
        Jsou soubory s dokumentací, README a spustitelný program (výstup make) v kořenovém adresáři projektu, aby jej opravující nemusel hledat v podadresářích?
        Jsou všechny soubory správně pojmenované?
        Testují testy opravdu, že program pracuje správně?
        Je z dokumentace patrné, že rozumíte teorii, jak jste program navrhli, implementovali, otestovali a jaké byly největší a nejdůležitější problémy, které jste museli vyřešit? Pakliže se od zadání odkloníte (např. implementujete něco navíc, zadání ponechává volnost implementace), je toto patrné z dokumentace?