Podcast

Tady je opravený text s odstraněním gramatických a stylistických chyb:

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Datatalk. Mým dnešním vzácným hostem je Ondřej Stuchlík, spoluzakladatel a CTO Datamallu. Ahoj Ondro.
Ahoj Jirko, díky za pozvání.

Dnes se podíváme do Datamallu, protože je to česká firma, která byla dlouho nenápadná a vyrostla na více než sto lidí. Dělá velmi zajímavé use case, které si myslím, že žádná jiná firma v Česku nedělá. Na tenhle díl se proto moc těším.

Začněme tedy na začátku. Ondro, jak ses dostal k datům, jak vlastně vznikl Datamall a kde to všechno začalo?

Tak jo. Počítače jsem do nějakých dvaceti let moc neznal, respektive jsem na nich hrál možná nějaké hry, ale k softwarovému inženýrství nebo vývoji software jsem se dostal až na vysoké škole. Původně jsem šel na ČVUT do Prahy na strojní fakultu, chtěl jsem se věnovat strojírenským technologiím a managementu.

Ve druháku nás ale začali učit programovat v C, a mě to hrozně chytlo. Začal jsem si o tom zjišťovat spoustu věcí a měl jsem kamaráda z Gimplu, který mě tehdy po ICQ rád radil.

Wow.
Jo, přesně tak — radil mi, jak dělat for-cykly, ify a podobně. Já jsem mu to pak lepil několik dní. Měl jsem navíc štěstí, že na koleji mi řekl kamarád, že na FEL České vysoké školy technické na elektrofakultě je obor nazvaný „Softwarové technologie a management“. Říkal jsem si: „Aha, já teď studuju strojní a management, tady je softwarový management a ten software mě baví – jak moc to asi bude jiné?“

Jediný problém byl, že už běžel semestr, takže jsem potřeboval během roku přestoupit. Podařilo se mi to, chvíli jsem studoval současně obě fakulty, ale po půl roce jsem zjistil, že programování a vývoj software je to, co mi je blízké, takže jsem strojní fakultu ukončil a pokračoval na elektrofakultě.

Na FEL jsem potkal kamaráda Fandu Páce, se kterým jsme se ve třetím ročníku přidali k firmě EB. Programovali jsme v Javě, dělali javovské systémy, například software pro žižkovské divadlo Járy Cimrmana.

Tak jsem přišel k programování jako takovému a naučil jsem se, co obnáší vyvíjet software, který někdo koupí, nasadí a používá.

První systém, který jsem nasazoval, byl opravdu za provozu – bylo to v divadle, kde stála obrovská fronta lidí, kteří si chtěli koupit vstupenky. Byl jsem u toho, když nasadila software, který chvíli nefungoval a my jsme ho museli opravovat. Byl tam velký tlak, protože jsem viděl ty lidi — nebyly to jen nějaké grafy a metriky jako u monitoringu, ale skuteční lidé ve frontě, kteří čekali a chtěli, aby to fungovalo.

Instantní feedback.
Přesně tak, byla to hodně tvrdá škola, ale hodně mi to dalo. Takže to byly moje začátky jako profesionála.

Pokud budete chtít, mohu pokračovat dál nebo upravit i zbytek textu.

Opravený text:

álního, no asi ne profesionálního, jako placeného programování v Javě, abych řekl. No a my jsme vlastně postupem času přecházeli z té Javy, vlastně z toho standardního javovského stacku, na Ruby on Rails, a to pro mě byla velká škola, protože Ruby on Rails byl systém, který byl hodně spjatý s Linuxem, vývoj tam šel dobře na všech unixových systémech, takže to byla vlastně věc, kde jsem přičichnul k Linuxu, začal jsem si i na svém počítači rozběhnout Linux a začal jsem opravdu low-level zkoumat i ten operační systém. Ze školy jsem měl spíš programovací věci, ale co se týká administrace, Linuxových admin věcí, tak to mě vlastně k tomu přivedla tato část.

O jakém roce se bavíme? S Ruby on Rails zrovna je…

Byl Twitter ještě na Ruby on Rails? Já nevím, jestli byl nebo nebyl, ale bavíme se o nějakém roce 2011 třeba. Jo, 2010, 2011, už je to skoro 15 let. Ale mě to hodně dalo, protože jsem si na Linuxu zjistil, že každý příkaz, který tam napíšu, můžu opravdu zjistit, co dělá. Věděl jsem, že pomocí nějakých příkazů vždycky zjistím, která věc se na tom systému spouští a jestli je to skript nebo binárka. Fakt jsem si ladil i low-level, co se stane, když napíšu takovýhle příkaz, co to fakt udělá. Under the hood, jaké soubory to změní, jaké executables to spustí. A tím, že jsem měl ve škole i runtime systémy, zajímaly mě i virtuální stroje, jako Java Virtual Machine, interpreter Ruby on Rails nebo Pythonu. Tak se to všechno spojilo dohromady a já jsem vždycky chtěl vědět přesně, co ten počítač dělá.

Nikdy jsem nepotřeboval úplně assembler, ale vždycky jsem potřeboval vědět, co to dělá. Tak to bylo vlastně e-bill. No a potom jsem odešel, protože jsme s Fandou už nechtěli firmu dál škálovat. Tak jsem šel dál a chtěl jsem zkusit nějakou velkou firmu. Šel jsem do Barclays Capital, kde jsme opět vyvíjeli v Javě, tedy javovské systémy pro tradování městských dluhopisů na New Yorské burze.

Celkem skok, co? Ano, přesně, celkem velký skok. Ale říkal jsem si, jaké to je dělat Javu v large scale, jak moc je to jiné, než jsme dělali my, když jsme to vlastně vyrostli jako kluci na FELu, potom na FITu na informatice. Jak moc je to jiné ve velké firmě?

A jak moc to bylo jiné?

Zase tak moc ne, protože frameworky tenkrát – to byla doba, kdy ještě frčel Spring framework a Hibernate. Ale architektura byla velmi podobná. Když se na to zpětně podívám, nebylo to nic moc zajímavého. Byla tam prostě nějaká relační databáze, která měla master-slave replikaci, nad tím běžel nějaký springový javový klient a pak frontend. Takže z dnešního pohledu vlastně nic moc zajímavého.

Ale aspoň si člověk říkal, hele, tak nedělali…

Pokud chcete, mohu upravit text ještě víc do plynulejší češtiny, dejte vědět.

Jsme to nějak úplně blbě napsali. To, co jsme se naučili, vlastně vypadá docela zajímavě.

V tu dobu mě kontaktoval můj kamarád, spolužák a kolega Tom Borovička, se kterým jsme spolustudovali na FELu. Potom jsme oba přestoupili na FIT, což byla nová fakulta informatiky, která tehdy vznikla.

S Tomem jsme spolu hrávali squash. Byl tam skvělý předmět „Squash relax“, který zahrnoval squash a saunu, tam jsme spolu hrávali a později jsme spolu studovali i na státnice, protože nám vždycky dobře šlo společné přemýšlení. Dokonce jsme spolu, jak jsem zmiňoval, navrhovali vlastní programovací jazyk v rámci předmětu „runtime systémy“ a zjistili jsme, že nám spolupráce docela jde.

Počkej, ještě neskočím k pointě — navrhovali jste vlastní programovací jazyk?

Jo, jo. Ten předmět na FITu, runtime systémy, nám umožňoval vyzkoušet si vytvořit vlastní programovací jazyk s kompilátorem a virtuální stroj, který jazyk interpretuje.

Takže jazyk, ne framework?

Ano, jazyk. Vlastně fakt programovací jazyk, jmenoval se NULOG. Navrhli jsme jeho syntaxi, vytvořili překladač do bytekódu a interpret pro tento bytekód – něco jako Java nebo Ruby, samozřejmě v mnohem menším a jednodušším rozsahu, ale přesto malou variantu takového systému jsme si vyzkoušeli. Toto jsme dělali spolu s Tomem.

Takže jsme věděli, že nám spolupráce docela dobře funguje a Tom mě kontaktoval, jestli bych nechtěl založit s ním firmu zaměřenou na machine learning. Tenkrát se ještě neříkalo AI, říkalo se tomu machine learning – znělo to hezky.

Říkal jsem si, že je to docela dobrý nápad, protože FinTech a trading, zvlášť high-frequency trading, moc přidané hodnoty nepřináší. Když jsem pracoval v Barclays, zjišťoval jsem, jestli jsou finanční trhy zero sum game, nebo jestli high-frequency trading skutečně vytváří nějakou hodnotu. Došel jsem k závěru, že kromě liquidity trhu to světu moc nepřináší. Takže jsem si říkal, že machine learning by mohl být zajímavější oblast, kterým se věnovat.

Je to něco, co může posunout lidské poznání o kus dál a třeba udělat svět lepším, s větším dopadem. Tak jsem o tom nadšeně mluvil s Tomem a i když jsme nevěděli, jak to bude vypadat a jak to poroste, řekli jsme si, že do toho půjdeme. V roce 2015 jsme tak založili Datamall.

Jaké byly tvoje první zkušenosti s machine learningem v té době?

To je dobrá otázka. Moje zkušenosti byly téměř nulové. Před založením firmy jsem se… (pokračování textu).

Opravený text:

Ptal jsem se na machine learning, protože jsem viděl, že Tom to dělá. Tom vlastně studoval v Holandsku, nebo tam byl na internshipu, a dělal doktorát, přičemž se tehdy věnoval machine learningu. Jeho zkušenosti byly velké a tenkrát to bylo z větší části v MATLABu. Pythonový Scikit Stack ještě nebyl tak profláklý, takže spoustu věcí dělal v MATLABu nebo v Octavu, což byla open source verze MATLABu na Linuxu. No ne úplně totéž, ale open source verze s podobným cílem. Já jsem tehdy uměl machine learning jen trochu, měl jsem za sebou jeden kurz na Courzeře, pokud si dobře vzpomínám. Ale nevadilo to, protože jsme si s Tomem velmi rychle rozdělili práce – já jsem se soustředil spíš na data engineering a on byl lead v machine learningu.

Co se týče našich zkušeností, oba jsme inženýři srdcem. Já jsem měl zkušenosti, jak jsem popisoval, a Tom dlouhou dobu programoval v .NETu a C#. Vždycky jsme se trochu pošťuchovali, protože on dělal .NET a já Java, a říkali jsme si, co je lepší a co horší, ale vlastně jsme měli dobrý základy v obou platformách.

Pak přišel Python a všechno bylo v pohodě. Ačkoliv v .NETu mám stále spoustu věcí, které jsou vysoce výkonné a potřebujeme je využívat.

Tohle byly naše zkušenosti. Měli jsme také velké zkušenosti s fakultou. I když jsme zakládali Datamol, první kanceláře jsme měli na fakultě. Jsme stále silně spojení s Fakultou informatiky ČVUT – jsme partnerem a pořád tam i učíme. Už před Datamolem jsme oba učili na FITu. Já jsem tam učil už ve čtvrtém ročníku na vysoké škole základy algoritmizace pro bakaláře. Poté, když jsem dokončil FIT a měli jsme firmu EB, učil jsem objektové programování. Také v Datamolu jsme měli předmět distribuovaný data mining, takže stále máme silnou vazbu na naši Alma Mater.

Samozřejmě jsme se z fakulty museli brzy přestěhovat, ale tohle byly naše zkušenosti – měli jsme zkušenosti s profesionálním programováním, a chápeme, jak věci zjednodušovat či odhazovat. Také jsme uměli vysvětlovat technické a složité témata někomu dalšímu, a to nás vedlo k hlubokému pochopení věcí do hloubky. Připravovat a učit nějaký předmět nás vždycky donutí věci opravdu dobře zvládnout.

To nás vždy spojovalo, protože jsme chtěli rozumět věcem na dřeň. Když chceš něco prezentovat, musíš tomu opravdu rozumět. Přesně tak.

Prezentovat bych možná dal já, ale nerad bych, aby někdo na mě kladl otázky.

Takže roku 2015 vzniká…

Datamall. Hurá, tak jste to založili a teď sedíte v těch kancelářích. No, myšlenka založit Datamall byla podpořena, nebo vlastně iniciována tím, že Tom, jak jsem říkal, odjel na stáž do Holandska. Měl tam internship ve firmě Lely, což je holandská společnost, která vyrábí automatizované robotické farmy. Byli to naši startovací klienti a dodnes jsou pro nás vlastně největším klientem a partnerem.

Když jsme Datamall zakládali – mimochodem, moc gratuluju, 10 let s jedním klientem, to znám málokterý případ – my jsme tomu věřili a určitě si o tom ještě povíme. Vždycky jsme přijímali dlouhodobou spolupráci, ten partnership s Lely je pro nás velice důležitý.

Když jsme Datamall zakládali, nebyli jsme tam jen já a Tom, ale i třetí člověk, Eymof van Halssema. Ten tehdy vedl oddělení v Lely a poznal se s Tomem v Holandsku. Říkal: „Když tu budeme dělat tyto věci, zejména co se týče machine learningu,“ protože tehdy se toto odvětví teprve rodilo, byl to velký trend. Eymof je vědec a zároveň chytrý inženýr, který už tenkrát viděl potenciál těchto technologií v byznysu a měl i dobrý přehled o byznysových procesech. Dokázal proto vnímat, že by v Lely mohli dělat velké věci v této oblasti.

Jeho nápad, nebo spíše jeho podnět, byl pro Toma motivací: „Když nechceš zůstat v Holandsku a chceš se vrátit do Čech, co takhle založit firmu, která pro Lely bude tyto věci dělat?“ Takže takhle to všechno začalo a tak vznikl Datamall.

Takže ze začátku jsme byli tři, s prvním klientem a prvním kontraktem – to je úžasné. Asi se pojďme podívat blíže na Lely, protože jsme tady v podcastu měli Honzu Kučeru, bylo to už před dvěma lety, a i když šlo o malou firmu, bylo vidět, že sázka na specializaci a SaaS se vyplatila. Tak pojďme se podívat, co děláte pro Lely, protože to je případ, který rádi vyprávíte. Já jsem ho slyšel několikrát, ale vždycky rád znovu, protože mi přijde naprosto úžasný.

Jo, to je hezké. Na tom příkladu můžu ukázat, jak jsme vyrostli a co jsme si mysleli, že budeme pro Lely a další firmy dělat, a jak to nakonec dopadlo. Mysleli jsme si, že klient přijde s krásným datasetem a my budeme dělat jen data science. Přijdeme s obrovskými daty, z nichž si vyvineme trénovací machine learningové algoritmy, které budou distribuovaně fungovat.

Tenkrát byl Apache Spark ve verzi 0.9, když jsme začínali, ale už obsahoval nějakou ML knihovnu, která základní algoritmy jako K-Means uměla distribuovaně zpracovávat. Takže bylo možné vzít…

Opravený text:

Mít 10 výpočetních uzlů a spustit K-Means na obrovském datasetu, který by se ti na jeden počítač nevešel, zní dobře. Jenže tak to samozřejmě nebylo, že by klient za námi přišel s obrovským a krásným datasetem – čistým, kvalitním, dobře popsaným, s labely všude. My jsme měli náš „hell engine“, což byl set algoritmů, který uměl běhat na výpočetním klastru. Spustili jsme ho, měli jsme krásnou automatizovanou pipeline, kde jsme data předpracovali, vyčistili, udělali feature engineering, následovalo modelování, a pak jsme klientovi naservírovali hotový model. Mělo to přinášet hodnotu a být jednoduché – nic jiného bychom nemuseli dělat, jen ladit ten „hell engine“. Ten byl postavený nad Scalou, protože Apache Spark je postavený ve Scale a tenkrát, pokud se nepletu, ještě neměl Python interface, přes který se to dnes používá. Vývoj ve Scale, funkcionálním jazyce, který neumí každý, byl náročný, ale my ho uměli, takže jsme si mysleli, že máme skvělý nástroj.

Velmi rychle jsme ale zjistili, že to takhle fungovat nebude. Ze specializace na datovou vědu a předpokladu, že engineering je jen kvůli tomu, aby se algoritmy daly spouštět na velkých klastrech, jsme přešli k poznání, že je potřeba dělat i data engineering – tedy sbírat data. Vždy platilo „data beats algorithms“ – když máš více dat, i jednodušší algoritmus dá lepší výsledky. Uvědomili jsme si, že musíme více energii věnovat tomu, jak data sbírat a jak vůbec vytvořit dataset, na kterém můžeme modelovat. A tak jsme začali…

Vznikal Data Engineering Department v DataMoolu, který nyní i vedu. V DataMoolu mám několik rolí – jsem CTO, architekt a vedu právě tento Data Engineering Department. Už při sběru dat jsme dokázali přinášet hodnotu, ale zjistili jsme také, že náš proces není tak úplně end-to-end – je třeba posunout obě strany procesu dál. I když modely měly dobré výsledky, bylo nutné výsledky dobře doručit uživateli. Když je mezi tím třetí strana, která to nezintegruje správně, nebo aplikace, do které se model integruje, není ideální – řekněme, že je suboptimální –, pak i ten nejsofistikovanější engineering, kdy ses třeba vysbíral pár dat, vytvořil skvělý model, nemusí uživateli nic přinést.

Zde je opravený text s lepší srozumitelností, gramatikou a stylistikou:

Je to s aplikací, která vlastně nefunguje dobře, takže tě to celého potopí. Tak jsme řekli: „Hele, potřebujeme ještě třetí věc,“ a to byl tým, kterému jsme říkali UI department, protože jsme si mysleli, že budeme řešit uživatelské interakce celkově v různých módech. Dnes tomu ale říkáme Application Development Department. Prostě jsme potřebovali mít i pod vlastní kontrolou to, jak se výsledky modelů dostanou k uživateli. Takže vznikl Application Development Department.

A nedávno jsme navíc zjistili, že ideální je mít pod kontrolou i embedded software, který běží na zařízení, takže teď už máme i vlastní vývoj embedded engineeringu. K tomu se asi ještě dostaneme, protože tam je dost zajímavých témat. Ale to, na co jsem chtěl navázat, je, abys nám řekl něco o Lely.

Jo, přesně, díky, že mě vracíš zpátky k tomu, to si dobře děláš. Máš tam několik super témat, pojď nám to ukázat právě na Lely.

Super, tak já vezmu jeden konkrétní případ. Když víme, že škála je tak široká – od zařízení přes cloud engineering, sběr dat, modelování až po prezentaci – řeknu jeden případ, který považuji za hezký. Chtěl bych tu také sdělit něco třeba mladším kolegům, kteří přemýšlí, jestli jít do data engineeringu. Chtěl bych ukázat, že data engineering není jen sbírání dat například z banky, nebo z SAPu – tedy tabulek s transakcemi, objednávkami, poté spuštění ETL procesu, uložením do datového skladu a vytvářením BI reportů pro finanční nebo skladový reporting.

Chtěl bych ukázat, že data engineering může být mnohem zajímavější a širší, a ilustroval bych to na příkladu Lely. Lely má jedním ze svých vlajkových produktů dojíci robot, který je plně automatizovaný. To znamená, že zvířata mohou chodit k robotu, kdy chtějí, což je hlavní přínos v rámci Animal Welfare – zvíře se volně pohybuje po farmě a není závislé na tom, kdy přijde farmář něco udělat. Roboty na farmě vlastně slouží a zajišťují chov takzvaně 4.0. Tyto roboty mají hodně nastavení, a optimální nastavení nelze určit jednoduše najednou, protože každé zvíře je živý organismus a každé potřebuje trochu jiný přístup. Pro každé zvíře je to jiné, takže neexistuje jedno univerzální nastavení robotů, které by Lely mohla nastavit všem farmářům. Nastavení je potřeba ideálně personalizovat – nebo lépe řečeno „animalizovat,“ protože to není člověk, ale zvíře – tedy nastavit ho na míru konkrétnímu zvířeti.

Co k tomu potřebuješ…

Pokud chceš, mohu pokračovat a dokončit text, stačí říct!

Jasně, tady je opravený text s lepší srozumitelností a plynulostí:

Eš? Jak může vypadat ten stack? Jen tak pro doplnění – já mám farmu, tam zvířata, která dojím, tedy asi nejčastěji krávy. Ano, přesně tak, krávy. Stojí tam i ovce. Je to především na krávy. Říkáš tedy univerzálně – mám farmu, mám tam kravičky, které doju, mám tam automatický dojící stroj, který je také česá, dávají jim trávu. To znamená, že na farmě je víc robotů: někteří dojí, jiní krmí, další uklízejí a další třeba jídlo přistavují. Celý systém tak představuje robotizovanou farmu.

V ideálním světě dat pak dokážeš informace z těch různých robotů kombinovat a řídit jejich vzájemné interakce. Skvělé! A kravička chodí volně po farmě, řekne si: chci se podrbat, chci se podojit, chci se najíst. Ano, to je vlastně přidaná hodnota – zlepšení animal welfare, protože ten pohyb a interakce jsou přirozené a dobré pro zvíře.

Je tu ještě jedna věc, která je docela logická, ale zároveň krásná – alignment kapitalistického, tedy ziskového cíle, s etickým, tzv. zvířecko-právním přístupem. Šťastné kravičky dávají víc mléka. Přesně tak. Když se dělají optimalizace robotů, bere se v potaz, aby zvíře bylo zdravé, zároveň aby nastavení nebylo jen „sluníčkářské“, ale i aby robot byl efektivně využitý a nebyl podvyužitý.

Teď si představím krásnou, sluncem zalitou farmu plnou šťastných kraviček. Pojďme se podívat na data a inženýrství. Jak to vypadá?

Data engineering nemusí být jen sběr objednávek nebo transakcí a tvorba ETL do datového skladu s reportingem. U takového systému, o kterém mluvíme, je třeba si představit desítky tisíc dojících robotů, možná až stovky tisíc po celém světě. Roboti nejsou kdekoliv, ale na farmách – na každé farmě (každém „site“) jsou různá zařízení a zároveň nějaký edge computing. Některé výpočty probíhají přímo na robotech, jiné na „edge“ zařízeních a další v cloudu.

Když chceš dělat personalizovaná nebo zvířecí specifická nastavení robotů, ukazuje se, že není efektivní mít jeden obrovský model, který optimalizuje všechna zvířata dohromady. Mnohem lepší je trénovat modely na úrovni jednotlivých „site“, protože podmínky se mohou lišit podle umístění zvířat a dalších faktorů.

Pokud chceš, mohu upravit text ještě víc nebo shrnout. Dej vědět!

Tady je opravený text:

A nevím proč, jen vím, že různá zvířata po světě potřebují různá nastavení. A tím pádem může pipeline fakt vypadat tak, že potřebuješ trénovat tisíce modelů denně. Protože my opravdu máme machine learning model per každou farmu (site). Pro každou farmu se udělá model, který funguje dobře v daném kontextu.

Takže si můžeme představit systém, kde je kolem 100 tisíc robotů po světě, v přibližně 30 tisících lokalitách. To znamená 30 tisíc edge computing nodů, kde máme nasazený systém nazvaný Data Gateway. Protože všechny ty farmy nemají optické připojení nebo Wi-Fi, na která jsme zvyklí, na spoustě míst může být připojení drahé nebo nestabilní. Třeba na Novém Zélandu jsou často satelitní připojení.

Takže je to úplně jiný typ inženýrského řešení, než když jsi zvyklý, že vše běží v cloudu na gigabitovém optickém připojení. Potřebuješ tyto datové Gateway, které řeší přerušovanou konektivitu. Máme tedy nasazeno těchto 30 tisíc systémů, které sbírají data do cloudu, kde běží umělá inteligence, dnes se spíš říká machine learning. Ale není to jen inference, které pak posíláš zpět do robota, ale i přetrénovávání modelů. Tedy mluvíme o tisících modelech denně.

Co se mi líbí, je ten zpětný feedback loop. Model neoptimalizuje, aby srovnal reklamy nebo správně nabídl hypotéku, ale fakt, aby výstup byl opravdu optimální pro dané zvíře, a pošle zpět robota s novým nastavením. Robot se překonfiguruje a loop pokračuje, optimalizuje se dál a dál.

Myslím, že tento případ není jenom váš nejznámější, ale je i dost definující, protože když se podívám na to, co děláte a v čem jste fakt specifičtí, jak jsem říkal v úvodu, neznám druhou firmu v Česku, která by měla takovéhle případy a specializaci. Přijde mi, že to není náhoda. Kdybyste třeba první měli banku, dnes byste dělali banky, ale díky tomu, že jste měli Lely a působili jste v zemědělství, jste hodně blízko fyzickému světu.

Zase, jak vzpomínám na Honzu Kučerů, IoT a On Devices, Edge Computing jsou klíčové – potřebuješ optimalizovat připojení, datové toky, nejsou tam standardy, je to hodně inženýrská a embedded práce. To všechno se mi zdá velmi příznačné.

Začali jste někdy kolem roku 2015 ve třech lidech s jedním klientem. Udělejme rychlý posun do roku 2025 – co je Datamol dnes? Začali jsme ve třech, pak rostli do pěti, devíti lidí, dnes nás je přes sto, nejsme jenom v…

Pokud chcete, můžu text ještě víc upravit podle stylu, naformátovat nebo zkrátit.

Tady je opravený text:

V Praze, ale jsme i v Brně a máme také kancelář v Českém Krumlově. Kdyby někdo chtěl v Českém Krumlově pracovat a zajímá ho engineering, může se přidat. Jak jsi říkal, ten fyzický svět nás opravdu hodně definuje. Říkáme, že pomáháme našim klientům inovovat pomocí technik umělé inteligence a data engineeringu, ale neděláme to jako všude jinde. Neděláme telco, neděláme banking, neděláme marketing. Děláme věci, které jsou… To je skvělé. Když bych vzal professional services na českém trhu a i tady v datatolku a měl bych říct jejich specializaci, tak by to bylo právě banking, telco, marketing, salesová data. My to ale neděláme. Vždy říkáme, že jsme engeneers by heart a líbí se nám, když můžeme vidět, jaký fyzický device je za modelem, který děláme. Dokonce, když dokážeme použít nějakou znalost fyzikálního fenoménu při modelování dat, je to pro nás výhodou.

Proto se nám líbí, když za daty je fyzické zařízení a když existuje fyzika, kterou můžeme využít při vytváření modelů. Samozřejmě, pokud má člověk hodně dat, hluboké neuronové sítě si tu znalost dokážou najít samy, ale ve spoustě případů tolik dat nemáš. Jakákoliv doménová znalost, kterou do modelu přineseš, je obrovsky cenná. Teoreticky by ji člověk nepotřeboval, ale prakticky často dat není mnoho – například pokud neděláš user clicks nebo netrénuješ large language modely, kde máš data z celého internetu, ale máš data z měření, která někdo musí udělat v laboratoři. Ty data prostě nebudeš mít tolik, a proto do modelu musíš dostat nějaká pravidla, nějakou doménovou znalost. My jsme za to vždycky vděční, když ji můžeme použít.

Jak říkáš, nás definuje to, že děláme v podstatě IoT, Industrial Internet of Things. Sbíráme data, naše datové toky jsou obvykle z nějakého deviceu. Nemusí to být jen dojící robot, jak jsme zmiňovali. Máme například velkého klienta Thermo Fisher Scientific, který pracuje s elektronovými mikroskopy. Další device může být elektronový mikroskop. Zařízení může být i mnohem jednodušší, třeba chytrý kávovar.

Směju se, protože mě napadnul Červený trpaslík – nedal bych si toast. Jak moc chytrý asi můj kávovar může být? Ale hej, on je zase trochu chytrý, když jde dělat prediktivní údržba. Firma, která prodává coffee as a service, ti ten kávovar neprodá, ale dá ti ho třeba na benzínce a pak ti jen účtuje poplatek za každé uvařené kafe.

Jasně, jako domače. Ano, přesně tak. A tím pádem, když jsi ta firma, která takhle dost strká ty kávovary po světě, chceš, aby neměli downtime, takže chceš třeba vědět, kdy se ten kávovar rozbije. A samozřejmě chceš mnohem jednodušší use case. Nejdřív chceš umět dělat ten billing, že jo? Chceš vidět,

kolik těch kafí se tam uvařilo. Takže to může být taky třeba device. Nebo zajímavý projekt, na kterém pracujeme, se jmenuje FreshAid. Cílem toho projektu je zjistit zralost ovoce – jaké ovoce je zralé – a udělat to neinvazivní metodou. Protože když máš třeba nějaké třídící linky, chceš být schopen rozdělit ovoce do různých beden podle toho, jak dlouho ještě má dozrávat. Nebo chceš zjistit, jestli nějaký kus není shnilý, abys ho vyndal, aby ti neskazil celou bedýnku.

Jo, chápu. A hlavně, jsem zvědavý, kam jste to dostali, protože pořád čekám na zdravá avokáda a manga.

Jo, ano, přesně. Model pro mango je přesně věc, na které teď pracujeme. Je to grantovaný projekt, takže o něm můžu konkrétně mluvit. A přesně, chceš testovat zralost ne tak, že ovoce rozřízneš – každých padesát kusů – a zjistíš, jestli je ideální, ale chceš pomocí nějaké neinvazivní metody přiložit anténu, pustit do toho impuls a na základě impulsní odezvy z elektroimpedanční spektroskopie, což je taková jednoduchá řada závislosti frekvence, kterou do ovoce pustíš, zjistíš, jaká tam je odezva. Dostaneš z toho křivku a podle tvaru křivky se snažíš predikovat, jestli je ovoce shnilé, nezralé, zralé, a podle toho to třídíš.

Takže to je zajímavá věc, kde se dá využít dost znalostí z fyziky. Když dostáváš zpět tu křivku, a kdybys měl miliony takových křivek, neuronová síť by se naučila sama, které frekvence má zpracovat a které ignorovat. Ale víš co? Aby ses dostal k těm měřením, někdo musí mango změřit, pak ho rozříznout a zkontrolovat, jestli je zralé, udělat například refraktometrem test, kolik je v něm cukru. To jsou všechny drahé štítky (labely). Často v těchto případech, když netrénuješ na obrovském datasetu z internetu, ale snažíš se vytvořit transferovou funkci z raw dat, která naměří nějaký senzor, na hodnotu, kterou chceš predikovat, jsou ty štítky hodně drahé na získání. Proto pak potřebuješ co nejvíce doménových znalostí, aby modelu pomohly získat zajímavé výsledky i z malého množství dat.

Takže to je jeden zajímavý projekt, který děláme dnes, abych nastínil co nejvíce úhlů pohledu, co se dá dělat v data engineeringu nebo v tomto datovém oboru.

Jasně, tady je opravený a stylisticky upravený text:

Aspekty data science a data engineeringu jsou velmi zajímavé, zvlášť v kontextu konceptu, který se nazývá in silico modeling. Tento termín pochází z biochemie, kde se používá označení in vivo (výzkum v organismu) a in vitro (výzkum ve zkumavce). In silico modeling znamená, že se něco zkoumá v křemíku, tedy digitálně. Jde vlastně o tvorbu digitálních modelů, které například ve foodtechu dokážou predikovat, co se stane, když smícháš tři, čtyři nebo pět ingrediencí v různých poměrech.

Například chceš zjistit, jak se bude chovat shelf life – tedy jak dlouho bude potravina skladovatelná, jak se bude vyvíjet za měsíc, dva, tři, zda se vytvoří nějaké hrudky, změní barva, nebo zda se třeba nevyvinou bakterie, které překročí povolený práh a produkt už nesmíš prodávat.

Toto všechno bys bez in silico modelingu musel testovat klasickým způsobem – smíchat ingredience v různých poměrech, udělat třeba stovku vzorků, uložit je na sklad, pravidelně je kontrolovat, fotit, pozorovat vývoj. Jsou to velmi nákladné a časově náročné procesy.

Naopak s modely, ideálně vyvinutými strojovým učením, by bylo možné tyto procesy výrazně urychlit, ale potřebuješ mít hodně dat, abys správně zachytil chování složitých fyzikálně-chemických systémů. Další možností je spolupráce s doménovými experty, kteří pomocí sad diferenciálních rovnic (představ si tisíce řádků textu s rovnicemi) popíší, jak se systém chová při kombinaci různých ingrediencí. Ty pak můžeš model numericky řešit a dostaneš předpověď, jak se potravina bude chovat.

Tento přístup ale není úplně jednoduchý – podobně jako při předpovědi počasí, kde je spousta parametrů a konstant, které je ještě potřeba doladit.

Proto je dobré použít machine learning – díky datům získaným v laboratoři můžeš mít počáteční matematický model postavený na znalostech foodtech nebo biotech inženýrů a následně pomocí ML optimalizovat konstanty a parametry modelu. Tím „dojedeš“ poslední míli k dostatečně přesným predikcím.

Tento přístup krásně spojuje fyzický svět a digitální modelování s praktickou aplikací – například při tvorbě nových zdravých potravin. Jeden z pěkných případů uvedla společnost Hellmann’s, která publikovala případ, kdy vyvinuli veganskou majonézu čistě na základě in silico modelování. Výsledek nevznikl přímo kreativní činností food inženýrů, ale algoritmem, který navrhl kombinace ingrediencí a jejich poměry tak, aby měla majolku daný shelf life a další požadované vlastnosti.

Tohle je podle mě skvělý příklad, jak se tyto technologie spojují a přinášejí inovace.

Pokud chceš, mohu ti pomoci i s další stylistickou úpravou nebo zkrácením textu.

Jasně, tady je opravený text s úpravou gramatiky, interpunkce a čitelnosti, při zachování původního významu:

Jak daleko je to od bankovnictví a zpracovávání BI reportů? Je to skvělé. Takže foodtech, agritech, klasický průmysl? Ano, přesně tak. To je přesně ten záběr, který nás zajímá – tam, kde je hodně fyziky.

Říkal jsi, že vás je 100 a že teď už máte… Pojďme k těm oddělením, protože ty use cases a problémy, o kterých mluvíš, nebo zadání, jsou opravdu zajímavé. Přemýšlím, jaký na to potřebuješ tým. Jestli máte skupinu odborníků na shelf life, kteří přijdou, a zároveň mezi nimi je jeden data scientist a tři matematici. Jak takový tým postavíš?

Jo, jo, jo. Ta doménová znalost, o které mluvíš, je fakt klíčová a důležitá. My máme třeba v tomhle obrovskou výhodu, že náš spoluzakladatel AIMO je zároveň biotech inženýr, takže rozumí doménové problematice a má dostatečný přesah do software engineeringu, aby to dokázal i správně namapovat. Takže tam to máme takto vyřešené.

Jinak je to určitě obrovská výzva – vždycky najít u klienta protějšek, tedy subject matter experta (SME), který přesně rozumí dané oblasti. S klienty samozřejmě dlouhodobě spolupracujeme, abychom my jako data scientisti a data inženýři nasáli dostatek jejich doménové znalosti. Díky tomu dokážeme porozumět oběma stranám, mít přesah a nemít žádný slepý bod, což nám umožňuje vyvinout řešení, které opravdu funguje.

Tým funguje tak, že, jak jsem říkal, máme vše od embedded až po application development. Začínáme tím, že dokážeme data z zařízení sbírat, nainstalovat nebo vyvinout software, který ta data ze zařízení nasbírá. To může být zařízení s embedded Linuxem nebo i zařízení bez operačního systému, běžící „bare metal“, kde prostě nějaká smyčka čte data z registrů.

Takže to je první část – embedded. Na to máte samostatný tým? Ano, přesně tak, máme na to samostatnou divizi. Kolik lidí má tahle jednotka? Jak ji nazveme? Ať už jakýkoliv label, tak to je prostě embedded.

Moje otázka je, kam se posunul trh s IoT? Pár let zpátky, před 8–10 lety, to byla ta „next big thing“, IoT, edge computing – velký buzz. Všichni říkali, že internet věcí bude všude, že s námi budou komunikovat křižovatky, chytrá auta a že doprava v Praze bude z poloviny autonomní. Ano, to byl velký příslib.

Nicméně narazilo to na spoustu problémů, typicky na standardizaci. Jak je to dneska? Posunula se standardizace, nebo ne?

Myslím, že ano. Hlavní standardy, které tu byly už dříve, byly třeba MQTT, což většina lidí zná jako…

Pokud chceš, mohu text doplnit nebo upravit dál.

HTTP a REST — tohle si můžeme představit jako podobný protokol, taky běží na TCP/IP, akorát vrstva nad tím, co se posílá, není jako HTTP metody GET nebo POST.

Má to ale jinou strukturu těch zpráv (message), co se posílají, a je to vytvořené tak, aby to mohlo běžet na zařízeních, která třeba nemají velký výkon, nebo která musí být energeticky úsporná. Tento standard se myslím dobře rozšířil a stále více providerů nabízí cloudovou variantu, takzvaného MQTT brokera, ke kterému se můžeš připojit. API si můžeš představit jako nějaké rozhraní pro komunikaci.

My například nejvíc používáme Azure IoT Hub, což je služba dostupná od roku 2015, myslím, že Microsoft ji pustil někdy v roce 2016. Takže MQTT je takový standard na transportní vrstvě, pokud o ní mluvíme. Existují i další protokoly, například AMQP, který má třeba lepší šířku pásma (bandwidth) a dokáže přes jednu spojení sdílet více fyzických kanálů. Na druhou stranu ale AMQP nemusí být tak energeticky úsporný a zase nabízí lepší spolehlivost. MQTT tedy zůstává takovým standardem, který funguje například i v Koreji.

Co se týče LoRa a přenosových protokolů — to už je trošku jiná oblast. Na této úrovni, pokud se bavíme o rozmístění senzorů v místnosti s co nejnižší spotřebou energie, tam myslím ještě není jednoznačné vítězství jednoho řešení. (Poznámka: tu zazněla zmínka o francouzském projektu s českým investorem, ale detaily nejsou úplně jasné.) LoRa představuje standard na fyzické vrstvě přenosu dat, ale na této úrovni se stále nachází mnoho různých možností, které je třeba správně integrovat.

Je to logické, protože na fyzické vrstvě se těžko hledá univerzální řešení („one size fits all“), jelikož energetické požadavky jsou různorodé a závisí na vzdálenosti přenosu, množství přenášených dat nebo například tom, zda je potřeba data mezi zařízeními cacheovat. Nemyslím si, že se nám podaří celou tuto vrstvu standardizovat tak, jak se nám to povedlo u protokolů založených na REST API.

To je podle mě dobře, protože v tom pořád je jakási inženýrská zajímavost — je třeba zvolit ten správný protokol na míru, nikdo ti nenařídí architekturu od stolu, musíš mít o tom znalosti, aby sis vybral správně.

Dobře, vraťme se k rozdělení oddělení. Takže Embedded je na zařízení, přesně tak. Pak máme data engineering oddělení, které začíná zhruba na edge computingu. Tam se nějak dělí odpovědnost… (tady původní text končí).

Jasně, tady je opravený a lehce upravený text, aby byl srozumitelnější a plynulejší:

Am vlastně končí embedded a už začíná v podstatě cloud engineering. A samozřejmě v cloudu, což znamená budování distribuovaných systémů, které ta data potom, co přitečou z těch zařízení (devices), sbírají, ukládají do různých formátů, aby je bylo možné dál zpracovávat. To je vlastně cloud engineering.

Ještě tě ale zastavím. Začínali jste v roce 2015 a teď to nazýváš cloud engineeringem, data engineeringem, nebo data engineeringem obecně. Na druhou stranu jste v průmyslu, na farmách se špatným připojením, a tak. Máte ještě nějaké on-premise řešení? Předpokládám, že on-premise to začínalo, že každá farma měla vlastní server.

Ano, pravda. Na těch farmách ty servery stále ještě jsou a edge computing nodey tam budou vždycky – nějaký hardware tam prostě být musí. Ale máš pravdu s tím on-premisem, že jsme vlastně začínali trénovat naše strojové učením (machine learning) modely na výpočetních klasrech, které jsme si sami stavěli. Měli jsme vlastní železo v datacentru, instalovali jsme na to operační systém a na tom jsme rozběhli celý moderní data stack. Dneska to dekomisnujeme a vše postupně přesouváme do cloudu.

Data však vždycky mířila do cloudu; nebyli jsme ve fázi, kdy bychom z celého světa sbírali data na jeden server, který bychom sami spravovali. Ale začínali jsme s tím, že jsme data science nějakou dobu, i letos, dělali na on-premise klastru.

Teď se postupně přesouváme k tomu, že chceme vše, tedy i trénink modelů a samotné data science, dělat v cloudu. Data engineering ale byl v cloudu vždycky, takže data z embedded zařízení dostaneme do cloudu, vyčistíme je, vytvoříme dataset, na jehož základě může data science začít budovat strojově učící modely, které se pak deploynou do produkce.

A výsledky těch modelů chceme buď přímo použít k řízení fyzického zařízení, třeba robota nebo třídicí linky, anebo třeba u predictive maintenance, kde chceme vědět, že se robot s určitou pravděpodobností rozbije příští týden, abychom ho stihli opravit dřív, než dojde k selhání. Takové insighty chceme předat technikům prostřednictvím aplikací, které vyvine application development tým.

A poslední část je tedy data science, že? Jak myslíš poslední je první?

Máme embedded, pak data engineering, následně aplikace a také data science, protože z dat potřebujeme postavit model a ten deployovat do produkce, aby mohl potom fungovat.

Pokud chceš, mohu ti pomoci i s další úpravou nebo zkrácením. Stačí říct!

Zde je opravený text s jazykovou a stylistickou úpravou pro lepší srozumitelnost:

Abychom data vlastně zpracovali a následně vygenerovali nějaké insighty, které potom ukážeme v aplikaci. Takto tedy vypadá celý chain. Super. A co stack? Mluvil jsi o Azure, tedy o .NETu, tak máte nějaký ekosystém okolo Microsoftího stacku? Na začátku jsi také zmiňoval, že jste dělali věci ve Scale a MATLABu, kam se to tedy posunulo? Jak dnes vypadá vaše data science? Předpokládám, že se přizpůsobujete klientovi a jdete až do fyzikálních modelů, že u některých projektů to nejde ovlivnit, ale obecně?

Určitě máme affinity v Azure, tam jsme začínali, ale děláme věci také na AWS, takže v Google Cloudu teď nic nemáme. Fungujeme tedy na AWS a Azure. Naše IoT platforma, kterou reutilizujeme ve většině projektů, abychom dostali data z device do cloudu, je stále napsaná v .NETu. Určitě tam zůstane, protože potřebujeme mít výkon pod větší kontrolou. Takže backend je .NET, ale veškerý data engineering a data science už děláme v Pythonu.

Používáme vlastně dvě architektury – jednu starší, kterou jsme používali dříve a ke které teď konvergujeme, a druhou modernější. Ta starší architektura pro machine learning v produkci byla založená na konceptu competing consumers. Když jsme například potřebovali natrénovat 10 000 modelů, nasypali jsme do fronty v cloudu (například Apache Kafka nebo RabbitMQ) 10 000 zpráv, kde každá zpráva reprezentovala úlohu: natrénuj jeden model na určitých datech. Na tuto frontu se připojilo několik competing consumerů, tedy worker jobů, kteří zprávy z fronty vytahovali a zpracovávali.

Tyto workery jsme typicky deployovali do Kubernetes už v letech 2016, 2017. V té době začínaly být dockery výrazným tématem, i když ještě soupeřily s Linux containers, ale už bylo jasné, kam to směřuje. Asi od roku 2018, 2019 se Kubernetes staly jasným vítězem v orchestraci kontejnerů. Takže takový byl náš stack – správu Kubernetes clusterů jsme měli manažovanou buď od Azure nebo AWS. Na těchto clusterech běžely Docker kontejnery s Pythonem.

Jak jsem možná na začátku zmiňoval, tak mnohdy Pythonní úlohy nemusí být distribuované – nemusí to být něco, co běží na více uzlech současně. Může to být například klasický scikit-learn model. V našem případě totiž trénujeme tisíce modelů, ale každý model není příliš velký, takže je dokážeme …

Pokud chcete, můžu pokračovat v opravě i další části textu.

Zde je opravený text:

Můžeme ten model vlastně zabalit do toho Dockeru a on na tom jednom výpočetním uzlu úplně v pohodě inferuje. Dokonce i trénování se často dá dělat na tom jednom výpočetním uzlu, trénink nemusí být distribuovaný.

Co se týká toho stacku, jak jsi říkal, myslím, že v tom není nic esoterického. Je to Python, Scikit-learn, Docker a Kubernetes. Vlastně to je ten stack, ve kterém to běží – tahle competing consumers architektura.

No ale čím dál víc přecházíme k takovým zjednodušením. My jsme tuto architekturu volili proto, abychom měli co nejmenší latence a co největší kontrolu nad paralelizací. Ale zjišťujeme, že není potřeba mít věci úplně perfektní, protože to pak stojí mnohem víc úsilí, komplexity a tím pádem i peněz.

Takže přecházíme zpátky k standardnímu MapReduce paradigmatiku. Jak jsem říkal, my jsme se Sparkem začínali, známe ho od verze 0.9, učili jsme ho na fakultě. Když potřebujeme vyhodnotit nebo natrénovat třeba tisíc modelů, vytvoříme dataset, který necháme na MapReduce, ať nám to paralelizuje, a v každé map funkci či transformační fázi můžeme dělat inferenci nebo i trénování modelu.

Nemáme sice úplnou kontrolu nad tím, jak se partitioning přesně provede, a když by jedna partition byla mnohem větší než ostatní, tak MapReduce s tím bude mít trochu problém, což bys u competing consumers neměl. Ale nakonec zjistíme, že to až tak moc nevadí. Navíc, protože je to jednodušší a řádků kódu je mnohem méně, když si nasadíš správnou architektonickou čepici, kde jako architekt rozumíš dostatečně hluboce kódu a zároveň víš, kde je obchodní hodnota, dokážeš přesně tyto dva světy spojit a říct: „Hele, uděláme to tak, že nemáme úplnou kontrolu. Když budou nějaké partitiony disbalancované, zpracování to bude trvat o něco déle, ale komplexita bude menší, bude se to lépe udržovat, takže to bude levnější a ekonomicky výhodnější.“

Takže vlastně přecházíme z toho paradigmatu, kdy jsme většinu věcí paralelizovali přes competing consumers pattern do Kubernetes s Python workloady a frontami, ke klasickému MapReduce, což znamená manažovaný Spark. Většinou nám Spark manažuje Databricks, ale dokážeme si ho spustit i sami. Pro nás je hodně důležité mít technologie i na open source, protože jak jsem říkal s Edge computingem, máme 30 tisíc zařízení po celém světě, a proto se nám hodí, že si tu technologii můžeme vzít a rozběhnout ji i na Edge.

Spark nám dává tuto možnost a filozoficky se nám líbí, že Databricks staví věci nad open source, některé části jsou open source, některé ne, ale hlavní části určitě. Takže víme, že když…

Pokud chcete, mohu pokračovat a upravit i zbylou část textu, pokud ji doplníte.

Opravený text:

Použijeme Spark, tak buď zaplatíme Databricksům, aby nám to hostoval, nebo když to bude moc drahé, tak si můžeš ten případ spočítat a platit svému adminovi, který ten cluster spravuje. Ostatně jsme to tak dělávali dřív sami. Nebo si přesně můžeš říct, že bych tenhle workload teď potřeboval přesunout na Edge a nechci ten kód přepisovat, chci, aby to bylo stejné. Proto se nám líbí Apache Spark a Delta Lake, což je vlastně standard, který Databricks open-source zveřejnil pro tabulková data nad velkými object storage, levnými cloudovými úložišti, jako třeba S3 nebo Azure Blobstore. Tyhle technologie se nám líbí právě proto, že je dokážeme, když budeme potřebovat, dostat i na vlastní hardware, třeba na farmě, nebo na nějakém počítači, který bude běžet vedle mikroskopu. Dokážeme to udělat, a to je i důvod, proč jsme vsadili na Databricks, když oni vlastně otevřeli ten open-source projekt. Na mě zafungoval jejich sales model – staví věci nad open sourcem, protože tak člověk nemá pocit vendor lock-in a může si to vzít sám jako inženýr. Mně to funguje, protože v tom vidím hodnotu – když budu potřebovat, vezmu si standard Delta Lake, Apache Spark a přenesu to jinam. Není to ale úplně ideální s Databricks, musím říct, že občas člověk musí být opravdu…

Aby dokázal férově vyvážit to, co to je: tady je byznysová hodnota, tady bude nějaké snížení engineering complexity, a jak velký to bude, nikdy přesně neuděláš.

Přesně, ale zhruba aspoň. Já si osobně myslím, že architekt by měl být schopen jít na úroveň řádku kódu. Ne, že by to dělal CTO – o tom jsme se bavili před natáčením, CTO to dělat nemusí, to bych tady určitě nechtěl říkat – ale myslím si, že když někdo má tu čepici architekta (já mám obě ty čepice), je důležité dodat, že to neříkám jen jako CTO, ale i jako architekt, že si dáváš tu zodpovědnost rozumět každému řádku kódu a máš sto lidí ve firmě, kteří tě informují.

Jasně, já určitě nerozumím zdaleka každému řádku kódu, co napíšeme, ale co si myslím, že je důležité, že architekt dokáže, když je potřeba, posunout diskusi právě na tuto úroveň. „Teď mi ukaž ten kód, pošli mi link na ten řádek v Githubu, kde děláš tu transformaci nad tím dataframem, ukaž mi, jak se jmenuje ta metoda v API a jaké garance má.“ To jsou podstatné věci. Nechceš, to je můj názor, nechceš commitovat do domény a být na kritické cestě, když se dodává software. To fakt nechceš dělat, ale chceš být schopen, když architektuješ s lead inženýry nějaké řešení, posunout diskusi na tuto úroveň. Ne že bys to dělal pořád, ale když to je třeba, tak proto, že jinak je tam příliš abstrakcí. Když je to potřeba, je mnohem praktičtější začít psát nějaké řádky kódu.

Pokud chceš, můžu pomoci i s rozdělením na odstavce a lepší strukturou textu.

Jasně, tady je opravený text s lepší strukturou a pravopisem:

Už můžeš poslat buď pseudokód, nebo link na konkrétní řádek v GitHubu. Myslím, že tím se to blíží k cíli, protože jinak jeden mluví o voze a druhý o koze, a nakonec z toho vznikne filozofická diskuse.

Ano, přesně. Když to tak popisuješ, vidím tam ty trade-offy. Když mluvíš o vaší původní architektuře versus to, kam jdete teď, možná opravdu neexistuje jedno nejlepší řešení. To se prostě časem mění a záleží na konkrétním use casu a business casu celého projektu.

Například jsi zmiňoval Kafku a streaming. Tehdy bylo jasné, že půjde o real-time data analytics, že budeme data zpracovávat rychle. Logicky jsme začínali s jednou dávkou za měsíc, potom na úrovni D-1, teď budeme mít dávky každou hodinu a možná za deset let bude všechno streamované. Klasické batchování přestane existovat, protože s nástupem superpočítačů už bude všechno v reálném čase.

Ale pořád to nedává úplný smysl. Jsou různé typy aut – sportovní auta i dodávky, a trh je pro obojí.

Ano, nejslavnější odpověď v IT je „it depends“. Vždycky je to „it depends“. Jakmile na něco není „it depends“, tak už tě to podle mě přestane bavit, protože to znamená, že architekturu už někdo vymyslel, někdo na to napsal toolset, takže to jen zapojíš. Díky bohu za „it depends“, protože to dělá software engineering pořád zajímavým.

A jak se to projevuje v tom „make the requirements less dumb“? Přesně tak, často v diskusích challengeju, jaká má být latence end-to-end. Když se vygeneruje nějaký datový bod na nějaké stránce, do kdy musí být v cloudu, do kdy musí proběhnout predikce třeba pro uživatele atd. Vždycky říkám, že pokud dokážeš něco spočítat batch processingem – například batch běžící každou hodinu – tak to bude jednodušší. Batch processing byl totiž první a je jednodušší než streaming.

I když nám platformy dneska hodně pomáhají a skrývají komplexitu, tak celková komplexita problému bude vždycky větší, pokud chceš dělat streaming s malou latencí, než když tam bude batch.

Podle mě platí: když něco dokážeš spočítat hodinovým nebo 15minutovým batchem (to je pořád batch), udělej to tak. Když dokážeš data uložit do relační databáze, která se vejde na jeden uzel, udělej to tak. Nevkládej víru pouze do škálování „out“, můžeš dělat i škálování „up“.

Když se dneska podíváme na cloudové providery, ti dokážou „vyspinovat“ stroj s 100 procesory a terabyty paměti. Dřív se to muselo dělat na výpočetních klastrech, které byly poměrně složité. Dnes to můžeme řešit na jednom stroji. Dokud data udržíš na jednom uzlu, dělej to tam. Nedělej distribuovanou architekturu nasilu. Dokážeš-li data dostat do relační databáze – použij ji, je to ověřená technologie, co tady je padesát let, a funguje.

Pokud chceš, můžu ti pomoci s dalšími úpravami nebo formátováním.

Tady je opravený text s úpravami pro lepší srozumitelnost a gramatiku:

Je to battle tested, máš tam garance, které chceš – všechno, atomicitu, konzistenci, máš tam durabilitu, ty věci, které potřebuješ, tam jsou, dokud to stačí, udělej to. A vlastně průmysl, když mluvím o relačních databázích, se aspoň na logické úrovni k tomu vrací i v distribuovaných systémech. Když se dneska podíváme na Snowflake nebo Databricks, každý přišel z jiného směru – Snowflake přišel z toho, že to byl prostě Oracle do cloudu, a Databricks přišel s tím, že máme tady Spark. Snowflake začal jako databáze, Spark jako výpočetní engine, ale dneska se to fakt konverguje. Jsou to alternativy, ale logická abstrakce, kterou dávají, je vlastně stejná jako u tradiční relační databáze. Máš katalog, ať už Unity katalog, nebo Polaris katalog, to je jedno, tam máš databáze, v nich schémata, ve schématech tabulky a v tabulkách sloupce se silnými datovými typy. Když se podíváš na jejich rozhraní a vedle dáš například Postgres, SQL Server nebo Oracle, jako bys vzal screenshot a proklikával data – vypadá to prostě stejně.

Jediný rozdíl je, že pod povrchem je výpočet mnohem složitější. A já si osobně myslím, že průmysl prošel cestou od roku 2010, kdy jsme museli tradiční relační databáze opustit, protože začínalo být těch dat tolik, že to přestávalo škálovat. Vzdali jsme se některých garancí, které nám relační databáze dávaly, ale co jsme získali? Získali jsme škálovatelnost. Dokázali jsme data najednou uložit na více serverech, i když třeba za cenu ztráty nějaké konzistence nebo typovosti.

Ale tím myslíš jako Hadoop, Big Data vlnu? Ano, buď Hadoop, nebo zejména NoSQL. Řekli jsme si, pojďme spíš směrem NoSQL, zahodíme některé záruky z SQL databází, ale získáme škálovatelnost. A teď si myslím, že jsme se zpátky dokázali vrátit k tomu, že logický model – data v tabulkách, silné datové typy, tabulky ve schématech, schémata v databázích a metadata katalog přístupný firmě – je dobrý model. Tak se k němu vraťme a začněme zase u data uvažovat v silných datových typech a tabulkách, protože už to umíme škálovat.

Ne vždycky, pořád platí to, co jsme říkali u Dripens – NoSQL pořád má své místo a tzv. polyglot persistence, kdy datovou vrstvu postavíš na mixu úložišť a technologií tak, aby odpovídala use case ekonomicky i technicky. To pořád platí, já netvrdím, že NoSQL zmizí. Ale spousta věcí už zase dokážeme v tom škálovatelném modelu, který je jednodušší a většinou i levnější.

Takže možná to byl nějaký sen, že vlastně se to…

Pokud chceš, rád doplním nebo upravím text ještě víc!

Tady je opravená verze vašeho textu:

Posouvá se to tak rychle, že to vždycky stíháme spočítat – když naházíme dostatečně velké množství dat na dostatečně velkou hromadu a potom na to pustíme dostatečně silný stroj, tak se to prostě stane. A teď zjišťujeme, že tomu potřebujeme rozumět. A takhle. Na druhou stranu mě tím přivádíš k jedné technologii, která do značné míry funguje tímto způsobem – naházíme dostatečně velké množství na jednu velkou hromadu a pustíme na to dostatečně silný výpočet za miliardy dolarů, a ono to vyjde. A ten „love scale“ tam zafungoval. Těmi technologiemi jsou LLM (Large Language Models) a GenAI (Generative AI). Jak ale tyto technologie pronikly do byznysu a konkrétně do use case, kde máte hodně fyzického světa a fyzikálních věcí, které jsou spíše v matematice než v kulturních nebo jazykových oblastech? Jak se na ně díváte, nebo jak k nim přistupujete? Předpokládám, že pro vás to nebyla tak velká revoluce, protože jste spíše zaměření na hardware a IoT než na zákaznickou podporu nebo sociální sítě.

Jasně. V oblasti industrial use case s tím samozřejmě nějak výrazně nehýbám, mám jen pár okrajových případů, které můžu zmínit, ale…

Obecně ne, ale máš pravdu, že u těch zákazníků, kterým pomáháme inovovat pomocí data a AI, má LLM určitě své místo. My je samozřejmě používáme. Myslím si, že use case chatbota, respektive řešení jako Retrieval Augmented Generation (RAG), se komoditizuje natolik, že ho dneska fakt používá skoro každý. A protože cena těchto systémů jde výrazně dolů, vznikají systémy, které nad tvojí knowledge base, wiki nebo souborem výzkumných prací vytvoří chatbota, který ti umí poradit. Ta cena je tak nízká, že se to začíná vyplácet v čím dál větším počtu byznysů. Takže tohle, co děláme, je nasazení LLM hlavně v aplikační vrstvě, aby uživatel mohl mít například chatbota, a to je dnes už de facto standardní nabídka každé firmy, která se pohybuje v datovém světě. LLM prostě nejde minout.

Mě ale třeba zajímá případ, se kterým teď pracujeme, jestli LLM dokáže pomoci i s generováním soustav rovnic, které by popisovaly nějaké fyzikální systémy. To mi přijde mnohem zajímavější. Opět jde o to, jestli LLM může nejen dělat chytřejší vyhledávání v knowledge base, které pak zobrazí hezky strukturovanou odpověď – což je v podstatě to, co dnes dělá – tedy nejen odemknout přirozený jazyk. Ale dokázalo by i generovat takové rovnice na základě znalosti kontextu a pomoci s iterací nad nimi. Následně by se ty výsledky mohly upravovat dalším zpracováním. To je pro mě zajímavá oblast.

A co se týče dalších oblastí, kde LLM určitě používáme a chceme používat, myslím, že to je velký trend…

Pokud chcete, mohu pokračovat a upravit i další části textu.

Tady je opravený text s upravenou gramatikou, interpunkcí a stylistikou:

Pustí nad strukturovanými daty. To znamená self-serve data analytics. Už dneska nepotřebuješ, aby ten člověk, který interaguje s daty, musel psát SQL dotazy, ale mohl je napsat v normálním, přirozeném jazyce. Mám takovou osobní hypotézu: myslím si, že když v 70. letech vymysleli SQL, měli podobný pocit jako my teď s LLM, že se s počítačem můžeme bavit v přirozeném jazyce. Napsali například „SELECT FROM“, vyber mi z employees, kde je salary větší než… A měli takový pocit, že napsali větu a počítač jim vrátil výsledky. Podle mě máme něco podobného i teď, akorát už je to opravdu natural language – zeptáme se „vrať mi tyhle data“, „udělej mi takovouhle agregaci“ a LLM pak dokáže postavit SQL dotaz. Když v 70. letech bylo SQL takovým jazykem pro ně, teď potřebujeme úroveň překladu na přirozený jazyk, a myslím si, že tenhle use case pro LLM také existuje.

To znamená předhodit LLM v rámci byznysu firmy nejenom jejich jedničky a nulky, které jsou v textu, ale i ta data, která mají ve strukturovaných datových zdrojích. Samozřejmě je velmi důležitý metadata management – musíme mít data dobře popsaná, aby LLM mělo kontext. To je myslím řešitelné. Z inženýrského pohledu je další část, kterou určitě Datamol dělá, to, že umožní self-serve analytics. My tomu vždycky říkali data democratization v firmy, chceme, aby data mohlo používat co nejvíce lidí. Pamatuju si na citizen data scientist, což kdysi měla Keboola – citizen data scientist, něco podobného. Jsou to různá označení na stejnou věc. Teď zpětně, když slyším citizen data scientist, tak se směju, protože od tohohle se ustoupilo. Už nebudeme učit byznysáky Python. Ne Python, ale podle mě ten cíl je stejný – zvětšit počet lidí, kteří z dat dokážou sami získávat insighty, a ne aby si museli zadávat dotazy někomu z datového týmu, aby vytvořil report nebo zkontroloval query.

Samozřejmě to bude mít stejné nedostatky a problémy jako všechny LLM – nebudeš si úplně jistý, jestli dotaz napsalo správně nebo jestli jsou výsledky správné. Ale to mi přijde podobné, jako když se dnes zeptáš jakéhokoliv e-já (AI), taky nemáš jistotu, jestli odpověď je stoprocentně správná. S tím se budeme muset naučit pracovat. Ale myslím si, že to, že to odemkne a otevře data mnohem širší skupině lidí přes self-serve analytics, je určitě správná cesta.

Pomůže to zrychlit vývoj, aby inovace, které jsme vždy chtěli dělat data-driven, mohly opravdu vznikat rychleji. Gen AI je jedna z dalších věcí v jednom z oddělení, tak vás to zase tak netýká. Co jsou pro tebe hlavní změny, které jsi zaznamenal za poslední…

Pokud chceš, mohu ti pomoci i s pokračováním textu.

Zde je opravený text s důrazem na gramatiku, interpunkci a styl, aby byl plynulejší a srozumitelnější:

Posledních deset let? On-prem cloud, nějaká architektura, cizelování detailů versus big picture a business development – tak to tam vidím. Co se podle tebe změnilo a co zůstalo úplně stejné?

Zůstalo stejné. Hele, podle mě je to, co v Datamolu zůstalo úplně stejné, firemní kultura. Teď to vezmu z téhle stránky a pak se dostaneme k inženýringu, ale myslím, že tohle je taky hrozně důležitá věc. Chtěl bych tím poděkovat všem v Datamolu, kteří dokázali škálovat tu firemní kulturu i přes to, že nás je teď sto.

Vždycky jsme říkali, když jsme Datamol zakládali, že chceme dělat the work we like with people we like in environment we like. Byli jsme si docela jistí, že tu část „the work we like“ budeme mít splněnou, protože machine learning je zajímavá oblast, IOT je zajímavá oblast. To znamená, že všichni inženýři jsou mentálně dostatečně saturovaní problémy, které řešíme.

Od začátku jste global díky té specializaci, takže si můžete vybírat tu úzkou profilaci. To je pravda. Na jedné straně v Česku bude pár zákazníků, kteří tuhle specializaci vyžadují, ale v globálu to půjde.

Z komunikačního pohledu mi přijde, že jste unikátní v tom, že se diferenciujete tím, že neděláte telekomunikace ani banking. Tohle bych začínal konverzace. Nám se to taky stává – když se někdo zeptá, co děláme, my říkáme, co neděláme. To je takový začátek.

Takže to tam vidím. Jak to udržet v těch lidech? Máš nějaké tipy?

No, zkusím nějaké dát dohromady, jestli se mi to podaří. Ale podle mě to, co zůstalo stejné, je právě to, co jsem zmínil. Jsem opravdu vděčný všem, protože dělat práci, kterou máš rád, s lidmi, které máš rád, je hrozně důležité – proto se v práci cítíš dobře.

A proto se snažíme do těch lidských vztahů co nejvíc investovat – i když nabíráme nové lidi, snažíme se najít takové, kteří jsou rádi, že ta firma incentivizuje nejen společnou práci, ale i osobní vztahy. Máme spoustu afterwork aktivit, věříme si a jsme k sobě fair.

Co se týče udržení této atmosféry, musíš ve všech detailech a každodenním koloběhu firmy dbát na to, aby tohle nezapadlo. Aby lidé měli dost času spolu mluvit, trávit čas i mimo kancelář. Aby hodnoty jako vzájemná důvěra a fér přístup byly rozprostřené ve všech rozhodnutích firmy. Prostě to prioritizovat.

Ano, vždycky to mít v rozhodovací matici. Věřím pevně, že to, co Datamol skutečně odlišuje, není to, jak máme firemní kulturu definovanou nebo napsanou – to může spousta firem opsat – ale skutečný rozdíl je v tom, jak ji opravdu žijeme.

Pokud bys chtěl, mohu text ještě upravit na konkrétní formát nebo styl.

Jasně, tady máš opravený text:

Jak to žiju, jak to dokážeme v tom každodenním životě uplatnit. A lidi, co k nám přijdou jako zvenku, tak nám to docela potvrzují. Takže to je firemní kultura, je to, jak se chováš, když se nikdo nedívá. To je hezké, to se mi líbí. To mám hrozně rád. A ještě si vzpomenu na svého kamaráda Adama Hrubého, který to krásně vyjádřil. Nevěřil bych firmě, která by mezi hodnotami na stěně měla „nelžeme si“. To je jako ve chvíli, kdy musíš na stěnu dát „nelžeme si“ — trochu? Proč to potřebuješ incentivizovat? To není standard. Koho mám vybírat? Všem to musím napsat? Na to si vždycky vzpomenu.

No a co se změnilo? Co se změnilo? Takže tohle se nezměnilo, ta kultura zůstala stejná. Samozřejmě se změnilo to, že už nejsme na jednom patře.

Jsme prostě ve třech patrech, takže samozřejmě jsou tam nějaké věci, které jsou těžší, už prostě nepoznáš se s každým z firmy za dva týdny, bude to trvat, to se určitě změnilo. Ale co se týká toho, abychom taky šli na technologickou stránku, co se změnilo z těch technologií, tak myslím, že jsi to shrnul docela dobře. On-prem věci — začínali jsme tak, nikdy ne na produkční nasazení, ale na trénink, na data science, od toho odcházíme. Nechci tím říct, že každý musí odejít do cloudu, pořád bude existovat nějaký případ, kdy ten hardware využiješ, a teď nevím přesně, ale tipnul bych si 70–80 %, že se ti vyplatí to mít pod stolem a udržovat si to sám.

Když si koupíš opravdu počítač, kde budeš mít třeba nějakou Tesla grafickou kartu a fakt ji budeš vytěžovat, třeba zpracovávat tolik videostreamů, že ji budeš mít konstantně na 80 % vytíženou, tak se ti fakt může vyplatit to mít pod stolem. Ale typicky to tak není, většinou data scientist přijde do práce, ráno něco začne, většinu času používá ten malý komp, který má, a pak jenom občas to potřebuje nafouknout a pustit na nějakém velkém datasetu. A to prostě na on-prem železe neuděláš, pokud nemáš tisíc data scientistů a nevytváříš si vlastně vlastní cloud.

Takže v tomhle případě se snažíme jít cestou cloudu, protože tím, že se víc přiblížíme k pay-per-use, je to ekonomicky výhodnější. Takže to se určitě změnilo.

Co se u nás určitě mění, jak jsme říkali, je návrat k MapReduce a psaní věcí nad nějakým Spark enginem, protože, jak jsem říkal, dokážeme to pak dobře spustit i on-prem, když potřebujeme, například na edge.

Co si myslím, že se ještě bude měnit a kde vidím, že to není úplně standardizované, je otázka, jak moc bude v tom IoT světě, jak ses ptal na standardizace. Co myslím, že není úplně dobře vyřešené, je management třeba 30 tisíc Kubernetes klastrů. My samozřejmě chceme ty workloady, které mají běžet na edge, aby běžely na nějakém Kubernetes klastru, aby to na edge mělo stejný interface jako Kubernetes, i když to nemusí být distribuované. Centralizování …

Pokud chceš, můžu ti pomoci s doladěním nebo rozdělením do paragrafů.

Tady je opravený text s úpravami pro lepší srozumitelnost, gramatiku a stylistiku:

Centralizace, prostě jedna věc, jeden interface, vlastně způsob, jak definujeme, jak tam ty workloady běží. A to je ještě dneska docela těžké. Vzít nějakou platformu, která by orchestrala 30 tisíc orchestrátorů nebo kontejnerů, to je zatím složité. Existují sice platformy Kubernetes na edge, tedy jak provozovat Kubernetes na edge, ale jak to orchestrálně zvládnout v takovém obrovském měřítku, to už podle mě není tolik firem, které to potřebují, aby to bylo dobře standardizované.

Na to bych se osobně těšil – kdyby existovala nějaká open-source platforma, která by dokázala rolovat věci na těch 30 tisíc sitech, kde na každém site je Kubernetes cluster, a přitom by uměla škálovat. Protože stejný problém, jako jsme měli v cloudu, budeme mít i na edge. Budeme potřebovat stále více algoritmů přesouvat na edge, a to znamená, že výpočetní síla, která tam je dnes, je jiná, než jakou tam budeme potřebovat třeba za pět let.

Nedej bože, až tam budeme chtít deployovat nějaké LLM nebo grafické karty, bude potřeba umět na edge zapojit další výpočetní uzly a nad tím spuštět jeden orchestrátor Kubernetes, který to celé zabalí a bude vypadat jako jedna koherentní věc. Takové výzvy mě opravdu zajímají a pokud máš business case, kde má smysl tomu věnovat inženýrský čas a mentální kapacity, jsou tyto případy velmi zajímavé.

Když mluvíš o platformě, která orchestruje edge computing, tak předpokládám, že to nebude ambice Spotflow, protože jsi zmínil, že máte vlastní software a aplikaci, kterou používáte na většinu těchto use caseů a kterou jste dokonce produktivizovali. Ano, je to tak. Dokonce je to dnes spin-off.

Počítáš do těch stovky lidí i lidi ze Spotflow, nebo ne? Myslím, že ano, s tím spin-offem je to propojené. Ale Spotflow necílí na orchestrace Kubernetes v rozsahu, ale aktuálně se soustředí na embedded observability. To znamená nejen sběr dat ze zařízení, ale také schopnost řešit specifické potřeby, například sbírat crash dumpy, logy a nad nimi dělat pokročilou analytiku.

Jde o to zjistit, z jaké verze firmwaru a po jakém sledu akcí dochází k nějakým crashům. To je vlastně současný směr, jak se platforma Spotflow definuje. Už to není jen generický IoT sběr dat, ale vyloženě embedded observability a monitoring v embedded světě. Ideálně s pokročilou analytikou nad těmito daty. Není to jen o sběru a vizualizaci v nějakém obrovském dashboardu, ve kterém se nikdo nevyzná a kde jsou data jen pro data, ale o možnosti udělat nad tím nějaké insighty. A to je opravdu náročné, pokud máš ve světě třeba 100 000 zařízení a potřebuješ zjistit, jaké sekvence akcí a kombinace firmware a hardware vedou k určitým crashům.

Pokud chceš, mohu dále pomoci s úpravou náročnějších pasáží nebo přepsat text do formálnějšího stylu.

Zde je opravený text:

Úm, tak tohle může být například nějaká pokročilá analytika, kterou vlastně dokáže platforma Spotflow. Ale dneska je to samostatná firma, která to prodává, používá to někdo jiný než vy a tak. Teď je to firma, která je přesně samostatnou jednotkou, ale sales teď začíná a hledá se ten fit v embedded světě. Vlastně ten pivot na embedded je to, kde teď děláme validaci – validaci value proposition a zjišťujeme, jak by to fungovalo, jak bude fungovat, v kterých embedded firmách – velkých i malých, kdo to bude chtít, v jakém modelu si to nasadí, kdo bude chtít data vlastnit, kdo je schopen je posílat do tvé platformy, kdo je musí mít pod svou kontrolou. V embedded je to hodně výrobci, ne? Přesně tak, je to úplně jiný svět. Bosch a takové mají vlastní řešení. Jo, je to tak.

Co vás teď čeká? Jsme teď na přelomu roku 2024/2025. Jasně. Jaké jsou nejbližší výzvy a když se potkáme za rok, jak to bude? Kam chcete DataMall posunout? Náše hlavní cíl je v tom dynamickém prostředí, kde přicházejí nové technologie, zákazníci a projekty, abychom se udrželi na hraně (on the edge) a byli stále firmou, která… To se mi líbí, on the edge je dobré a dvojznačné. Ano, pravda – ať už v IoT světě, nebo v technologickém. Takže udržet se v expertíze a zároveň udržet firemní kulturu. Opravdu pořád chtít pracovat v prostředí, které máme rádi, s lidmi, které máme rádi, na projektech, které dávají smysl. Takže přestože se vize zdá být poměrně statická, je zároveň velmi dynamická. Jinak se to dělá ve 20 lidech a jinak ve 100. Ano, přesně tak. A protože se technologie mění a zákazníci přicházejí a odcházejí, chceme být vždy partnerem, který pomáhá inovovat. To je ta věc navenek, ale i dovnitř, abychom to pořád dělali v prostředí, kde se cítíme dobře. Takže to je náš cíl.

Co se týká růstu, víme, že v Praze už růst nechceme, máme tu teď čtyři patra. Větší rozšiřování by znamenalo, že nás na Malostranském náměstí bude sedět 70, 80 lidí, a to by už mohlo negativně ovlivnit kulturu a hůře by se škálovalo. Takže víme, že chceme škálovat vytvořením dalších jednotek, aby nedocházelo k sociálnímu přetížení, kdy člověk „jen musí znát“ všechny ostatní. Tedy Brno a Krumlov. Ano, Krumlov je správný bod.

Pokud někoho zaujme náš přístup k data engineeringu, který jsem popisoval – není to telco, není to banking, není to standardní ETL, ale je to komplexnější řešení -, určitě se podívejte na naše webové stránky datamall.ai, sekci „Careers,“ kde najdete volné pozice. Když někoho toto zaujme, může se nám určitě přihlásit. A v Brně je teď větší poptávka než v Praze. Ale v Praze s…

Pokud chcete, mohu pokračovat v opravě i zbytku textu nebo ho případně zestručnit.

Samozřejmě to zavřené není, ta možnost. Ondro, moc díky. Datamall mi přijde úplně unikátní a hrozně se mi líbí, že jste tu abstraktní práci dostali zpátky – nejen do fyzického světa, ale až do fyzikálního. Ty vaše use cases…

Moc se mi líbí, díky, že jsi tady sdílel svoje zkušenosti, a určitě zase brzy, protože to bylo z mé strany úžasné. Ještě jednou díky, Jirko, za pozvání, bylo to moc příjemné povídání.