Zeptejte se na cokoli, co se týká návrhu API! Odpovím a hlavně se zaměřím na rozdíly mezi psaním API a psaním běžného kódu. Navrhování API sice vypadá jako programování, ale pro většinu z nás to není denní chléb. Tudíž se návrh API se nachází hodně blízko našeho horizontu vědomostí a je tím pádem je trochu nejasný.  Věci, které leží blíže k nám jsou ostřejší a lépe viditelné. Vzdálenější objekty jsou více a více rozostřené. To, co je téměř na horizontu, je nejasné a záhadné. Měl jsem to štěstí, že jsem se navrhováním nejen NetBeans API živil více než patnáct let. Při té práci jsem posbíral minimálně dvacet pozorování, které se mohou jevit paradoxně. V této přednášce si na některé společně posvítíme. Ale připravte si otázky! Ať se můžeme zaměřit na to, co vás zajímá!

Přednáška pro začínající Java vývojáře představí praktické základy CI/CD – od verzování a práce s repozitářem až po automatizované buildy a nasazování do Azure. Účastníci uvidí, jak se tvoří jednoduché, ale spolehlivé pipeline, jaké nástroje GitHub nabízí pro automatizaci a jak CI/CD pomáhá udržet kvalitu kódu i rychlost vývoje. Cílem je dát nováčkům jasný a použitelný základ, který mohou hned začít využívat ve svých projektech.

Tato přednáška ukáže Java vývojářům, jak GitHub Copilot mění způsob psaní kódu – od generování funkcí a testů až po návrhy architektury či refaktoring. Účastníci se naučí formulovat prompty, pracovat s Copilotem v IDE, v Codespaces i příkazové řádce a využívat vibe coding jako moderní styl vývoje, který kombinuje kreativitu, rychlost a bezpečné vedení AI asistenta. Přednáška je ideální pro začátečníky, kteří chtějí Copilot začít používat prakticky.

Díky AI se způsob, jakým vznikají produkty mění doslova před očima. Byznys dokáže vytvářet prototypy a malé týmy zvládnou to, na co bylo ještě nedávno potřeba několik desítek lidí. Konkurenční výhodou není něco vytvořit. Konkurenční výhodou je vědět, co má smysl vytvářet. S tím, jak se zodpovědnost za produktový management rozšířuej napříč organizací, dělá produktová rozhodnutí v podstatě každý. Některé týmy vytvoří produkty, které změní trh, jiní vytvoří krásně zpracovaná řešení hledající problém. V této přednášce se podíváme na to, proč se zákaznická empatie, experimentování, prioritizace a Product Thinking stávají klíčovými dovednostmi pro každého, kdo ovlivňuje směřování produktu – od lídrů přes vývojáře až po doménové experty. Podíváme se, jak se organizace posouvají směrem k menším a autonomnějším týmům a co se stane, když zodpovědnost za produkt přestane být rolí jednotlivce a stane se odpovědností celého týmu. Ve světě, kde může vytvářet každý, není konkurenční výhodou schopnost něco postavit. Je to schopnost pochopit zákazníka. Po této přednášce: * Porozumíte tomu, proč se product thinking stává jednou z klíčových leadership dovedností. * Zjistíte, jak zákaznická empatie a experimentování pomáhají týmům zaměřit se na produkty, které zákazníkům přinášejí hodnotu. * Naučíte se posilovat product thinking napříč týmy, nejen v rámci product managementu. * Pochopíte, jak autonomní týmy balancují rychlou dodávku, inovace a hodnotu pro zákazníka.

Většina z nás už zkusila delegovat opravu chyb na AI agenty. Výsledek se ale často zvrhne v neefektivní smyčku přidávání debugovacích výpisů, rekompilací a čekání na build. Proč ale nutit AI pracovat s kódem naslepo, když může mít k dispozici stejné informace jako vývojář v IDE? V rámci přednášky si představíme mcp-jdwp-java — open source implementaci Model Context Protocol (MCP) serveru, která dává LLM agentům přímý přístup k Java debuggeru. Ukážeme si, jak tato integrace mění pravidla hry: místo hádání začne agent systematicky zkoumat stav JVM, nastavovat breakpointy a vyhodnocovat výrazy přímo nad běžícím procesem.

Technológie a frameworky sa menia závratným tempom, no srdcom každej úspešnej aplikácie zostáva jej biznis logika. V ére umelej inteligencie, kedy AI dokáže generovať kód behom sekúnd, sa paradoxne ešte viac zvyšuje dôležitosť správneho softvérového dizajnu. Bez pevných architektonických základov totiž riskujeme, že namiesto komplexných riešení vytvoríme len rýchlo vygenerovaný technický dlh. Na tejto prednáške sa pozrieme na to, ako pomocou hexagonálnej architektúry (Ports & Adapters) striktne oddeliť doménovú logiku od infraštruktúry. Ukážeme si, ako izolovať komplexnú doménu tak, aby zostala čistá, testovateľná a nezávislá od databáz, frameworkov či externých API. Zistite, ako navrhnúť aplikáciu, ktorá prežije technologické trendy a zostane udržateľná, nech už kód píše človek alebo AI.

Prompt je jen malá část toho, co jazykový model skutečně vidí. Rozebereme anatomii kontextového okna, systémové instrukce, skills, metadata i nástroje a ukážeme si, jak projekt nakonfigurovat tak, aby model dostával ve správný okamžik ty správné informace.

Za poslední rok se svět softwarového vývoje dramaticky změnil. AI dnes dokáže psát kód, hledat chyby, navrhovat řešení a zvládá stále větší část práce, kterou donedávna dělal vývojář. Co to znamená pro backendové Java vývojáře? Které dovednosti budou v době AI skutečně důležité a které naopak ztratí na významu? Jak se změní způsob, jakým budeme software navrhovat, vyvíjet a testovat? A kde jsou skutečná rizika a kde naopak nové příležitosti? Kam se může role programátora v následujících letech posunout?

Java běží v izolovaném prostředí JVM. Co když ale potřebujeme zavolat operační systém nebo knihovnu napsanou pro konkrétní procesor? Tradiční řešení je Java Native Interface (JNI). Přináší však režii, nutnost vytvářet C/Java adaptéry a riziko poškození paměti JVM. Java Native Access (JNA) některé z těchto problémů zmírňuje, ale jiné vlastnosti jsou zase neefektivní. Od Javy 22 je k dispozici Foreign Function and Memory API. Který způsob si vybrat? A jak to vlastně funguje? Pojďme se podívat na temná zákoutí JVM a porovnat výkonnost, třeba při volání knihovny SDL. 

Znáte to. Zadání je vágní, chybí polovina informací, a když se na to zeptáte, dostanete odpověď, které taky nerozumíte. Někde na začátku toho řetězce sedí analytik — a je to jednoduchý viník. Podíváme se, kdy za to analytik opravdu může, kdy to tak jen vypadá, a hlavně na to, co s tím můžete udělat vy — protože kvalita zadání se liší, ale očekávání od výsledku jsou vždycky stejně vysoká. Obsah: ● Za všechno může analytik ● Kdy za to analytik opravdu může: chyby, které děláme ● Analytici — odkud přicházejí a proč se tak liší technickou hloubkou ● Vztahy, ne dokumenty: kde se spolupráce láme ● Jak se ptát, aby z toho bylo použitelné zadání