20.11.2014

Poznatky z GeeCON konference

23. a 24. 10 se v Praze konal další ročník konference GeeCON se zaměřením na Javu a tady je několik mých poznámek, které můžou někoho navnadit, aby si stáhl prezentace dostupné na webu nebo zašel na příští ročník. Neal Ford – This is Water Cascade of Attention-Deficit Teenagers (http://www.jwz.org/doc/cadt.html) – problém u projektů, který ubírá motivaci ke spolupráci a hlášení chyb. Uživatel projektu založí chybu, vývojář projektu se na ní za celá léta ani nepodívá, na projektu dojde k velkému přepsání, vyjde nová verze a staré bugy se jednoduše zavřou bez jakékoliv investigace. Metawork is more interesting then work – máme příliš mnoho frameworků, jejich vymyšlení je zajímavější než vývoj samotný. Collective intelligence is significantly correlated to group composition, and is higher with a higher concentration of females in the group. (http://www.wjh.harvard.edu/~cfc/Woolley2010a.pdf) Aktuální „best practices“ budou zítra „anti-patterns“. Důležité je vytvářet architekturu, která pomáhá a ne trestá. Pokud se systém stává více distribuovaný, je vhodné preferovat přístup BASE (Basically Available Soft-state services with Eventual-consistency) proti zavedenému ACID (Atomicity, Consistency, Isolation, Durability) – viz. CAP Theorem (http://www.julianbrowne.com/article/viewer/brewers-cap-theorem) Janne Sinivirta – Pragmatic Architecture for Agile Teams Agilní přístup neznamená vynechat architekturu. Je třeba najít balanc mezi disciplínou a agilním přístupem („Balancing Agility and Discipline“ by Barry Boehm and Richard Turner). Dělat dostatečný návrh a dostatečně včas. Architektura je příliš důležitá, než aby ji dělal jen architekt. Je to zodpovědnost týmu. Neměli bychom se bát povolit lokální rozhodnutí. Dokumentovat vazby, které nejsou zřejmé z kódu. Ujasnit si, kdo to bude číst. There’s no organization. Just people. Oliver Gierke – Whoops! Where did my architecture go? Pokud si myslíte, že je architektura drahá, zkuste to úplně bez ní. Stavba systému uvnitř představuje mikro architekturu, zatímco komunikace mezi nimi představuje makro architekturu. „Layers“ vs. „Slices“. „Layers“ (web, service, dao) jsou pro vývojáře známé a důležité, pro business lidi ale nezajímavé. „Slices“ (core, client, account) jsou pro vývojáře méně důležité, pro business lidi ale klíčové. Jak potom pojmenovat packages? …web.core, …service.core, …dao.core (…layer.slice) nebo …core.web, …core.service, …core.dao (…slice.layer) nebo jenom …core, …client, …account (…slice)? Máme přece default visibility, na implementační třídu stačí, jenom interface a doménová třída bude public. Kompilátor tak pomáhá dodržovat architekturu. Je třeba začít co nejstriktněji a uvolňovat, jen pokud je potřeba. Buďte obeznámení se závislostmi. Závislosti mezi „layers“ tvoří graf, mezi „slices“ může být schovaný cyklus. Karel Rank – Low-latency trading system in Java – SubM Java je pokládána za pomalou proti C++ a pro realtime aplikace nepoužitelná. Několik let jsem vyvíjel pro realtime QNX v C-ku a proto mě osobně zajímá jakékoliv přibližování Javy k světu realtime. Prezentace ukázala, že při znalosti Javy, paměti, CPU se dá vytvořit aplikaci s nízkou latenci. Přepnutí kontextu na Intel Sandy Bridge trvá dlouhé 3 mikrosekundy. Proto použijeme jen jedno vlákno, immutable instance, binding vláken na jádra (affinity). Je dobře znát latenci jednotlivých vrstev paměti a využít toho: L1 – 0,5ns, L2 – 7ns, L3 – 25ns, RAM – 100ns, HDD – velice dlouho. Pokud to jde, minimum interakce s HDD. Latenci kvůli JIT porazíme zahřátím JVM pomoci testovacích požadavků (cca 10000), aby byla JVM rychlá už od prvního klientského požadavku. GC neporazíme. Můžeme použít G1 GC nebo CMS GC, Buffer Pooling, ThreadLocal. Zůstává vyřešit neefektivní algoritmus. Použijeme cache-friendly a specializované struktury, nic z JDK (kromě ArrayList). Podívejte se na trove4j a Disruptor (kruhový buffer, Single-Writer princíp – http://mechanical-sympathy.blogspot.cz/2011/09/single-writer-principle.html, https://lmax-exchange.github.io/disruptor/). Václav Pech – JetBrains MPS – Speaking your language Původně jsem na přednášku zašel jen ze zvědavosti, protože ostatní mně podle názvu nezaujaly. Během několika minutách při ukázce několika obrazovek jsem si ale vybavil moji několikaletou práci v doméně meteorologie a letectví, a specifické pojmy, jednotky a méně nebo více košaté vzorce. Konkrétně mi to připomnělo implementaci knižnice fyzika pro převody mezi jednotkami soustavy SI a dalšími, význam suché a vlhké teploty (tzv. teplota punčošky) a rosného bodu, plovoucí průměr rychlosti a směru větru… Každá doména mluví svým vlastním jazykem. Čím je doména více specializovaná, tím si tvoří specializovanější jazyk. Například snažit se naprogramovat běžným programovacím jazykem vzorec, který má několik indexů nahoře i dole, nebo používá tabulku nebo matici je složité a vizuálně to jako vzorec nebo matice nevypadá. Přednáška ukázala, jak stavět DSL (Domain Specific Language) pomocí nástroje JetBrains MPS (Meta Programming System) https://www.jetbrains.com/mps/. MPS finálně generuje zápis do základního jazyka (Java, C …). Prezentován byl známý jazyk Karel definován pomocí DSL. Příklad jazyka pro složitější matematické operace (demo příklad distribuován s nástrojem MPS):geecon Stefano Gioia – Java and communications Je možné Javu použít v Telco doméně? Oracle se bude o to snažit. Java se musí přiblížit k realtime a latence musí být nízká, čemu bránil hlavně GC. Po posledních optimalizacích je GC mnohem více deterministický a nedělá výkonnostní výkyvy a velké pauzy při své práci. Je tak možné plnit podmínky SLA. Následovat bude příprava komunikačního API pro potřeby Telca a optimalizace SIP Servletu. Nikita Salnikov-Tarnovski – I bet you have a memory leak Skvělá přednáška o tom, jak v jednoduché aplikaci vznikne Memory nebo Classloader leak a co je toho příčinou. Při odhalování a řešení jednotlivých problémů byl prezentován nástroj Plumbr (http://plumbr.eu/). Memory leak – situace, kdy objekty již nejsou v aplikaci využívané, ale GC je nedokáže identifikovat jako nepoužívané. Problém je vždy specifický pro danou aplikaci. Jenom autor aplikace chápe, jak jsou objekty používané pro různé UC a jak problém řešit. Classloader leak – nejčastější leak u web aplikací, kdy po odstranění aplikace někde zůstane reference na objekt z této aplikace a všechny jeho kamarády. Stačí potom několikrát udělat redeploy a JVM padne. Nejlépe nedělat redeploy. Většina classloader leaks není způsobená vývojářem aplikace. Je to daň za znovupoužití a modulární vývoj. Vývojář častokrát neví, co všechno používá. Knihovna třetí strany si něco registruje, drží a v lepším případe autor knihovny alespoň v dokumentaci upozorní na nutnost explicitně volat nějakou metodu pro uvolnění prostředků. Někdy to v dokumentaci není a někdy ani knihovna neposkytuje metodu pro to a leak se nedá odstranit. Nedělejte si vlastní log level jako potomka java.util.logging.Level. Dostane se do statické mapy inner třídy KnownLevel a zůstane tam do konce života JVM. Bruce Eckel – Do Languages Matter? Velice pěkná procházka historií programovacích jazyků s nadhledem. Skvělý závěr konference. Každý přechod byl spojen s jistým odporem (assembler –> C, C –> C++, C++ –> Java s její VM a GC). Python komunita – kultura je přátelská a ráda vítá nové lidi, na konferencích je 20% žen a aktivně se zapojují Scala – „League of Legends“, možná nějaký hněv v komunitě nad titulem „Atomic Scala“ Vybrat si knihovnu nebo framework? Knihovna představuje jednu dimenzi složitosti. Framework představuje dvě nebo tři dimenze složitosti. Je tato složitost vyvážena vyšší produktivitou? Jak složité je vyměnit framework za jiný? Začni tím, že se budeš ptát proč.