Často kladené otázky (FAQ) k projektu z IPP

• IPP Fórum 2009
• IPP Fórum 2008
• Oficiální stránky IPP

• Proč nemohu vypracovávat projekt sám místo v týmu?
  • Stručně řečeno, protože to neodpovídá záměru projektu, kde se v IPP hodnotí hlavně týmová práce (např. skrz projektovou dokumentaci). Dalším důvodem týmového projektu je část každé přednášky věnovaná problémům týmové spolupráce v aktuálně probíraném typu programovacích jazyků. Technicko-organizačním důvodem je také počet studentů, jejichž projekt je potřeba manuálně opravovat. Samostatné týmy chtějí navíc nejčastěji lidé, kteří již IPP opakují a většinou již projekt neúspěšně absolvovali a těm nemáme v úmyslu vycházet vstříc, když stejné podmínky nemůžeme zajistit všem studentům předmětu. Další důvodem je to, že v dnešní době jen velmi málo komerčních projektů vznikají jako dílo jednoho programátora ale téměř vždy musíte pracovat týmově a proto je tato dovednost důležitou součástí vašeho vzdělání.

Nejdůležitější fakta k zadání projektu z IPP na ak. rok 2008/2009:

• Plný text zadání projektu je na privátních stránkách předmětu.
• Zadaní bude zveřejněno na konci 3. týdne letního semestru .
• Termín odevzdání je do 29. 4. 2009 včetně (do půlnoci):
  • Pozdní odevzdávky nejsou povoleny (v IPP hodnoceno 0 body).
  • Pokud bude v semináři schválena nějaká výjimka či dodatečné posunutí termínů (hromadné nebo individuální), tak na to nebude v IPP brán zřetel (a následky mohou být v IPP fatální).
• Každý tým by měl ideálně obsahovat 4 studenty. Týmy se tvoří v seminářích.
• Nástin hodnocení jednotlivých částí je v zadání projektu a částečně také v následujících odpovědích (FAQ však není závazné; FAQ obsahuje spíše doporučení a rady).
• Odevzdavá se do IS do předmětu vašeho semináře (kromě lidí, kteří nemají zapsaný seminář, viz dotaz níže).

• Při komunikaci přes e-mail vždy používejte školní email. Pokud Vám nefunguje pop3 nebo imap, je tu vždy k dispozici webové rozhraní školní elektronické pošty.
• Vyplňujte předmět zprávy, kde bude na začátku řetězec “IPP:”
• Píšete-li za tým (nejčastější případ), tak jasně uvádějte, kdo je vedoucí týmu (jméno i login)
• Neřešte vše na poslední chvíli. Těsně před termínem je v časovém presu i učitel, který je pak méně ochoten (nebo dokonce nemůže) vám pomoci.

• Implementace skriptu a části dokumentace je povinná pro uznání projektu (viz korelační funkce v zadání projektu).
• Není povolena slovenština (U nečeských a neanglických dokumentací bude následovat stržení 10-15% bodů za jazykovou nesprávnost).
• Změna podmínek pro uznávání projektů z minulých let.

1. Komu mám napsat dotaz ohledně projektu z IPP?
   • Opravování projektů má na starosti Zbyněk Křivka.
   • Máte-li obecnější dotaz, který by mohl zajímat i ostatní studenty, využijte fórum předmětu!
2. Jaké jsou podmínky pro uznání bodů z projektu IPP z minulého roku, pokud IPP opakuji?
   • Projekt musel být vypracován v ak. roce 2007-2008 (tj. ne uznán, ale vypracován).
   • Student musel získat alespoň 16 bodů.
   • V době přihlašování na projekt, respektive do týdne (tj. do 2. 3. 2009) od jeho vyhlášení pošlete e-mail s žádostí na mail kolar@fit.vutbr.cz (dodržet správnou formu e-mailu, tj. začátek předmětu zprávy je “IPP:”, posláno ze správného školního mailu).
   • V případě splnění všech těchto podmínek vám budou body do IS zapsány spolu s ostatními na konci semestru.
3. Mám zapsané IPP, ale nemám zapsaný žádný seminář (např. student opakuje IPP, ale seminář již úspěšně zvládl):
   • Zde jsou 4 teoretické možnosti a kombinace, které jsou ošetřeny v podstatě stejně:
     1. Všichni v týmu mají zapsané IPP i seminář (standardní situace, ve které pravděpodobně dotazovaný není).
     2. Všichni v týmu mají zapsané IPP, ale jen někteří mají seminář. Řešení projektu i jeho opravení probíhá jako v bodu (I), ale některým (těm, co nemají seminář) v semináři body propadnou na oltář výuky.
     3. Všichni v týmu mají seminář, ale jen někteří mají IPP. Opět dle bodu (I), jen propadají body v IPP a ne v semináři analogicky jako v bodě (II).
     4. Nikdo nemá zapsaný seminář, všichni mají jen IPP. Opět dle bodu (I), t.j. projekt řeší jako by měli zapsaný seminář (tato situace je výjimečná a upozorněte na ni Zbyňka Křivku). V této variantě se pouze liší způsob odevzdání, který se provádí do IPP a ne do semináře (viz níže).
   • Ani jedna situace se tedy neřeší individuálním zadáním.
4. Tým mě zradil. Co mám dělat?
   • Nefunkčnost týmu lze hlásit nejpozději do konce března, když už musíte mít jasno, jestli spolupráce funguje nebo ne. V případě, že se Vám rozpadne tým a byl(a) byste na řešení sám(sama), dejte vědět na krivka@fit.vutbr.cz a situaci budeme operativně řešit (individuální zadání, ad-hoc vytvoření náhradního týmu apod.). Řešení problému s týmem během dubna je také ve vašem zájmu, ale již nemůžeme zaručit, že Vám budeme schopni pomoci. Oznámení o nefunkčnosti týmu týden (a méně) před odevzdáním se považuje za provokaci a bude ignorováno. Tým je považován za rozpadlý, pokud z něj hodlá odevzdat pouze jediný člověk (ostatní vzdali).
5. IPP opakuji a nemám za projekt dost bodů na zápočet.
   • Pokud s některou částí bodování nesouhlasíte a jste objektivně přesvědčení, že jsme něco přehlédli (týká se částí opravovaných v IPP, nikoli v semináři), zkuste se zastavit ve vypsaných reklamačních hodinách k člověku, který vám projekt opravoval (uvidíte u hodnocení projektu). U reklamací a konzultací k hodnocení projektu může být přihlédnuto k dosavadnímu studijnímu průměru studenta.

1. Jak je projekt z IPP hodnocen?
   • Hodnocení se skládá ze dvou částí:
     1. procentuální hodnocení za projekt ze semináře (0 až 100%);
     2. hodnocení části IPP (0-20 bodů, resp. maximum 25 bodů včetně bonusových bodů).
   • Nad těmito parametry je potom proveden výpočet výsledného počtu bodů pomocí korelační funkce ze zadání projektu.
   • Zkorelovaný výsledek je nakonec rozdělen jednotlivým studentům podle zadaného rozdělení v týmu.
2. Jak byl projekt hodnocen (IPP části bez korelace a bez případných bonusových bodů za nadprůměrné řešení)?
   • Skript až 4 body
   • Dokumentace projektová a implementační až 6 bodů
   • Dokumentace programová (generováná) až 5 bodů
   • Dokumentace uživatelská (nápověda) až 5 bodů
3. Proč mám stržené body za slovenskou dokumentaci?
   • V zadání je jasně řečeno, že umožňujeme psát dokumentaci buď v češtině nebo v angličtině a v žádném jiném jazyce. Je to z důvodu, že u slovenštiny nemůžeme posoudit jazykovou stránku textu a znevýhoďnovali bychom česky a anglicky píšící studenty. Za slovenskou dokumentaci bude strženo asi 10-15% bodů z dané dokumentace, tj. jako by obsahovala velké množství jazykových chyb v češtině nebo angličtině.
   • Neboť jste na území České republiky, kde je úředním jazykem jazyk český (viz např. http://www.hrad.cz/cz/ceska_republika/index.shtml), tak vyučujeme primárně v češtině. Jazyk anglický je umožněn mimojiné proto, že zahraničním studentům je IPP nabízen v angličtině a nechceme našim studentům odepřít možnost zdokonalit nebo využít svou znalost angličtiny, která je nepochybně jazykem informatiky jako takové. Dále dáváme možnost studentům, kteří neumí česky tak dobře, aby si troufli na tvorbu psaného textu. Proti slovenskému jazyku sami nemáme námitek, ale veškerá nedorozumění, která se mohou objevit, budou přičtena na vrub tvůrce. Navíc bohužel už slovenštinu neumíme natolik dobře, abych si troufl hodnotit jazykovou úroveň dokumentace (pravopis, stylistiku).
4. Diakritika v generované programové dokumentaci a v nápovědě skriptu:
   • Pokud budete psát komentáře, jež se využívají při generování programové dokumentace, česky, tak nebude postihováno, pokud chybí diakritika. Pro ostatní dokumenty to však neplatí a v případě zvolení češtiny bude chybějící diakritika hodnocena jako jazykový prohřešek.
   • Pro dokumentaci v HTML formátu a v češtině s diakritikou doporučujeme kódování UTF-8, ISO-8859-2 nebo Windows-1250 a to tak, aby se dokument správně zobrazoval na nejrozšířenějších prohlížečích (FireFox 3, Internet Explorer 7).
5. Míchání různých jazyků v dokumentaci
   • Zevrubně platí, že míchání angličtiny a češtiny v jedné dokumentace je považováno za chybu. Výjimku tvoří opět programová dokumentace, kde upřednostňujeme anglické identifikátory tříd a metod, ale komentáře je možno psát česky, ale potom všechny komentáře budou česky a všechna jména identifikátorů založena na angličtině (v tomto zůstává požadavek jazykové konzistence platný)!
   • Různé typy dokumentace mohou být psány různým jazykem (např. programová komplet anglicky a uživatelská může být komplet česky, ale opět platí, že v rámci jednoho typu dokumentace nelze jazyky bezdůvodně míchat).
6. Jak je aplikována korelační funkce pro získání celkových bodů za projekt do IPP?
   • Nejprve se kontrolují základní podmínky pro hodnotitelnost projektu v IPP
     1. nenulové body za implementaci (tj. procenta ze semináře)
     2. alespoň půl bodu (před korelací) získáných za skript a další bod za dokumentační složky projektu
   • Dále se aplikuje jádro korelační funkce:
     1. máte-li ze semináře více jak 114%, tak se koreluje o 14% menší hodnotou
     2. máte-li ze semináře mezi 114% a 90%, tak se koreluje bez úpravy těmito procenty
     3. máte-li ze semináře mezi 1% a 90%, tak se koreluje s přidáním 10%
   • Nakonec zaokrouhlíme výsledek na celé číslo (0 až 20 potažmo 25).

Dotazy k implementaci a dokumentaci projektu.

1. Máme skript nějak dokumentovat?
   • Kromě případných komentářů uvnitř skriptu doporučujeme napsat zmínku do projektové dokumentace (půl až celou stránku) a nezapomenout přehledně zmínit případné nadstandardní vlastnosti/schopnosti skriptu (např. propracovanější zpracování operátoru čárka, doplňující parametry skriptu, apod.).
   • Nápověda skriptu (parametr –help) může být napsána v případě češtiny bez diakritiky.
2. Máme na vstupu očekávat syntakticky správně zapsané programy v jazyku? Nebo lze očekavat zdrojove soubory s chybami?
   • Všechny testované zdrojové texty jsou správné v daném jazyce. Předpokládá se, že programovací jazyk analyzovaný skriptem bude odpovídat jazyku, ve kterém byla implementována hlavní část projektu (tj. Java pro IJA a C++ pro ICP).
3. Pokud cesta se jménem souboru bude příliš dlouhá (více než 80 znaků), má se při výpisu oříznout nebo je délka řádku neomezená?
   • Délka řádku není při výpisu nijak omezena.
4. Vyhledávat u parametru -w všechny podřetězce nebo jen celá slova (tj. hledané slovo je z obou stran doplněno o libovolný nepísmenný znak), případně hledat i překrývající se výskyty hledaného slova?
   • Je to na vás. Vaši volbu zapište do dokumentace. Vyhledávejte CASE-SENSITIVE stylem. Doporučujeme nepřekrývající vyhledávání.
5. Co s direktivami preprocesoru, které začínají #? Např. #define DVESTA 200 … je DVESTA identifikátor?
   • Z pohledu preprocesoru je to identifikátor, na rozdíl třeba od direktivy #include, která má jako parametr jméno souboru (tedy řetězec, např. 123.h).
6. Jak zpracovávat ternární operátory (např. ?:)
   • Operátor ?: by se měl počítat jako jeden operátor, ale kvůli jednoduchosti skriptu nebudou základní testy příliš náročné (např. bez zanořování ternárních operátorů do sebe).
7. Co považujeme za operátor?
   • Libovolný operátor daný dopředu známou a fixní posloupností nepísmenných znaků.
   • Takže mezi operátory v našem skriptu nepočítáme např. new, delete, sizeof, instanceof
8. Jak pracovat s operátory . a ,?
   • Snažte se o dobrý poměr kvalita spočtených operátorů versus náročnost implementace. Netriviální řešení zmiňte v projektové dokumetaci.
9. Hvězdička v Javě (Např. 3 * 4 nebo import balicky.*)
   • Zamyslete se, jak je dále zpracována hvězdička (*) v obou příkladech. Kdy je hvězdička operátor a kdy jiný syntaktický prvek jazyka?
10. Má se u přepínače -c (vypsání délky poznámek v bytech) u řádku s komentářem k celkovému výsledku přičítat i znak nového řádku uvnitř komentáře?
    • U víceřádkových komentářů započítat všechny konce řádků uvnitř komentáře. U komentářů do konce řádku započítat i konec řádku. Konec řádku počítejte jako jeden byte (Pozor: na Windows je to dvojznak, na Linuxu a MAC OS jeden znak skutečně).