Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Během akce Arduino Days 2026 byl publikován Arduino Open Source Report 2025 (pdf) a oznámeno 7 nových produktů kompatibilních s deskou UNO Q (Arduino USB-C Power Supply, USB-C Cable, USB-C Hub, UNO Media Carrier, UNO Breakout Carrier, Bug Hopper, Modulino LED Matrix).
Google v pátek spustil v Česku Vyhledávání Live. Tato novinka umožňuje lidem vést plynulou konverzaci s vyhledávačem v češtině. A to prostřednictvím hlasu, nebo prostřednictvím toho, na co ukážou svým fotoaparátem či kamerou v mobilu. Rozšíření této multimodální funkce je možné díky nasazení Gemini 3.1 Flash Live, nového hlasového a audio modelu, který je od základu vícejazyčný, takže umožňuje lidem po celém světě mluvit na vyhledávač přirozeně a v jazyce, který je jim nejbližší.
Jsongrep je open-source nástroj, který efektivně prohledává JSON dokumenty (editovat je neumí). Kompiluje regulérní jazyk dotazu do podoby deterministického konečného automatu (DFA), díky čemuž prochází strom JSON dokumentu pouze jednou a je v tom tedy rychlejší než jiné nástroje jako jsou například jq, JMESPath nebo jql. Jsongrep je napsaný v programovacím jazyce Rust, zdrojový kód je dostupný na GitHubu.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2026. Na programu je celá řada zajímavých přednášek a workshopů. Vstup na konferenci je zcela zdarma, bez nutnosti registrace. Přednášky lze sledovat i online na YouTube.
Mozilla a společnost Mila oznámily strategické partnerství za účelem rozvoje open source a suverénní AI. Cílem je ukázat, že open source AI může konkurovat uzavřeným systémům. Obě organizace chtějí posílit technologickou suverenitu a snížit závislost na hrstce velkých technologických firem.
Adam Rice předvedl, že pomocí DNS lze distribuovat a spustit kompletní hru DOOM. Rozdělil WAD soubory a binárky do téměř 2000 DNS záznamů v Cloudflare zóně (jeden TXT záznam v DNS může nést okolo 2000 znaků textu). Ty pak stáhl PowerShellem, dekomprimoval a spustil přímo v paměti počítače bez nutnosti zápisu na disk, což prakticky dokazuje, že DNS může sloužit jako distribuované úložiště dat a možný kanál pro načítání kódu. Repozitář projektu je na GitHubu.
Dnes a zítra probíhají Arduino Days 2026. Na programu je řada zajímavých přednášek. Sledovat je lze od 17:00 na YouTube. Zúčastnit se lze i lokálních akcí. Dnes v Poličce v městské knihovně a zítra v Praze na Matfyzu.
Byla vydána beta verze Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.04 LTS mělo vyjít 23. dubna 2026.
Byla vydána aktualizována Příručka pro začínající wikipedisty a wikipedistky (pdf).
Ač by se mnou někteří studenti nejspíš nesouhlasili, mým cílem není jim přinést do života peklo. Domácí úlohy samy o sobě snadné nejsou (toho jsme si plně vědomi), tak proč jim ještě víc znepříjemňovat život tím, že když už úlohu pochopí, vyřeší a chtějí odevzdat, že jim to nepůjde?
Máme v každém semestru kolem 300 studentů, z čehož více jak 2/3 předmět nevzdají a domácí úlohy vypracovávají. Na domácí úlohu mají většinou dva týdny, takže přirozeně většina odevzdání probíhá poslední den, především pak navečer před půlnocí. Dovedete si tedy představit, jak nadšení studenti jsou, když zrovna v ten moment nastanou problémy. A nebo téměř kdykoliv jindy.
Náš systém jsme si vyvinuli a postupně ho vylepšili do podoby, kdy je robustní a zvládne daný nápor studentů, odevzdání (v posledním semestru kolem 1500-1800 na úlohu - studenti mohou odevzdávat vícekrát) a domácích úloh. Programátor by řekl, že v tom moment to nejspíš bude fungovat i nadále (koneckonců o čem jiném je testování) - on ví, že systém by již neměl nebo dokonce nemůže selhat (fail-safe), a je o tom přesvědčen do té doby, než mu studenti začnou psát, že to nefunguje.
Tento semestr je obzvláště povedený, co se týče výpadků a chyb, přestože nově nasazované vlastnosti za to nemohou. Zde je seznam věcí, které způsobily problémy:
Tyto chyby mají jednu věc společnou - netýkají se vlastního systému, ale vnějšího prostředí. A v ten moment vám je vlastnost systému, že nemůže selhat, poněkud nedostatečná, neboť neprokývá vnější prostředí, které chybu způsobuje. V ten moment zbývá jediné - logovat, zjistit chybu, a problém vyřešit.
Podělím se zde o příběh s řešením jedné výše zmíněné chyby, díky které jsem toho opravdu tolik nenaspal. Těsně před deadline jedné úlohy jsem byl upozorněn na pomalost systému, tak jsem začal procházet logy a přišel na zvláštní řádek. Tento řádek mluvil o tom, že není možnost poslat přílohu cvičícímu na vyhodnocení. Důsledkem bylo, že přestože student odevzdal a úkol se vyhodnotil, email dorazil jen jemu, ale cvičícímu, který uděluje body, již ne. Student o tom samozřejmě nevěděl, neměl jak. Vypnutí systému nepřipadalo kvůli blížícímu se deadline v úvahu, takže jsem s hrůzou v očích sledoval, jak přes sto studentů odevzdává, a přemýšlel, jak to vyřeším. Napsal jsem tedy email cvičícím, ať body neudělují, že jim dané emaily nechodí, a začal situaci řešit.
Prvně jsem musel přijít na to, co chybu způsobuje, abych jí mohl napravit. Ukázalo se, že chyba je způsobena negenerováním HTML verze zdrojáků v ostrém systému. Paradoxně na mé lokální kopii na stejném stroji to fungovalo. Řešením bylo tuto vlastnost vypnout, posílat zdrojové kódy v plaintextu do té doby, než se to vyřeší. Na fakt, že chyba byla způsobena updatem verze vimu a mě nedostupným konfigurákem vimu (ostrý systém běží pod jiným uživatelem), jsem přišel až asi o dva dny později.
Poučení: Pro obnovu dat je potřeba zamezit reprodukci chyby, nikoliv nutně ji rovnou perfektně opravit.
Spousta studentů však již stihla odevzdat, takže bylo nyní potřeba vyřešit je. Log, do kterého se normálně píší strojově čitelná data ze všech vyhodnocení, a ze kterého se dá udělat znovu odevzdání, byl kvůli chybě neúplný. Naštěstí chybová hláška s nedostupností přílohy byla v jiném logu (celkovém), a byla i s cestou k adresáři s dočasnými soubory vyhodnocení. V tomto adresáři jsou uloženy i obsahy emailů posílané studentům a učitelům. S trochou magie (grep, sed, xargs) jsem tedy tyto emaily vyextrahoval a seskupil do archivů podle cvičících. Mohl jsem jim tedy tato vyhodnocení poslat separátně emailem. A mohl jít spát. (Paradoxně email kvůli zátěži emailového stroje nedošel, a já ho musel poslat ráno znovu.)
Poučení: Logujte několikrát, klidně v různých formátech, ale duplicitně. Pomůže vám to s obnovou v momentě, kdy nějaký log nebude dostupný. A buďme rádi za terminál!
Dalším velmi podstatným faktem je komunikace s okolím. Nebýt upozornění na jiný problém, chyby bych si všiml později, a studenti by ve velkém nadávali, proč nemají body; podobně jako kdyby nějaký cvičící začal o půlnoci rovnou opravovat vyhodnocení domácích úloh. Díky upřímné komunikaci s těmito lidmi předejdete problémům, které se mohou nepřímo dotknout někoho jiného, což rozhodně příjemné není. Podobná situace je dle mého názoru při komunikaci se zákazníkem či v našem případě se studenty - nevědomost je stresující, vede ke konfliktům a k dalším chybám. Komunikace naopak vede ke zklidnění situace a usnadňuje kooperaci v budoucnosti.
Poučení: Dejte o chybě vědět těm, kterých se bezprostředně týká. Oni se uklidní, nebudou vám psát nenávistné emaily a při další chybě budou kooperovat. Chybovat je předci lidské...
Chybám se nevyhnete. Pokud s nimi však nebudete počítat, bude jakákoliv obnova velmi náročná. Více záznamů o chování systému, ze kterého můžete zjistit, co se vlastně stalo, vám dá možnost něco podniknout i v momentě, kdy nějaký ten záznam není. (To samozřejmě neznamená psát do dvou logů naráz, neboť k záznamu nemusí dojít vůbec.) Díky tomu jste schopni chybu vyřešit (ne nutně rovnou opravit) bez nutnosti pomoci od uživatelů, se kterými pokud komunikujete, tak vám nahlásí potom i další chyby, které nevyhnutelně nastanou, abyste je mohli co nejdříve řešit a přinést tak mír celé galaxii :)
Tiskni
Sdílej:
Tyto chyby mají jednu věc společnou - netýkají se vlastního systému, ale vnějšího prostředí.
Komplexnější úlohy je dobré rozdělit na více kroků – v prvním jen přijmeš soubor od studenta, bezpečně ho někam uložíš a potvrdíš studentovi přijetí souboru. A pak teprve řešit další kroky, které jsou závislé na vnějším okolí (tady můžou nastávat problémy, ale nic se neděje, protože vždycky se můžeš vrátit a začít znova zpracovávat data, která jsi získal v prvním kroku).
Paradoxně na mé lokální kopii na stejném stroji to fungovalo. Řešením bylo tuto vlastnost vypnout, posílat zdrojové kódy v plaintextu do té doby, než se to vyřeší. Na fakt, že chyba byla způsobena updatem verze vimu a mě nedostupným konfigurákem vimu (ostrý systém běží pod jiným uživatelem), jsem přišel až asi o dva dny později.
Po každém upgradu je dobré ostrý systém otestovat, alespoň základní scénář.
Nebýt upozornění na jiný problém, chyby bych si všiml později, a studenti by ve velkém nadávali, proč nemají body; podobně jako kdyby nějaký cvičící začal o půlnoci rovnou opravovat vyhodnocení domácích úloh.
Jestli student může přijít o body kvůli tomu, že se někde zasekl nějaký e-mail, tak je to prostě špatně navržený proces. K vyučujícímu by se měly dostat tyto tři stavy:
Souhlasím, že to není ideální řešení, bohužel při daném množství studentů jsme nepřišli zatím na lepší způsob. Dodám však, že cvičící zdrojové kódy po úspěšném projetí testů kontroluje a má právo studentovi zdroják vrátit s tím, že ho zprasil (a děje se to).
K druhé části dodám, že daný předmět je zaměřen především na výuku programovacího jazyka, na úlohy s otevřeným řešením máme k dispozici jiné předměty (naštěstí).
Souhlasím, že to není ideální řešení, bohužel při daném množství studentů jsme nepřišli zatím na lepší způsob.Kolik vas tam je na takove mnozstvi?
Dodám však, že cvičící zdrojové kódy po úspěšném projetí testů kontroluje a má právo studentovi zdroják vrátit s tím, že ho zprasil (a děje se to).Pak je to OK. Osobne preferuji oba pristupy soucasne.
Takove automaticke testovani sice setri cas, ale podle me to neni uplne dobre.to mi pripomina jednu diskuzi na rootu
chyba byla způsobena updatem verze vimuNo to mi vysvětli, jak vim ovlivňuje serverovou aplikaci?
Btw: celem mi to silne pripomina continous integration (nekam poslu zdorjaky, pusti se vuci nim definovane testy, o vysledkou jsou informovani dani uzivatele). Nepremysleli jste nad reseni, ze puzijete nejkay CI server, pripadne si jej upravite podle toho, co vam tam chybi, misto vyvijet nejake vlastni resesni? Co se zbytku tyce (vypadky SVN, vysoky load na serveru, plny disk) - monitorovat to treba Nagoisem by melo zajistit minimalne vcasne informovani administratora, pripadne rovnou nekde spustit skripty, co se postaraji o napravu (napr. pridaji misto na disku)
nebo dokonce to, ze prijemce dostane jen cislo revize a udela si checkou zdrojaku ze SVN sam?Na prohlížení je ideální odkaz na pohled na danou revizi přes web.