<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="pl">
	<id>https://jak.mazovia.edu.pl/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=SheenaStuder44</id>
	<title>Mazovia - Wkład użytkownika [pl]</title>
	<link rel="self" type="application/atom+xml" href="https://jak.mazovia.edu.pl/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=SheenaStuder44"/>
	<link rel="alternate" type="text/html" href="https://jak.mazovia.edu.pl/index.php/Specjalna:Wk%C5%82ad/SheenaStuder44"/>
	<updated>2026-11-05T23:28:19Z</updated>
	<subtitle>Wkład użytkownika</subtitle>
	<generator>MediaWiki 1.42.1</generator>
	<entry>
		<id>https://jak.mazovia.edu.pl/index.php?title=Kdy_zvolit_permisivn%C3%AD_licenci_a_kdy_copyleft,_aby_projekt_p%C5%99e%C5%BEil&amp;diff=1041673</id>
		<title>Kdy zvolit permisivní licenci a kdy copyleft, aby projekt přežil</title>
		<link rel="alternate" type="text/html" href="https://jak.mazovia.edu.pl/index.php?title=Kdy_zvolit_permisivn%C3%AD_licenci_a_kdy_copyleft,_aby_projekt_p%C5%99e%C5%BEil&amp;diff=1041673"/>
		<updated>2026-10-11T19:41:40Z</updated>

		<summary type="html">&lt;p&gt;SheenaStuder44: Utworzono nową stronę &amp;quot;Poslední pravidlo se týká komunikace. Větve, které na sebe navazují, držte krátké a slučujte v pořadí, v jakém vznikaly. Pokud dvě větve mění stejné místo, domluvte se předem, kdo sloučí první, a teprve pak upravte tu druhou. Větvení není jen technická operace, ale dohoda mezi lidmi. Když pravidla platí pro všechny stejně, přestane být slučování stres a stane se rutinou.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Vyhněte se několika častým chybám. Nepřidávej…&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Poslední pravidlo se týká komunikace. Větve, které na sebe navazují, držte krátké a slučujte v pořadí, v jakém vznikaly. Pokud dvě větve mění stejné místo, domluvte se předem, kdo sloučí první, a teprve pak upravte tu druhou. Větvení není jen technická operace, ale dohoda mezi lidmi. Když pravidla platí pro všechny stejně, přestane být slučování stres a stane se rutinou.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Vyhněte se několika častým chybám. Nepřidávejte sloupce, dokud je skutečně nepotřebujete — každý nový sloupec znamená nové pravidlo a nové místo, kde se dá schovat nedokončená práce. Nepoužívejte tabuli jako nástroj pro kontrolu lidí; jakmile se z karet stane měřítko výkonu jednotlivce, tým je přestane aktualizovat poctivě. A nechte tabuli ve stavu, který odpovídá realitě, i když je to nepříjemné. Zastaralá tabule je horší než žádná.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Nejprve si ujasněte, co vlastně potřebujete simulovat. Externí služba může být vzdálené API, databáze, fronta zpráv nebo třeba souborový systém. Pro každou z nich vytvořte rozhraní, které aplikace používá. To vám umožní snadno podstrčit náhradu. Například místo přímého volání HTTP klienta definujte rozhraní EmailSender s metodou send(). V produkci použijete skutečného klienta, v testech falešnou implementaci, která si pouze poznamená, co bylo odesláno.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Praktický postup: nejprve zjistěte, zda váš projekt závisí na jiných licencích. Kombinace GPL a permisivní licence je obvykle možná, ale výsledek musí být GPL. Naopak kombinace permisivní a proprietární je možná jen tehdy, pokud permisivní licence nevyžaduje copyleft. Vždy si přečtěte kompatibilitu licencí, ne jen jejich názvy. Pokud si nejste jisti, použijte jednoduchou permisivní licenci – méně právních problémů, více uživatelů.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Zavést kanban je snadné, udržet ho v chodu je těžší. Většina týmů selže nikoli na samotné tabuli, ale na pravidlech, která si nikdy nedomluvila. Metodika pro kanban nestojí na nástroji, ale na dohodě o tom, co jednotlivé sloupce znamenají, kdy se karta posouvá a kdo má právo rozhodnout, že je práce hotová. Bez této dohody se tabule do měsíce změní v dekoraci.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Metodika pro kanban se udrží jen tehdy, když ji tým používá k rozhodování. Jednou za čas se sejděte a projděte, které sloupce nebo limity už nefungují, a upravte je. Změna není selhání, je to součást provozu. Pokud se pravidla nemění a přesto práce plynule ubývá, máte vyhráno — a to je jediné měřítko, které stojí za to sledovat.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Při návrhu testů dbejte na izolaci. Každý test by měl mít vlastní instanci falešné služby, aby se výsledky neovlivňovaly. Pokud používáte dependency injection, je to snadné – v testu předáte mock, v produkci skutečnou implementaci. Vyhněte se globálním stavům a singletonům, které by mohly unikat mezi testy. Také nezapomeňte testovat, že aplikace volá externí službu správným způsobem – tedy že předává správné parametry a volá ji ve správný čas. K tomu slouží ověřovací metody na mockách.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Rychlost dotazu nejčastěji nezávisí na tom, jak dlouho trvá samotný výpočet, ale na tom, kolik dat musí databáze přečíst. Pokud dotaz prochází celou tabulku, aby vrátil pár řádků, je to signál, že chybí vhodný index nebo že ho optimalizátor odmítl použít. Prvním krokem je proto zjistit skutečný plán provedení. Většina databázových systémů umí příkaz EXPLAIN nebo jeho obdobu. Sledujte, zda se u tabulky objevuje full table scan, jaký typ joinu se použil a kolik řádků se odhaduje. Právě rozdíl mezi odhadem a skutečností často ukáže, kde je problém.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Pokud aplikace běží ve více instancích, paměťové úložiště přestane fungovat spolehlivě. Každý proces má vlastní počítadla a limit se tak fakticky násobí. Řešením je úložiště v Redis nebo jiné sdílené databázi. express-rate-limit podporuje vlastní store; stačí předat instanci klienta. Pozor na to, že Redis musí být dostupný a nesmí se stát dalším bodem selhání. Nastavte časové limity připojení a ošetřete výpadky tak, aby aplikace nespadla, ale aby limit přešel do bezpečného režimu.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Typickou chybou je přílišná složitost falešných objektů. Snažte se, aby stuby byly co nejjednodušší – vracejí předpřipravená data a nic nepočítají. Složitější logiku (např. filtrování, stránkování) nechte na produkčním kódu a v testech ji obcházejte. Další častou chybou je, že vývojáři testují pouze šťastnou cestu. Zapomínají na okrajové případy: prázdné odpovědi, neplatný formát dat, síťové chyby. Přitom právě tyto situace v produkci nastávají a je třeba je ošetřit.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Denní schůzka nemá být reportování vedoucímu. Držte ji krátkou a orientujte ji na tři otázky: co dnes dokončíme, co nám v tom brání a kde se tvoří fronta. Karta, která stojí na místě několik dní, je signál, ne ostuda. Sledujte dobu, po kterou karta prochází jednotlivými fázemi, ne jen celkový počet hotových věcí. Průměrná doba průchodu odhalí úzké místo spolehlivěji než pocit, že je tým zaneprázdněný.&lt;/div&gt;</summary>
		<author><name>SheenaStuder44</name></author>
	</entry>
	<entry>
		<id>https://jak.mazovia.edu.pl/index.php?title=U%C5%BCytkownik:SheenaStuder44&amp;diff=1041671</id>
		<title>Użytkownik:SheenaStuder44</title>
		<link rel="alternate" type="text/html" href="https://jak.mazovia.edu.pl/index.php?title=U%C5%BCytkownik:SheenaStuder44&amp;diff=1041671"/>
		<updated>2026-10-11T19:41:39Z</updated>

		<summary type="html">&lt;p&gt;SheenaStuder44: Utworzono nową stronę &amp;quot;Někdo, kdo praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Někdo, kdo praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.&lt;/div&gt;</summary>
		<author><name>SheenaStuder44</name></author>
	</entry>
</feed>