https://www.it-core.eu/wiki/api.php?action=feedcontributions&feedformat=atom&user=EvieRainey98174 2026-09-05T03:15:40Z User contributions MediaWiki 1.44.2 https://www.it-core.eu/wiki/index.php?title=Permisivn%C3%AD_vs._copyleft:_kter%C3%A1_open_source_licence_sedne_va%C5%A1emu_projektu%3F&diff=199377 2026-08-29T04:56:48Z

<p>EvieRainey98174: Created page with &quot;Praktickým krokem je rozhodnutí o tom, co odlišuje váš projekt. Pokud jde o knihovnu, kterou mají ostatní vývojáři připojovat do svých aplikací, permisivní licence usnadní integraci. Pokud jde o samostatnou aplikaci, kterou chcete poskytovat s garancí svobody pro koncové uživatele, silnější copyleft dává smysl. Častou chybou je kombinace více licencí v jednom projektu. Přidávání souborů pod odlišnými licencemi vytváří právní zmatek a...&quot;</p> <hr /> <div>Praktickým krokem je rozhodnutí o tom, co odlišuje váš projekt. Pokud jde o knihovnu, kterou mají ostatní vývojáři připojovat do svých aplikací, permisivní licence usnadní integraci. Pokud jde o samostatnou aplikaci, kterou chcete poskytovat s garancí svobody pro koncové uživatele, silnější copyleft dává smysl. Častou chybou je kombinace více licencí v jednom projektu. Přidávání souborů pod odlišnými licencemi vytváří právní zmatek a může vést k tomu, že kód nelze legálně distribuovat vůbec. Proto si hned na začátku ujasněte, jestli budete používat jednotnou licenci, nebo zda si vystačíte s výjimkou pro určité části projektu.&lt;br&gt;&lt;br&gt;Druhým častým problémem je expirace tokenu. Mnoho aplikací nastavuje příliš dlouhou platnost, třeba den nebo týden, aby uživatel nemusel často přihlašovat. To je ale past: pokud token unikne, útočník má dlouhý časový okno. Ideální je krátká expirace v řádu minut a kombinace s refresh tokenem. Refresh token pak musí být dlouhodobý, ale musí být uložen bezpečně, nejlépe v HttpOnly cookie s atributy SameSite a Secure. Při každém obnovení přístupového tokenu ověřte, že refresh token nebyl odvolán, a to buď na straně serveru, nebo pomocí blacklistu v databázi.&lt;br&gt;&lt;br&gt;Rozdělení testů do vrstev neznamená, že integrační testy jsou důležitější. Jsou jen dražší. Snažte se, aby integrační test tvořil jeden velký tok – od požadavku až po uložení a načtení. Pokud se něco pokazí, rychle zjistíte, která vrstva selhala. Zavedení těchto pravidel vyžaduje disciplínu, ale výsledkem je testovací sada, která roste s projektem a nepůsobí jako brzda. Když vývojář vidí, že testy běží rychle a spolehlivě, začne je psát častěji a s menším odporem.&lt;br&gt;&lt;br&gt;Nakonec si zkuste představit, že zprávu čte někdo, kdo nezná kód. Pokud po přečtení tuší, co se změnilo a proč, je to dobrá zpráva. Pravidelně se vracejte ke starým commitům a hodnoťte, zda byste podle nich dokázali rekonstruovat rozhodovací proces. Časem vám psaní smysluplných zpráv půjde samo a stane se přirozenou součástí práce.&lt;br&gt;&lt;br&gt;Třetí oblast, kterou bych zdůraznil, je asynchronní kód. Express od verze 4 nezpracovává chyby v async funkcích automaticky. Pokud v route handleru použijete async/await a dojde k výjimce, Express ji nechytí a server může spadnout. Řešení je jednoduché – buď každý async handler obalíte do try/catch bloku, nebo si vytvoříte malý wrapper, který chyby předává do next(). Modernější verze Expressu (5.x) už tento problém řeší, ale pokud zůstáváte na verzi 4, wrapper je nezbytnost. Bez něj se vám může stát, že jeden špatný požadavek shodí celý proces.&lt;br&gt;&lt;br&gt;Pamatujte také na testování sítě. Mobilní aplikace se používají na cestách, v metru, na venkově, kde je signál slabý nebo nestabilní. Proto je důležité testovat chování aplikace při pomalém připojení, při výpadku sítě a při přepnutí z Wi-Fi na mobilní data. Vytvořte si testovací scénáře, které simulují tyto podmínky pomocí nástrojů pro omezení šířky pásma nebo emulaci zpoždění. Ujistěte se, že aplikace uživatele informuje o probíhajícím načítání, nedochází ke ztrátě vstupů a po obnovení připojení se data synchronizují bez chyb.&lt;br&gt;&lt;br&gt;První chybou, kterou u začínajících projektů vidím, je všechno nacpané do jednoho souboru. Express umožňuje rozdělit aplikaci na moduly, a to byste měli využít. Místo deseti route handlerů v jednom souboru si vytvořte samostatné soubory pro jednotlivé zdroje (například uživatele, produkty, objednávky). Každý soubor exportuje router, který pak připojíte k hlavní aplikaci. Tím získáte přehlednost a každý router můžete testovat samostatně. Nezapomeňte také na oddělení logiky od samotných route handlerů – validaci, práci s databází a byznys logiku držte v samostatných službách nebo middleware.&lt;br&gt;&lt;br&gt;S validací souvisí i jednotné zpracování chyb. Express má vestavěný mechanismus pro chybové middleware, který se definuje se čtyřmi argumenty (err, req, res, next). Vytvořte si centrální middleware pro chyby, který zaloguje detailní informace a vrátí klientovi pouze bezpečnou část. Nikdy nevracejte klientovi stack trace nebo interní chyby databáze. Pro produkční prostředí použijte generický formát chyby, který klientovi řekne, co se pokazilo a případně jak to opravit. Pro vývojové prostředí můžete vrátit více detailů.&lt;br&gt;&lt;br&gt;Commitová zpráva je jediný trvalý záznam o tom, proč jste změnu provedli. Kód se přepíše, soubory se smažou, ale historie zůstává. Pokud píšete zprávy typu „oprava bugu&quot; nebo „úpravy&quot;, za pár měsíců nebudete vědět, co jste vlastně dělali. Vyplatí se proto investovat pár sekund navíc a napsat zprávu, která dá odpověď na dvě základní otázky: co se změnilo a proč.</div>

EvieRainey98174 https://www.it-core.eu/wiki/index.php?title=User:EvieRainey98174&diff=199374 2026-08-29T04:56:46Z

<p>EvieRainey98174: Created page with &quot;Autor blogu praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejraději popisovat postupy krok za krokem.&quot;</p> <hr /> <div>Autor blogu praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejraději popisovat postupy krok za krokem.</div>

EvieRainey98174