V tomto videu se podíváme na důležitý technický detail v Blazoru, který představil – proč by se v metodě OnInitialized popř. OnInitializedAsync neměly používat parametry. Ukážeme si na příkladu konkrétního problému, který může nastat, když komponenta nezmění instanci při změně routy a parametr zůstane se starou hodnotou. Dozvíš se:
Jak funguje lifecycle metoda OnInitialized v Blazoru
Proč je nevhodné používat [Parameter] hodnoty v této fázi
Jaké chyby to může způsobit v praxi
Kdy (a jestli vůbec) je použití parametrů v OnInitialized v pořádku
Záznam ze Vzdělávacího okénka HAVIT z 3. dubna 2025.
V tomto videu se dozvíte vše o našich nových YAML pipelines v Azure DevOps, které prezentuje Jiří Kanda. Jirka vysvětluje, proč jsme se rozhodli přejít na YAML pipelines a jaké výhody nám to přináší.
Specifika našich buildů a důvody pro změnu na YAML pipelines.
Výhody YAML pipelines, jako jsou lepší parametrizace a paralelizace.
Základní syntaxe YAML a struktura YAML pipelines.
Paralelní běh jobů a použití více agentů.
Volitelné parametry buildů a task scheduler.
Podpora pro integrační testy a automatické pull requesty.
Použití deduplication a reprodukovatelnost buildů.
Validace zranitelností nuget balíčků a definice pipeline v projektech.
Problémy s manuálním spuštěním buildů.
Záznam ze Vzdělávacího okénka HAVIT z 27. března 2025.
Tentokrát o ValueExpression parametrech v Blazoru a potřebě jejich správného použití pro fungování validací.
Záznam ze Vzdělávacího okénka HAVIT z 13. března 2025. Zkoušíme zpestřit novým formátem mini-okének, kde se budou objevovat ad-hoc témata v řádu 2-10 minut.
Záznam ze Vzdělávacího okénka HAVIT z 26. září 2024, kde Daniel Hrubý povídal o Microsoft Azure Entra ID a aspektech jako MFA, Conditional Access Policies, B2B Collaboration atp.
Záznam ze Vzdělávacího okénka HAVIT ze 24. října 2024, kde jsem ukazoval problematické chování Blazored.FluentValidationsValidator při komplexním view-modelu a validaci fieldů na sub-modelech.
Záznam z přednášky pro konferenci WUG Days Brno z 6. září 2024, kde jsem ukazoval základy uspořádání paměti v .NET, internals Garbage Collectoru a pokročilý debugging pomocí Windows Debuggeru (WinDbg) a SOS extension.
Téma není zaměřené primárně na novinky, ale jde do hloubky — jak .NET skutečně spravuje paměť, jak to funguje uvnitř a jak se v tom vyznat při pokročilém debuggingu (Memory Dump, WinDbg, SOS).
Zásobník (Stack)
Zásobník je paměť pevné velikosti (defaultně 1 MB na thread), organizovaná pomocí Stack framů. Každé volání metody přidá Stack frame s lokálními proměnnými, parametry a návratovou adresou. Stack je základním mechanismem řízení běhu programu — bez něj by se metody neměly kam vracet. Stack overflow nastává téměř výhradně kvůli nekonečné rekurzi, ne proto, že by aplikace měla příliš hluboký call stack.
Managed Heap a Garbage Collector
.NET runtime si od Windows alokuje nativní paměť a část z ní předá Garbage Collectoru, který ji uspořádá jako managed heap. GC je zodpovědný nejen za uvolňování paměti (jak napovídá název), ale i za samotnou alokaci referenčních typů. Klíčovými koncepty jsou GC Generations (Gen0, Gen1, Gen2) pro generační sběr odpadu a Large Object Heap (LOH) pro velké objekty nad 85 000 bytů.
Windows Debugger (WinDbg) a Memory Dump
WinDbg je mocný, ale uživatelsky nepřívětivý nástroj pro analýzu .NET procesů a Memory Dumpů. Instaluje se přes Microsoft Store. Nejčastější workflow: z Task Manageru vytvoříte Memory Dump (pravé tlačítko → Create memory dump file), soubor načtete do WinDbg a analyzujete. Pro práci s .NET objekty je nezbytná SOS (Son of Strike) extension, která umožňuje zkoumat managed heap, zásobníky threadů a jednotlivé objekty přímo v paměti.
HAVIT Knowledge Base 