http://wiki.pannier-schulungen.de/api.php?action=feedcontributions&feedformat=atom&user=ZSBKathleen 2026-08-21T19:49:28Z Benutzerbeiträge MediaWiki 1.28.0 http://wiki.pannier-schulungen.de/index.php?title=Benutzer:ZSBKathleen&diff=113695 2026-08-21T17:33:34Z

<p>ZSBKathleen: Die Seite wurde neu angelegt: „Váš průvodce světem interiérů sází na osvědčené tipy. Píšu o tom, jak si poradit v malém bytě. Nejvíc mě baví hledat cesty, jak si usnadnit…“</p> <hr /> <div>Váš průvodce světem interiérů sází na osvědčené tipy. Píšu o tom, jak si poradit v malém bytě. Nejvíc mě baví hledat cesty, jak si usnadnit život.</div>

ZSBKathleen http://wiki.pannier-schulungen.de/index.php?title=Verzov%C3%A1n%C3%AD_webu:_Pr%C5%AFvodce_pro_za%C4%8D%C3%ADnaj%C3%ADc%C3%AD_kod%C3%A9ry&diff=113696 2026-08-21T17:33:34Z

<p>ZSBKathleen: Die Seite wurde neu angelegt: „Druhý častý problém je ignorování dotazovacích vzorů. NoSQL databáze nejsou univerzální – každý typ má specifické možnosti dotazování. Než…“</p> <hr /> <div>Druhý častý problém je ignorování dotazovacích vzorů. NoSQL databáze nejsou univerzální – každý typ má specifické možnosti dotazování. Než nasadíte, zkuste si napsat pět nejčastějších dotazů, které vaše aplikace bude spouštět. Pokud zjistíte, že potřebujete fulltextové vyhledávání nebo složité agregace, možná je lepší zůstat u relační databáze nebo zkombinovat obojí (tzv. polyglot persistence). Také si rozmyslete, jak budete data mazat – některé NoSQL databáze nemají efektivní operaci pro smazání velkého rozsahu dat.&lt;br&gt;&lt;br&gt;Stavba REST API v Node.js s frameworkem Express patří mezi základní dovednosti backendového vývojáře. Express je minimalistický, ale dostatečně flexibilní nástroj, který vám umožní rychle vytvořit funkční rozhraní. Než začnete, ujistěte se, že máte nainstalovaný Node.js a že rozumíte základům JavaScriptu, jako jsou async/await a práce s objekty. Celý postup je vhodné rozdělit do menších kroků, abyste se vyhnuli chaotickému kódu a usnadnili si budoucí údržbu.&lt;br&gt;&lt;br&gt;Na závěr si osvojte testování API pomocí nástrojů jako Postman nebo přímo v rámci integračních testů. Pravidelně kontrolujte, jak vaše API reaguje na neexistující cesty, neplatná data nebo příliš velké požadavky. Express sice zvládá základní limity, ale pro produkci byste měli přidat kompresi a ochranu proti DoS útokům. A pamatujte – kvalitní REST API není jen o tom, aby fungovalo, ale aby bylo robustní, konzistentní a snadno použitelné pro ostatní vývojáře.&lt;br&gt;&lt;br&gt;Nejprve si otevřete vývojové prostředí. Doporučuji použít Visual Studio Community nebo Visual Studio Code, obojí je zdarma. Po spuštění vytvořte nový projekt typu „Konzolová aplikace&quot; (Console App) pro jazyk C#. Jméno projektu zvolte bez diakritiky, třeba „PrvniAplikace&quot;. Po vytvoření uvidíte soubor Program.cs s předpřipraveným kódem. Smažte vše, co tam je, a napište následující kód: Console.WriteLine(&quot;Ahoj, světe!&quot;); a stiskněte F5. Program se spustí a v okně se zobrazí text. Tím máte za sebou první funkční aplikaci.&lt;br&gt;&lt;br&gt;Nakonec si osvojte práci s vysvětlením plánu dotazu (EXPLAIN). Tento nástroj vám ukáže, jak databáze dotaz zpracovává, které indexy používá a kde dochází k sekvenčnímu procházení. Než optimalizujete, vždy se podívejte na tento výstup. Často zjistíte, že problém není v dotazu, ale v chybějícím indexu, který se tváří jako existující, ale ve skutečnosti se nepoužívá.&lt;br&gt;&lt;br&gt;Routování a zpracování požadavků Express používá pro definici koncových bodů metody jako app.get(), app.post(), app.put() a app.delete(). Každá z nich přijímá cestu a callback funkci, která má přístup k objektům req a res. Při psaní rout je důležité používat parametry cest, třeba /users/:id, a validovat je ještě před samotným zpracováním. Typickou chybou je zapomenout na asynchronní zpracování – pokud vaše handler funkce nepoužívá async/await, může dojít k neošetřeným rejectovaným promisům, které aplikaci spadnou. Vždy proto obalujte asynchronní operace do try/catch bloků.&lt;br&gt;&lt;br&gt;Další praktickou záležitostí je správa stavových kódů HTTP. Vracejte 200 pro úspěšné GET požadavky, 201 pro vytvoření nového zdroje, 204 pro úspěšné smazání a 400 nebo 404 pro chybové situace. Nepoužívejte univerzální 500 pro vše, co se nepovede. Konkrétní kódy pomáhají klientům rychleji diagnostikovat problém. Rovněž se vyhněte vracení surových chybových hlášení z databáze – vytvořte si jednoduchý middleware, který zachytí výjimky a převede je na JSON s přátelským popisem.&lt;br&gt;&lt;br&gt;Další důležitou dovedností je umět se vrátit k předchozímu stavu. Pokud jste provedli commit a zjistíte, že je něco špatně, můžete se pomocí historie podívat na jednotlivé commity a vybrat ten, ke kterému se chcete vrátit. Pozor ale na to, že pokud jste provedli další změny a ty nejsou commitnuté, mohou se dostat do konfliktu. Vždy si proto před návratem uložte nebo zahoďte aktuální rozpracovanou práci. Dobré je také vědět, že commit nemusí být trvalý – můžete jej upravit, sloučit s jiným, nebo úplně odstranit, dokud nedojde k publikaci.&lt;br&gt;&lt;br&gt;Nejjednodušší a pro menší týmy nejpraktičtější je model trunk-based development. Všechny změny směřují do hlavní větve, ale každá funkce nebo oprava dostane vlastní krátkodobou větev. Pravidlo zní: jedna větev = jeden úkol. Větve pojmenovávejte podle čísla úkolu nebo srozumitelného popisu, například feature/login-form nebo fix/empty-state. Hlavní větev zůstává vždy stabilní a připravená k nasazení.&lt;br&gt;&lt;br&gt;Až je práce hotová, nemažte staré větve hned po sloučení. Nechte je ještě pár dní, ale označte je jako uzavřené. Pokud se objeví chyba, můžete se k nim vrátit. Když si tým zvykne na tato pravidla, ušetříte hodiny času, které by jinak padly na řešení konfliktů a na dohady, kdo co měl udělat jinak. Pravidelná revize workflow po každém větším projektu pomůže odhalit slabá místa a upravit proces podle aktuálních potřeb.</div>

ZSBKathleen