Kafemlejnek.TV Kafemlejnek.TV

V druhém dílu s Radimem Danielem Pánkem se podíváme na zoubek nástroji Canarytrace, který Radim s týmem vyvíjí a který umožňuje auditing výkonosti webové aplikace z pohledu uživatele. Díl je tentokrát lepší sledovat na YouTube, protože se v něm hojně odkazujeme na to, co je vidět na monitoru a ve videozáznamu uvidíte záznam obrazovky.

Canarytrace je nástroj úzce integrovaný do Google Chrome, který přes jeho debug protokol sniffuje telemetrická data prohlížeče a ukládá je do Elasticsearch. Nad vybranými metrikami potom vytváří reporty, grafy a notifikuje odpovědné stakeholdery. V průběhu 30 minut v rychlosti prolétneme základní funkce tohoto nástroje.

Zajímavým faktem je to, že nástroj může běžet 24/7 jako jeden z běžných uživatelů vaší webové aplikace a průběžně monitoruje její odezvy. V podstatě je to kontinuálně běžící web.dev / Lighthouse, který měří chování aplikace za běžného provozu i v průběhu speciálně připravených výkonnostních testů.

Pokud jste nadšenci do testování výkonnosti – Radim hledá pro Canarytrace co-foundera.

Radim Daniel Pánek je v Čechách známým evangelizátorem výkonnostního testování. Sám natáčí vlog o výkonnostním testování TEST-STACK, přednáší a spoluorganizuje veřejné akce. Kromě toho je také zakladatelem startupu Canarytrace, který umožňuje auditing výkonosti webové aplikace z pohledu uživatele. To jsou důvody, proč jsme si právě jeho pozvali do dalšího dílu Kafemlenku, který je zaměřený na výkonnostní testování.

Natáčení jsme rozdělili na dvě části – v této se bavíme o výkonnostním testování obecně – například, jak připravit infrastrukturu, data a na co si při přípravě dát pozor. Druhá se zaměří přímo na Canarytrace – jaké možnosti nám tento nástroj přinese, jak vnitřně funguje a v jakých případech se ho vyplatí použít.

Radim se s námi podělil o řadu zajímavých vhledů do života výkonnostního testera, který spolupracuje s různými firmami na IT trhu. Dozvíte se, že metriky jsou základ každého systému. Základem je také analýza, která nám řekne, které parametry systému jsou žádoucí a kde se předpokládá jeho růst. Analýza také odpoví na to, jaké objemy dat bude nutné připravit a jaké testovací uživatele k tomu využít. Padne také zajímavý fakt, že dobré je v úvodu testování prověřit čistý výkon “prázdné infrastruktury” bez vlastní aplikace, aby bylo možné stanovit “baseline”. Zkrátka jednoduše – drobných tipů a faktů během natáčení proběhne celkem dost. Doufáme, že rozšíří obzory i vám.

Mapy.cz jsou klenotem českého Seznamu a troufám si odhadnout, že neexistuje Čech, který by je neznal. Mnoho z nás je běžně používá ať už pro plánování a navigaci na pěších, či cyklo výletech, jiní i jakou auto-navigaci. Osobně jsem s Mapy.cz absolvoval cestu až do řeckých Atén a offline mapy, mě bezpečně provedly přes několik zemí bez jediného zaváhání. V naší zemi nám Mapy.cz nabízejí mnohem více možností, než konkurenční celosvětoví SW hegemoni jako je Google nebo Apple. Proto mi bylo velkou ctí v Kafemlejnku uvítat Martina Baka, který tým vyvíjející tuto aplikaci vede.

Hned v úvodu se od Martina dozvídáme, že Mapy.cz jsou provozovány v Kubernetes clusteru, frontend je napsán převážně ve vanilla JavaScriptu a pouze jedna izolovaná část je napsána v Reactu. V týmu stále probíhá diskuse, zda-li se vydají cestou Reactu nebo nikoliv – kdysi se používala knihovna JAK, která je v současné době dostupná jako open-source. Data jsou ukládána převážně v PosgreSQL a jeho rozšíření PostGIS. Martin překvapivě tvrdí, že současní vývojáři nemusí nijak zásadně řešit geografickou matematiku, protože ta byla “oprogramována” před lety a od té doby funguje v podstatě beze změny.

Grafické dlaždice jsou uloženy v jedném velikém souboru, kde jsou dostupné na konkrétních souřadnicích. Aktuálně používají 9+9 fyzických strojů na poskytování rastrových dat z výše uvedeného velkého souboru a obsluhují 20 tisíc reqs/sec. Do budoucna plánují postupnou migraci na nové řešení založené na CDN, které Martin v podcastu celkem podrobně popisuje.

Pro vykreslování map používají knihovnu Mapnik a to jak pro vlastní dataset, tak i pro data přebíraná z OpenStreetMap. Na toto téma jsme se pustili i do určitého fabulování na téma schvalování úprav v OpenStreetMap, takže pokud někdo z posluchačů je v této oblasti odborníkem, budeme rádi za upřesnění informací, třeba v komentáři – díky!

Snažíme se z Martina vytáhnout více informací o tom, jak funguje algoritmus pro vyhledání optimální trasy z bodu A do bodu B avšak neúspěšně. Každopádně se dozvídáme, že algoritmus funguje samostatně jak na klientovi (přímo v aplikaci), tak na serveru. Vyhledání trasy tedy funguje i v offline režimu.

Překvapením pro nás bylo poodkrytí způsobu, jak jsou generovány návrhy na výlety v požadované délce. Čekali jsme kdoví jak sofistikovaný algoritmus pro návrhy oblíbených POI, ale vlastně se jedná jen o nalezení okruhu v okolí tak, aby uživatel neprošel 2x stejným úsekem. Plno funkcí, kde jsme čekali nějakou magii, skrývá jen velmi jednoduchá, ale praktická řešení.

Zajímavá je informace o spolupráci s Windy.com, jejímž výsledkem je i pokus o rozšíření českých map do světa pod značkou WindyMaps.

Narazili jsme i na funkce pro monitorování šíření Covidu, která je v mapách stále dostupná a zamýšleli se nad její smysluplností. Tuhle část zde nebudu podrobněji komentovat a doporučuji poslechnutí záznamu od 48 minuty.

Tým pro Mapy.cz stále hledá nové vývojáře. Hledají především Python, C++ vývojáře. Umožňují práci z domu, ale preferují setkávání 2x týdně v Praze. Probíráme, jak vypadá přijímací pohovor do Seznamu a co mohou případní uchazeči při práci v Seznamu čekat.

Zboží.cz asi není třeba dlouze představovat – je to jeden ze stavebních kamenů české jedničky Seznam.cz. Agreguje nabídky zboží a umožňuje vyhledávat zajímavé nabídky skrz rozsáhlý sortiment českých e-shopů. Kombinuje katalog, fulltextové vyhledávání a PPC systém v jednom. Do tohoto dílu se nám podařilo dohodnout rozhovor s Petrem Novákem, který vede vývojáře, kteří mají rozvoj Zboží.cz na starosti. I v tomto případě jsme využili příležitosti a natočili rozhovory hned dva – v příštím díle se budete moci těšit na Martina Baka, který má na starosti Mapy.cz.

Petr Novák nám představil architekturu a způsob vývoje. Dozvěděli jsme se, že Zboží.cz je složeno s desítek komponent (dalo by se říci mikroslužeb) a je provozováno na privátním cloudu Seznamu z Čech. Produktová databáze je v MySQL, kde již naráží na velikostní limity a tak pokukují po Vitess.io a možnosti automatického shardování, které nabízí. Vedle toho používají také Elasticsearch a samozřejmě i vlastní “seznamácké” fulltextové vyhledávání. Zajímavé je, že frontendový index je aktualizován celý – tedy nikoliv inkrementálně, ale je vždy vybudován z nuly.

Kromě PPC části a s tím souvisejícího “účetnictví” je zajímavé načítání a agregace nabídek s tisíců e-shopů, které dohromady tvoří miliony produktů, které se často mezi sebou překrývají. K agregaci je vytvořena umělá inteligence, která v kooperaci s lidskou supervizí a korekcí slučuje nabídky e-shopů do srozumitelných a porovnatelných produktů v katalogu Zboží.cz.

V týmu Zboží.cz najdete vývojáře v C++, Pythonu a frontend je celý v Typescriptu/Reactu, nově se přepisuje na SSR v Next.JS. Pro přesnos dat se historicky používá protokol FastRPC, někde REST API. Poměrně detailně probíráme způsob nasazování nových verzí aplikace, monitoring služeb a další věci, které spadají pod termín SRE.

V Seznamu preferují pravidelné osobní setkání týmů, ale ani jim se v Covidové době nevyhnul částečný full remote. I na to přišla řeč, stejně tak jako na komunikační nástroje, které používají a v závěru probíráme, které pro které role hledají ve Zboží.cz nové vývojáře.

Doufáme, že vás tento díl bude bavit alespoň tak, jak nás bavilo jeho natáčení.

V tomto dílu se s Františkem soustředíme především na zásadní rozdíly v přístupu k vývoji aplikace pro algoritmické obchodování a běžnými enterprise aplikacemi, které pravděpodobně vytváří řada z nás. Františkova předchozí kariéra se odehrávala především v bankovním sektoru v oblasti elektronického bankovnictví. Vývoj podobných webových aplikací si každý z nás v dnešní době už asi umí představit, v případě bankovnictví je práce okořeněná navíc jen větším důrazem na kvalitu výstupu a bezpečnost. Co je tedy tak odlišného při psaní obchodovacího automatu?!

Jednou ze zajímavostí je to, že pokud optimalizujete obchodovací algoritmus na rychlost (latenci), vyplatí se v tomto segmentu znovu vynalézat kolo. Vymýšlení vlastních optimalizovaných řešení, místo použití generických knihoven, může ve svém výsledku přinést v kritických momentech několik mikrosekund náskoku, který umožní algoritmu vyhrát v konkurenci ostatních. František také bez uzardění přiznává, že teprve při psaní algotradingové aplikace se naučil reálně programovat. Teprve tady si skutečně sáhnul na vlastní implementaci B-stromů a řadu dalších low-level datových struktur a algoritmů, které my ostatní používáme zaobalené do high-level knihoven aniž bychom o tom leckdy sami věděli.

Další z překvapivých momentů je ten, že chyba aplikace s potenciální finanční ztrátou, může být pro zadavatele – obchodníky bez problémů akceptovatelná. Pokud na druhé straně dostanou novou verzi aplikace s úpravami, které jim umožní obchodovat s náskokem oproti ostatním a potenciálně vydělat násobně víc.

Dozvíme se, že na první pohled složité optimalizace nemusí v Javě ve výsledku až tak bolet. Jednou formou zpomalení v aplikacích obecně jsou systémová volání kernelu (context switch). Při psaní aplikací, které vyžadují nekompromisní výkon (jakými jsou např. i databáze) se doporučuje minimalizovat počet systémových volání kernelu a co lze si spravovat aplikačně sami. František zmiňuje existenci síťových karet, které si umí samy generovat časový otisk (dotaz na aktuální čas totiž obvykle vyžaduje právě systémové volání) a možnost vyjmout síťovou kartou ze správy kernelem a spravovat si ji nativně aplikací přes C knihovnu implementující TCP/IP stack. Tímto způsobem je možné se dostat i na řádově lepší rychlosti.

Věříme, že tento druhý díl, pohladí na duši všechny tech-geeky mezi našimi posluchači.

Tento díl vám přináší Luhačovická pražírna kávy. Kávové předplatné můžete spolu s Feršem a Novojem vychutnávat společně. Při zadání slevového kódu “kafemlejnek” v košíku dostanou naši posluchači exklusivní slevu 15%.

Námět na tento díl vznikl na loňském ročníku jOpenSpace, kde měl František Řezáč skvělý offline příspěvek o zvláštnostech psaní algoritmických automatů pro obchodování na energetické burze. Vzhledem k tomu, že byl tak zajímavý a zároveň nebyl zaznamenán, jsme se v Kafemlejnek.TV dohodli, že tyto zkušenosti nasdílíme přes náš kanál.

V prvním díle našeho rozhovoru s Františkem se snažíme nejdříve proniknout do specifik vlastních burze s energiemi a především Ferš hosta trápí svými dotěrnými otázkami, které pramení z jeho zkušeností s fotovoltaikou na domě. Pokud vás zajímají čistě IT informace, přeskočte rovnou na druhý díl z této série, kde se budeme už skutečně věnovat pouze programování. V tomto se dozvíte, jak jsou producenti a spotřebitelé energie trhem incentivizováni dodržovat plánované dodávky a odběry elektřiny, jak se měří a rozpočítává spotřeba elektřiny a jak se odhaduje spotřeba na základě historické zkušenosti a diskrétních odečtech. V řadě detailů nebudou informace dostatečně přesné, ale pro naše účely jsou dostačující. Energetika je skutečně velmi složité odvětví s klíčovým dopadem na naše životy, a proto by mohl být tento náhled na tuto problematiku užitečný i pro vás.