https://wiki.rettungsdienstblog.eu/api.php?action=feedcontributions&feedformat=atom&user=AidenPelsaert4 2026-11-09T14:22:49Z Benutzerbeiträge MediaWiki 1.37.1 https://wiki.rettungsdienstblog.eu/index.php?title=Co_zysk%C3%A1%C5%A1,_kdy%C5%BE_zautomatizuje%C5%A1_nudnou_pr%C3%A1ci_v_Pythonu&diff=454937 2026-10-11T14:30:52Z

<p>AidenPelsaert4: Die Seite wurde neu angelegt: „Napiš pravidla, která platí pro všechny endpointy Největší čas se ztrácí na věcech, které nejsou v žádném konkrétním endpointu. Jak se předává autentizace, kdy vyprší token a co dělat při jeho expiraci, jak vypadá stránkování a řazení, jak se posílá datum a čas, jestli se čísla posílají jako řetězce, jak se zapisují peněžní částky. Tato pravidla patří do jednoho úvodu, na který se odkazuje zbytek dokumentac…“</p> <hr /> <div>Napiš pravidla, která platí pro všechny endpointy Největší čas se ztrácí na věcech, které nejsou v žádném konkrétním endpointu. Jak se předává autentizace, kdy vyprší token a co dělat při jeho expiraci, jak vypadá stránkování a řazení, jak se posílá datum a čas, jestli se čísla posílají jako řetězce, jak se zapisují peněžní částky. Tato pravidla patří do jednoho úvodu, na který se odkazuje zbytek dokumentace. Když je každý endpoint popisuje po svém, vznikají chyby, které se hledají celé hodiny, protože kód na první pohled vypadá správně.&lt;br&gt;&lt;br&gt;Udržuj dokumentaci vedle kódu a aktualizuj ji ve stejném kroku, ve kterém měníš endpoint. Ideálně tak, aby se generovala z definice, kterou používá i server, a tím se nemohla rozejít s realitou. Ověřuj ji tím, že podle ní napíšeš testovací volání, a to spusť. Když příklad v dokumentaci nefunguje, je to chyba jako každá jiná. Zpětná vazba od frontendu je nejcennější zdroj: když se na něco ptá dvakrát, patří to do dokumentace, ne do chatu.&lt;br&gt;&lt;br&gt;Proč většina začátečníků skončí u rozbitého skriptu Nejčastější chyba není v syntaxi, ale v prostředí. Nainstaluješ knihovnu globálně, spustíš skript a ono to funguje. O měsíc později přejdeš na jiný počítač a nic neběží, protože chybí závislosti. Řešení je virtuální prostředí: vytvoř ho příkazem python -m venv venv, aktivuj a teprve do něj instaluj balíčky. Seznam závislostí si ulož pomocí pip freeze &gt;requirements.txt. Druhá častá chyba je zapomenutá cesta k souboru. Nepoužívej absolutní cesty typu C:\Users\... v kódu. Ulož skript do stejné složky jako data nebo cestu sestav pomocí pathlib a __file__. Třetí chyba je tichý běh: skript něco smaže nebo přepíše a ty to zjistíš později. Vždy nejdřív testuj na kopii dat a výstup ukládej do nového souboru, ne přes původní.&lt;br&gt;&lt;br&gt;Výsledkem je čitelná historie, bezpečnější tajemství a možnost vrátit kód i konfiguraci nezávisle. Není to o nástroji, ale o disciplíně: kód a konfigurace mají různé vlastníky, různé tempo změn a různé dopady. Dokud je držíte pohromadě, platíte za to při každém incidentu.&lt;br&gt;&lt;br&gt;Konfiguraci dělte podle prostředí, ale ne pomocí větvení v gitu. Větve pro vývoj, test a produkci vedou k nekonečnému mergování a rozjetým rozdílům. Lepší je jedna větev a adresářová struktura: například base, vyvoj, test, produkce, kde se hodnoty překrývají. Tajemství nepatří ani do jednoho repozitáře. Držte je ve správci tajemství nebo v šifrovaném souboru, který se odemyká při nasazení. Do gitu patří jen odkaz na tajemství, ne jeho obsah.&lt;br&gt;&lt;br&gt;Čistý kód v JavaScriptu nepoznáte podle toho, že funguje. Fungovat může i změť funkcí, které se navzájem volají přes globální proměnné. Čistý kód poznáte podle toho, že ho za půl roku pochopíte i vy sám, a že ho bez obav upraví někdo jiný. Rozdíl mezi čitelným a nečitelným kódem přitom není v délce ani v použitém frameworku. Je v rozhodnutích, která děláte při psaní každé funkce.&lt;br&gt;&lt;br&gt;U každého endpointu uveď čtyři věci: metodu a cestu, povinné a nepovinné parametry včetně typu a omezení, příklad požadavku a příklad odpovědi. Neopisuj jen úspěch. Uveď i chybové stavy, které frontend reálně potká: neplatný token, chybějící oprávnění, neexistující záznam, konflikt při souběžné úpravě. Ke každému přidej konkrétní stavový kód a tělo odpovědi. Pokud backend vrací chyby v různých formátech, frontend bude mít v kódu desítky podmínek, které se budou plést. Sjednoť tvar chyby ještě předtím, než začneš psát dokumentaci.&lt;br&gt;&lt;br&gt;Používej reálné příklady, ne vymyšlené. Vygeneruj je z běžícího serveru a vlož tak, jak skutečně vypadají, včetně zanořených objektů a prázdných hodnot. Vyhni se popisům typu „vrací seznam&quot; bez upřesnění, co je v položce a co znamená každé pole. U výčtových hodnot vypiš všechny možné varianty a napiš, co znamenají. Frontend pak nemusí hádat a backend nemusí vysvětlovat, proč se zobrazuje nula místo názvu stavu.&lt;br&gt;&lt;br&gt; Kdy přesunout test do jiné vrst&lt;br&gt;&lt;br&gt;Verzování kódu a verzování konfigurace mají odlišná pravidla: kód se mění v logických celcích, konfigurace se mění podle prostředí, tajemství a nasazení. Když obojí leží v jednom repozitáři bez pravidel, vzniká zmatek: commit obsahuje změnu logiky i úpravu produkční adresy, historii nelze číst a návrat k předchozí verzi rozbije běžící systém. Řešením není jeden velký repozitář, ale oddělení podle účelu a citlivosti.&lt;br&gt;&lt;br&gt;Dokumentace REST API není popis toho, co všechno umí server. Je to pracovní nástroj pro člověka, který za týden nebo za měsíc usedne k frontendu a potřebuje vědět, co poslat a co dostane zpět. Pokud dokumentace vzniká až na konci vývoje, bývá neúplná a plná domněnek. Začni tím, že sepíšeš jeden jediný scénář: přihlášení uživatele, načtení seznamu položek, jejich úprava. Teprve z něj odvoď strukturu celé dokumentace. Většina týmů zjistí, že víc než polovinu endpointů lze popsat podle tří nebo čtyř opakujících se vzorů.</div>

AidenPelsaert4 https://wiki.rettungsdienstblog.eu/index.php?title=Benutzer:AidenPelsaert4&diff=454936 2026-10-11T14:30:31Z

<p>AidenPelsaert4: Die Seite wurde neu angelegt: „Váš průvodce dílnou i obývákem žije už dlouho. Sdílím zde, jak skloubit funkčnost s teplem domova. Nejraději hledat cesty, jak si usnadnit život.“</p> <hr /> <div>Váš průvodce dílnou i obývákem žije už dlouho. Sdílím zde, jak skloubit funkčnost s teplem domova. Nejraději hledat cesty, jak si usnadnit život.</div>

AidenPelsaert4