Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.3 (𝕏, Mastodon). Přehled novinek a vylepšení v poznámkách k vydání.
Byla vydána nová verze 14.4 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Databáze DuckDB (Wikipedie) byla vydána ve verzi 1.5.0. S kódovým názvem Variegata (husice rajská). Přináší řadu vylepšení, včetně nového ergonomičtějšího CLI klienta nebo podporu pro typ VARIANT a vestavěný typ GEOMETRY.
V pátek 6. a sobotu 7. března proběhl v pražském sídle Nejvyššího kontrolního úřadu (NKÚ) Hackathon veřejné správy 7.1. Publikovány byly vytvořené aplikace. V kategorii projektů rozvíjených z krajského kola zvítězil tým „Mackokládi“. Čtyři středoškoláci ze Dvora Králové uspěli s aplikací KompaZ. Jde o digitálního průvodce, který pomůže s rychlou a srozumitelnou orientací v životních i krizových situacích „krok za krokem“. Aplikace
… více »QGIS, svobodný desktopový GIS, byl vydán v nové hlavní verzi 4.0. Změny zahrnují několik nových analytických a editačních funkcí, rozšíření podpory 3D, více možností úprav uživatelského rozhraní či mnoho dalších zlepšení použitelnosti. Řada 3.44 má aktualizace plánovány do září.
Dan Blanchard vydal knihovnu pro Python chardet v nové verzi 7.0.0. S novou verzí byla knihovna přelicencována z LGPL na MIT. Souhlasili s tím všichni přispěvatelé? Dan Blanchard souhlasy vůbec neřešil. Zaúkoloval umělou inteligenci (Claude), aby knihovnu zcela přepsala a výslovně jí nařídil, aby nepoužila žádný LGPL kód. Dan Blanchard tvrdí, že se jedná o clean room design. Protistrana argumentuje, že umělá inteligence byla trénována
… více »Andy Nguyen si na svou herní konzoli PlayStation 5 (PS5) pomocí exploitu Byepervisor nainstaloval Linux (Ubuntu). V Linuxu si spustil Steam a PS5 tak proměnil v Steam Machine. Na PS5 může hrát hry, které jsou vydané pouze pro PC a jsou na Steamu [Tom's Hardware].
Správce sbírky fotografií digiKam byl vydán ve verzi 9.0.0. Jedná se o větší vydání provázené aktualizacemi knihoven. Mnoho dílčích změn se vedle oprav chyb týká uživatelského rozhraní, mj. editace metadat.
Byla vydána verze 2026 distribuce programu pro počítačovou sazbu TeX s názvem TeX Live (Wikipedie). Přehled novinek v oficiální dokumentaci.
Jihokorejská Národní daňová služba (NTS) zabavila kryptoměnu Pre-retogeum (PRTG) v hodnotě 5,6 milionu dolarů. Pochlubila se v tiskové zprávě, do které vložila fotografii zabavených USB flash disků s kryptoměnovými peněženkami spolu se souvisejícími ručně napsanými mnemotechnickými obnovovacími frázemi. Krátce na to byla kryptoměna v hodnotě 4,8 milionu dolarů odcizena. O několik hodin ale vrácena, jelikož PRTG je extrémně nelikvidní, s denním objemem obchodování kolem 332 dolarů a zalistováním na jediné burze, MEXC [Bitcoin.com].
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.