Programování v jazyce C#

[in English] This page contains information for czech students of the Programming in C# Language course. For english, switch the language in the page header.

Náplň přednášek

1. přednáška

• Představení předmětu • materiály • příklady na rozehřátí • checked blok • překlad C# programu & assembly & CLR & CIL kód & metadata • ildasm.exe • ilspy.exe • mscorlib.dll

2. Přednáška

• Base Class Library • vlastní class library (.dll assembly) • .NET Framework & Mono & … • Sysinternals: Process Explorer • on-demand DLL loading & FileNotFoundException • přehled jazyků pro .NET • pravidla C# vs. pravidla CLR • ilasm.exe: C# → CIL → CIL assembler → CIL • verifiable vs. unverifiable kód • peverify.exe • srovnání s C# safe vs. unsafe kód

Doporučená literatura

• Mark Michaelis with Eric Lippert: Essential C# 5.0, Addison-Wesley, 2013 (lze koupit např. na Amazon UK)
• Jeffrey Richter: CLR via C# (4^th Edition), Microsoft Press, December 2012 (lze koupit např. na Amazon UK)
• Jon Skeet: C# in Depth (3^rd Edition), Manning Publications, September 2013 (lze koupit např. na Amazon UK)
• blog Erica Lipperta (bývalý člen C# týmu v Microsoftu): Fabulous Adventures In Coding
• C# Language Specification 5.0

Případně

• Christian Nagel, Evjen, Jay Glynn, Karli Watson, Morgan Skinner: Professional C# 4.0 and .NET 4, Wrox, John Wiley & Sons, March 2010 (lze koupit např. na Amazon UK

Náplň cvičení

1. Cvičení

• Informace o předmětu, podmínky zápočtu, Slidy
• Připomenutí práce s Visual Studio (2019)
  • Vyrobení projektu (.NET Framework / .NET Core), struktura projektu
  • Konfigurace, Intellisense, Bloková selekce, Dokumentační komentáře, Odsazení
  • Překlad, Spuštění, Debugging (základy)
• Zadání úloh Počítání slov a Četnosti slov
  • System.IO.StreamReader
  • String.Split
  • Array.Sort, List<T>.Sort
  • (Sorted)Dictionary<K, V>

2. Cvičení

• Čtení slov ze souboru:
  • ✖ StreamReader.ReadToEnd (problém s velkými soubory)
  • ✖ StreamReader.ReadLine (problém s dlouhými řádkami)
  • ✔ StreamReader.Read (po znacích)
    • Vrací int (extra -1 v rozsahu jako identifikace konce souboru)
    • Konverze do char přes standardní přetypování (char), ale až po kontrole == -1 konce souboru
• Kontrola existence souboru, a faktu jestli se dá otevřít/číst jenom pomocí výjimek z konstruktoru třídy StreamReader
  • File.Exists není dostatečné, když v je v systému více processů s přístupem k filesystému
• Problémy se zachytáváním příliš velkého rozsahu výjimek (catch (Exception) schová OutOfMemoryException)
• Počítání slov
  • Analýza SortedDictionary vs Dictionary vs SortedList vs Vlastní DS
  • Záleží na poměru unikátních slov a všech slov v souboru
  • Micro benchmark
• Možné řešení, které separuje koncepty čtení ze souboru a zpracovávání dat (slov v tomto případě)
• Zadání úlohy Zarovnání do bloku
  • Jedna řádka už se do paměti nevejde

3. Cvičení

• Drobné komentáře k úloze zarovnání do bloku
• Nástroj diff (Command Line)
  • Grafické: KDiff3, Visual Studio Code
• Testování aplikací
• Integrační testy
• UnitTesty (MSTest, xUnit, NUnit, MSDN tutorials (.NET Core))
  • ArrangeActAssert
  • Mock-up
  • Příklad testů pro WordReader: ProgramTests s Mock-upy, WordReaderTests, Kompletní projekt pro .NET Core 3.1
• Nová úloha Vícesouborové zarovnání
  • Rozšíření předchozí úlohy
  • Za 5 bodů
  • Extra 5 bodů nad rámec za rozumné UnitTesty
  • UnitTesty je třeba odevzdat v separátním souboru a zakomentované (/* ... */, případně #if ... #endif), aby to ReCodEx nepřekládal (nemá reference na unit testovací framework)

4. Cvičení

• Ukázka špatných unit testů jako integračních testů (místo testování kombinací vstupů jedné metody se testuje kombinace vstupů kombinací metod v mainu)
• Testování “zbytků” (glue-code)
  • Separátní metoda Run která může dostat upravené argumenty
  • Testování Console přes použití Run(TextWriter) (z Mainu se dá volat jako Run(Console.Out))
• Jmenné konvence
  • class MyClass, void MyMethod, namespace MyNamespace, stejně také veřejné položky
  • interface s prefixem I (IMyInterface), výjimka se suffixem Exception (InvalidRequestException)
  • lokální proměnné, neveřejné položky, argumenty funkcí jako camelCase (privátní položky je možné i prefixovat podtržítkem _camelCase)
  • Jména zásadně anglicky
  • Zkratky používat jen lokálně a jen zažité (str(ing), res(ult), char(acter), val(ue))
  • Skutečné zkratky v kódu pouze první písmeno velké (HttpRequest, XmlElement), pokud nemá zkratka pouze dvě písmena, pak obě velké (IOException)
• Komentáře k zarovnávání do bloku
  • Základní verze s privátními metodami pro tisknutí zarovnaného textu (nelze unit testovat)
  • Pokročilá verze se separátním ILineJustifier, který zároveň vede na hezký highlighting pomocí IStringWriter, z čehož vznikne adaptor a wrapper design pattern.
  • Zpracovávání více souborů pomocí návrhového vzoru factory
• Pohled zákazníka na programátora z videa The Expert (Short Comedy Sketch)
• Nová úloha Internetové knihkupectví
  • Zkusit využít návrhový vzor ModelViewController (MVC)

5. Cvičení

• Pohádka O hledání bugu aneb jak je důležité se dívat na specifikaci a ne na kód (s tím související Heartbleed bug v OpenSSL)
• Ukázkové řešení internetového knihkupectví
• Nová úloha Huffman I
  • Strom je třeba mít uložený v paměti v nějaké objektové reprezentaci. Nestačí jej postupně tisknout.

6. Cvičení

• Komentáře k úloze Huffman I
  • Uvědomění si, kde je kladen důraz na výkon (čtení souboru nebo stavění stromu)
  • Rozdíly mezi BinaryReader a FileStream, interní implementační detaily a možnost zefektivnění ještě dalším vlastním bufferováním (o velikosti 2ⁿ)
  • Přístupy k počítání frekvencí: Dictionary<byte, long> vs. new long[256] (int není dostatečně velký pro 1TiB soubory)
  • Reprezentace HuffmanTree: přímočarý přístup nebo více objektově orientovaný přístup
  • Stavění stromu: PriorityQueue (heap) vs. jednoduché dvě fronty (Queue) pro listové a vnitřní uzly, případně jeden setříděný seznam a postupné zatřiďování nových uzlů (částečně insert sort)
  • Tisknutí stromu: rekurze vs. explicitní Stack
  • Možné řešení
• Nová úloha Huffman II
  • Bitové operace v C#: or |, and &, xor ^, not ~, left shift << right shift >> (>> je závislé na znaménkovosti typu)
  • BinaryWriter
  • BitConverter, byte[] GetBytes(int), GetInt32(byte[]), …

7. Cvičení

• Komentáře k úloze Huffman II
  • Zase, uvědomění si, ve které části programu jde o výkon (čtení souboru vs. stavění stromu vs. čtení souboru podruhé vs. zapisování do souboru)
  • Jak generovat bitové sekvence
    • ✖ Jako string ("1011" + "0"), což alokuje novou paměť pro každou konkatenaci a musí kopírovat data z původních řetězců
    • ✖ Převod stringu na byte pomocí Convert.ToByte("10110", 2), což je univerzální algoritmus, který podporuje více soustav, než jen binární, kterou nativně podporuje procesor
      • Můžeme si konverzi udělat sami Hornerovou metodou a přidáváním (bitový or) hodnot
    • ✔ Pomocí bitových operací (or |, and &, xor ^, not ~, left shift << right shift >>)
  • Jak nastavit n-tý bit value na 1? Jako value | x, kde binární reprezentace x má samé nuly, kromě jedné 1 na n-té pozici (což je nějaká druhá mocnina)
    • ✖ Math.Pow(2, x) je zase univerzální funkce na mocniny, která podporuje i reálná čísla (tedy obecný algoritmus, neoptimalizovaný na mocniny dvojky)
    • ✔ 1 << x
  • Jak od-nastavit n-th bit (nastavit jej na 0) value? Jako value & x, kde binární reprezentace x má samé jedničky, kromě jedné 0 na n-té pozici, což je negace mocniny dvojky.
    • value & ~(1 << n)
  • Dává smysl si připravit cache kódů, abychom nemuseli znovu a znovu procházet strom
  • Možné řešení
  • Rozdíly mezi byte[] BinaryReader.ReadBytes(int lenght) a int FileStream.Read(byte[] buffer, int offset, int length), kde první možnost musí alokovat nový buffer, kdežto druhá možnost může opakovaně používat ten samý
• Použití symbolu @ před jménem je způsob, jak vyrobit identifikátor, se stejným jménem jako je klíčové slovo v C# (např. int @while nebo void @else()). verbatim identifier
  • Se hodí, při interakci s .NET jazykem L, ze kterého chceme použít identifikátor, který je rezervovaný v C#, ale ne v L
• Použití podtržítka v číselné konstantě jakožto oddělovat cifer pro čtenáře (např. int price = 12_751; nebo ulong bits = 0b10110010_10010101). digit separator
• Nástroje typu profiler v .NET, pro měření výkonu aplikace z pohledu CPU
  • Sampling (vzorkování)
    • Spustí program a v pravidelných intervalech jej zastavuje, aby se sebral vzorek — z ladících informací a instruction pointeru se dá vyčíst přesné místo v kódu, kde došlo k zastavení
    • Z těchto vzorků se vyrobí statistika s myšlenkou, že více vzorků na stejném řádku značí, že vyhodnocení řádku trvá nějakou dobu
    • Nefunguje pro sbírání vzorků z kódu OS (kernel), jako např. IO operace
    • Malý overhead, nepřesné, generuje statistická data
  • Instrumentace (instrumentation)
    • Modifikuje existující program tak, že na začátek a konec každé funkce se dá volání profileru, které může měřit přesný čas, jak dlouho funkce trvala
    • Tyto data jsou přesná (v rámci přesnosti měření, ale nejedná se o statistiku)
    • Může měřit dobu systémových volání (např. IO operace)
    • Obrovský overhead, přesné, generuje extrémní množství dat
  • Je nutné výstupy brát s rezervou
• Nová bonusová úloha Huffman III (s deadline v prvním týdnu letního semestru)
  • Huffman II naruby — Dekomprese
  • Nic nového, tudíž nekomentováno na cvičení a tedy s deadlinem až po zkouškovém
• Nová standardní úloha Excel
  • Nesnažte se za běhu vypisovat výstup, ale první načtěte list, ten vyhodnoťte, a pak až vypište do souboru
  • Nesnažte se podporovat vyhodnocování vzorců v jiném typu (např. v doublech)
  • Nesnažte se podporovat jiné druhy vzorců (funkce, více operátorů, konstanty)
  • Základní řešení dá pouze 80% bodů (12/15), pro 100% (15 bodů) je třeba naprogramovat i rozšíření

8. Cvičení

• Prodloužení deadline na Excel o jeden týden
• Rady jak se poprat s pamětí při řešení Excelu
  • Buňky mají různý obsah (13, =A1+B2, [], …). Je tedy logické, že budou v paměti reprezentované jinými typy
  • To automaticky šetří paměť, protože si každá buňka pamatuje jen to co potřebuje a ne sjednocení všeho (např. prázdná buňka si nepotřebuje pamatovat žádná data)
  • Zároveň to vede na hezký návrh, který je jednoduše rozšířitelný. Když budeme chtít pokročilejší vzorce, stačí přidat nový typ, a není nutné měnit chování jiných buněk.
  • Struktura sešitu v paměti by neměla být závislá na formátu vstupního souboru. Pokud se formát změní (např. budeme chtít podporovat .xls soubory Microsoftího excelu), tak nechceme měnit formát v jakém jsou data uložená v paměti.
  • Myslete na overhead datových struktur, které používáte. Např. overhead u Dictionary v použití Dictionary<string, Sheet> je téměř nulový, kdežto u Dictionary<string, int> je to několik set procent paměti navíc.
  • Pokud nemáte ukázkové vstupy, tak si nějaké vyrobte. Nebude těžké naprogramovat jednoduchý program, který vyrobí složitý dokument, který má desítky tisíc řádků nebo sloupců nebo vyžaduje vyhodnocení o tisících krocích.
• Conditional compilation
  • Možnost zařídit (ne)překládání části kódu v souboru v závislosti na jednoduché podmínce (např. pro ladění a produkci)
  • #define IDENT, #if IDENT, #else, #endif (tyto konstanty je možné definovat taky v nastavení projektu)
  • #warning, #error
• Task list ve visual studiu
  • Speciální klíčová slova v komentářích (HACK, TODO), které čte Visual Studio a zobrazuje je v Task List okně
• Úvod/Opakování nástrojů pro správu verzí (version control systems)
  • Archaické SVN s Local Working Directory (commit/update) Central Repository
  • Moderní Git/Hg s Local Working Directory (add/remove) Staging Area (commit/checkout) Local Repository (push/pull) Remote Repository
  • Ukázka použití Gitu z grafického nástroje (Tortoise Git) nebo přímo z Visual Studia
  • Jiné grafické nástroje: GitExtension (Windows, Git), SourceTree (Windows/Mac, Git/Hg)
  • Procvičení Gitu z příkazové řádky je možné v předmětu Nástroje pro vývoj software
• Nové bonusové úlohy (s deadline v prvním týdnu letního semestru)
  • Hradlové sítě, 30 bodů
  • Hradlové sítě II, 30 bodů
  • Hradlové sítě III, 40 bodů
  • Úlohy, které jsou jednoduché z pohledu algoritmu, ale velmi náročné na správné rozvrhnutí. Rozmyslet si správně strukturu programu je velmi důležité pro splnění těchto úkolů!
  • Příklad simulace hradlové sítě nad specifickým vstupem

9. Cvičení

• Excel Impossible
• Komentáře k řešení Excelu
  • Rozdíly ve využití paměti při ukládání hodnot jako int (1234) nebo string ("1234")
  • Různé druhy buněk jsou reprezentované různými typy (NumericCell : Cell, FormulaCell : Cell)
  • Rozdělení parsování souboru a jednotlivých algoritmů pro parsování různých typů buněk
  • Parsování referencí ve vzorcích
    • ✔ Hornerovo schéma
    • ✖ int.Parse; naparsuje také -10 nebo 00123
    • ✖ Regulární výrazy; špatně čitelné, těžkotonážní, parsování výrazu do automaty a pak obecný algoritmus na průchod automatem
    • Možné řešení
• Nová úloha Vyhodnocování výrazů
  • Výraz v prefixové formě je nutné naparsovat do nějakých rozumných datových struktur a pak až spustit vyhodnocovací algoritmus.
  • Důraz na rozšiřitelnost o nové operátory, funkce, …
  • Nesnažte se o řešení, které bude umět pracovat s libovolnými typy (double, string, komplexní čísla, zlomky). Výrazy budou vždy přirozená čísla (int).
  • Pro vyhodnocení použijte rekurzi, protože to pak vede na lepší design aplikace.
  • 5 bodů za testy v ReCodExu, dalších 5 bodů za vhodnou reprezentaci výrazů v paměti.

10. Cvičení

• Komentáře k řešení Vyhodnocování výrazů I
  • Reprezentace výrazů jako strom (což vede na jednoduchou manipulaci s pod-výrazy; Abstract Syntax Tree)
  • Použití klíčových slov sealed a abstract jako rady ostatním programátorům kde se má aplikace rozšiřovat/které typy se mají vyrábět. Zároveň to může použít i překladač pro nějaké micro-optimalizace
  • Nevýhody implementace pod-uzlů jako Expression[] array. Použití specifických tříd (BinaryOperator, …) s danou aritou
  • Specifické třídy PlusExpression, MinusExpression, … pro oddělení vyhodnocování výrazů a výpočtu hodnot
  • Parsování vstupu pomocí zásobníku ještě nedodělaných výrazů, což vyžaduje podporu v třídě Operator metodou AddOperand (která ale nerozbíjí immutability)
  • Nevýhody použití switch (token) pro vytváření jednotlivých operátorů. Řešení tohoto problému nebylo prezentování (vizte Bonus níže)
  • Možné řešení
• Představení návrhového vzoru Visitor
• Nová úloha Vyhodnocování výrazů II
  • 5 bodů za funkční řešení
  • 5 bonusových bodů za využití návrhového vzoru visitor pro implementaci vyhodnocování v reálných číslech (originální algoritmus pro vyhodnocování v celých číslech není nutné předělávat)
  • Bonus: 5 dalších bodů za implementaci parsovacího algoritmu takovým způsobem, který umožní jednoduché začlenění nových operátorů (jinými programátory, kteří používají naši knihovnu) bez nutnosti nějaké formy switch (operator)

11. Cvičení

• Komentáře k řešení Vyhodnocování výrazů II
  • Použití společného interface pro všechny visitory, což usnadňuje přidávání nových algoritmů
  • Visit metody přijímají konkrétní operátory (PlusExpression, …) abychom se vyhnuli konstruktu jako switch (operator)
  • Problémy s vracením hodnot z metod Visit a Accept podle kvality (nejhorší po nejlepší)
    • ✖ Použití typu double protože int se vejde do double (ale string se do double nevejde).
    • ✖ Použití typu object jako návratovou hodnotu, protože vše je potomkem objectu. Vede na neefektivní řešení kvůli boxování a případné problémy s InvalidCastException až za běhu u zákazníka
    • ✖ Použití explicitního zásobníku místo volacího zásobníku jako prostor, kam si můžu ukládat hodnoty
    • ✖ Použití jedné hodnoty, která je sdílená mezi voláními při vyhodnocování podvýrazů
    • ✖ Vícero interfaců a Accept metod, které vrací různé typy (int, double, …)
    • ✔ Nejlepší způsob řešení se dozvíme později
  • Bonus z minula (parsování) prodloužen do “příště”. Stále je možné ucházet se o body za šikovnou implementaci parsování
• Nová úloha Vyhodnocování výrazů III
  • 5 bodů za základní funkční řešení
  • 5 dalších bodů za implementaci nových algoritmů, které splňují následující pravidla:
    • Přidání nového algoritmu nevyžaduje modifikaci existujících datových struktur
    • Přidání nového typu operátoru způsobí, že se nepřeloží žádný existující algoritmus
  • Bonus: 5 dalších bodů za implementaci parsovacího algoritmu takovým způsobem, který umožní jednoduché začlenění nových operátorů (jinými programátory, kteří používají naši knihovnu) bez nutnosti nějaké formy switch (operator)

Informace o zkoušce

Zkouška probíhá primárně písemnou formou, a v každé zkouškové písemce je kolem 6 až 8 otázek (některé obsahují podotázky). U každé otázky, případně podotázky, je dole uvedeno, jaký maximální počet bodů (=N) lze za správně odpovězenou otázku/podotázku získat: N bodů získáte v případě, že je odpověď na otázku správně; 0,5 * N bodu získáte, pokud odpověď není zcela kompletní, ale jinak je správná (tj. nějaká malá část odpovědi chybí nebo je nepřesná); v ostatních případech získáte 0 bodů (tj. pokud v odpovědi chybí větší část, nebo je odpověď na otázku plně nebo i jen z části nesprávná).

Celkem lze z každé písemky získat maximálně 10 bodů. Mapování získaných bodů na výslednou známku je následující:

Každá zkoušková písemka trvá 150 minut, tj. ideálně 20 minut na každou otázku + 30 minut bezpečnostní rezerva. Po písemné části následuje ústní část, kde zkoušející se studentem prochází jeho písemku, a případně nepřesností/nejasností u některých odpovědí se ptá na doplňující otázky — na základě toho je určeno finální bodové hodnocení každé otázky. Základem hodnocení je ale vždy písemná část, tedy u otázky bez odpovědi nebo se špatnou odpovědí nelze ani po ústní části získat více než 0 bodů.

Níže budou pro ilustraci uvedena zadání vybraných písemek z již proběhlých termínů (AR 2018/2019):

• 16.1.2019 (PDF) [příloha zadání (dokumentace List<T>.RemoveAt)]
• 16.1.2018 (PDF) [příloha zadání (dokumentace List<T>.Insert)]
• 25.1.2017 (PDF)
• 20.1.2016 (PDF)
• 27.1.2016 (PDF)
• 1.2.2016 (PDF)

Doplňkové informace o zkoušce

Kromě informací uvedených ve slidech z první přednášky navíc pro zkoušky z NPRG035, NPRG038, a NPRG057 platí následující 2 body:

• Pokud někdo bude zapsán na nějakém z termínů zkoušky a na termín se nedostaví, bude mu tento termín v SISu označen jako propadlý (tj. student přijde o jeden pokus). Cílem tohoto opatření je optimalizace vytíženosti jednotlivých termínů, aby všichni studenti měli možnost přijít až na 3 termíny zkoušky.
• Pokud někdo na zkoušce získá známku 2 nebo 3 a bude si chtít svůj výsledek zlepšit, může explicitně na místě během vyhodnocení zkouškové písemky požádat zkoušejícího o nezapsání známky. Zkušební termín mu pak bude v SISu označen jako propadlý. Takový student může pak později
  • požádat o dodatečné zapsání získané známky, nebo
  • přijít na jiný termín zkoušky (jakýmkoliv výsledkem této “opravné” zkoušky se ovšem anuluje předchozí získaná známka).

Modelový příklad 1:

Student X získá na 1. termínu známku 2 a odmítne ji. Na 2. termínu získá známku 3 a odmítne ji. Na 3. termínu získá známku 1.
Aktuální stav studenta X: 1. termín = propadlý, 2. termín = propadlý, 3. termín = 1, tj. student X zkoušku splnil s hodnocením 1.

Modelový příklad 2:

Student Y získá na 1. termínu známku 3 a odmítne ji. Na 2. termínu získá známku 4.
Aktuální stav studenta Y: 1. termín = propadlý, 2. termín = 4, tj. pokud chce zkoušku splnit, musí student Y přijít na 3. termín. Pokud na 3. termínu opět získá známku 4, tak zkoušku nesplnil.

Modelový příklad 3:

Student Z se nedostaví na 1. termín, na 2. termínu získá známku 3 a odmítne ji, na 3. termínu získá známku 4.
Aktuální stav studenta Z: 1. termín = propadlý, 2. termín = propadlý, 3. termín = 4, tj. student Z zkoušku nesplnil.

Informace o zápočtu

Pro získání zápočtu je nutné splnit tři podmínky:

1. Zápočtový test

Naprogramovat a odladit jeden jednoduchý příklad v časovém limitu 3 hodiny. Koná se během zkouškového období v počítačové laboratoři. Celkem pět pokusu na splnění testu, maximálně však tři během zimního zkouškového období (další pak případně v letním termínu).

2. Zápočtový program

Termíny NPRG035 (zima) i NPRG038 (léto), NPRG057 (léto), NPRG064 (léto):

• Specifikace: 15. 7. 2022
• Předvedení finální plně funkční verze (včetně uživatelské a programátorské dokumentace):
  • 1. deadline: 12. 8. 2022
  • 2. deadline: 9. 9. 2022

Požadavky na program z NPRG035, NPRG064 (zdrojového kódu v jazyce C# ⇒ nevygenerovaný (ručně psaný) rozumný kód včetně rozumných komentářů):

• Předvedeno do 1. deadline: minimálně 30 kB zdrojového kódu v jazyce C#
• Předvedeno do 2. deadline: minimálně 45 kB zdrojového kódu v jazyce C#
• Předvedeno po 2. deadline: minimálně 60 kB zdrojového kódu v jazyce C#

Požadavky na program z NPRG038, NPRG057 (zdrojového kódu v jazyce C# ⇒ nevygenerovaný (ručně psaný) rozumný kód včetně rozumných komentářů + netriviální a rozumné použití některé z „technologií“ probíraných v NPRG038, resp. NPRG057 [více viz dané předměty]):

• Předvedeno do 1. deadline: minimálně 45 kB zdrojového kódu v jazyce C#
• Předvedeno do 2. deadline: minimálně 60 kB zdrojového kódu v jazyce C#
• Předvedeno po 2. deadline: minimálně 90 kB zdrojového kódu v jazyce C#

Poznámka: Každý zápočtový program, který splňuje požadavky NPRG038, resp. NPRG057, splňuje i požadavky NPRG035 (tj. lze odevzdat jeden program za oba předměty).
Poznámka: rozumný/rozumné = na požádání posoudí cvičící

POZOR! Osobní předvedení je součástí odevzdání. Na předvádění si připravte několik slidů shrnujících: hlavní funkce programu + hlavní řešené problémy + nástin architektury.

3. Domácí úkoly

Na cvičeních se budou postupně zadávat domácí úkoly, za jejichž vyřešení obdržíte body. Povinnost vám bude uznána pokud získáte dostatečné množství bodů, podle toho, jestli se cvičení účastníte. Získání většího množství bodů vám může pomoct získat body i ke zkoušce dle tabulky níže. K uznání povinnosti je třeba získat alespoň 80b.

Všechny domácí úkoly postupně najdete v ReCodExu pro NPRG035. Tam je také řešte a odevzdávejte. POZOR: Na úkoly zadané na cvičení je standardní deadline 7 dní (tj. do začátku příštího cvičení)!

Upozornění: Domácí úkoly jsou samostatnou prací, jejímž cílem je zhodnotit schopnost studenta samostatně vypracovat složitější program v jazyce C#. Pokud bude zjištěno, že některý student odevzdal cizí řešení (např. několik studentů odevzdalo různé instance stejného řešení některého domácího úkolu, apod.), bude to považováno za pokus o podvod. Všichni takoví studenti nesplní předmět NPRG035 v tomto akademickém roce a přicházejí o možnost uznání splněných povinností v roce příštím; případně bude disciplinární komisi UK MFF doporučeno jejich vyloučení ze studia!

Za nadstandardní množství bodů z úkolů je možné získat body ke zkoušce, a sice takto:

• min. 80 bodů = úroveň “I Can Win” → splněn jeden z požadavků na zápočet, konkrétně bod “povinnosti ze cvičení”
• min. 100 bodů → získání 1,25 silných bodů do zkoušky z NPRG035
• min. 120 bodů = úroveň “Hardcore” → získání dalších 0,75 silného bodu do zkoušky z NPRG035
• min. 150 bodů = úroveň “Nightmare!” → získání 0,5 slabého bodu do zkoušky z NPRG035
• min. 200 bodů = úroveň “Mission Impossible” → získání dalšího 0,5 slabého bodu do zkoušky z NPRG035
• min. 228 bodů = “božská úroveň” → na 1 rok propůjčen titul “bohyně veškerého Csharpistva” nebo titul “bůh veškerého Csharpistva”

Celkem lze tedy získat až 2 silné bonusové body a až 1 slabý bonusové body do zkoušky z NPRG035 (hodnocení zkoušky viz slidy z první přednášky). Pozor — tyto silné bonusové body se budou započítávat pouze při 1. pokusu o složení zkoušky (tj. při svém 2. i 3. pokusu mají všichni 0 silných bonusových bodů). Nerozlišuje se z jakého důvodu student přichází na 2. nebo 3. termín (tj. zda např. odmítl známku na 1. termínu). Slabé bonusové body se budou započítávat při všech pokusech o složení zkoušky, ale pozor: slabé bonusové body nedokáží prorazit bariéru mezi známkou 4 a známkou 3 (tj. pokud po přičtení silných bonusových bodů stále vychází známka 4, tak se slabé bonusové body do výsledku zkoušky nezapočítávají).

Poznámka: Virtuální cvičení je určeno pro studenty, kteří nechtějí chodit na cvičení (např. protože minulý rok nestihli dodělat pouze zápočtový program, splnit zápočtový test, apod.).

Uznávání povinností z minulých let

Pokud jste tento předmět měli zapsaný loňský akademický rok a splnili jste pouze některé z povinností potřebných pro udělení zápočtu, může vám je po explicitním požádání (např. při předvádění zápočtového programu) uznat váš letošní cvičící (lze uznat splněnou docházku, domácí úkoly, zápočtový test, odevzdaný a schválený zápočtový program). Téma zápočtového programu (pokud ho ještě nemáte dokončený) nemusí být novým cvičícím uznáno. Pokud jste v loňském roce úspěšně složili zkoušku, ale nepodařilo se vám získat zápočet, opět po explicitním požádání vám může zkoušku uznat Pavel Ježek. Toto je iniciativa vyučujících tohoto předmětu a nelze ji požadovat po studijním oddělení!