Byl vydán Mozilla Firefox 146.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 146 bude brzy k dispozici také na Flathubu a Snapcraftu.
Před rokem převzala Digitální a informační agentura (DIA) vlastnictví a provoz jednotné státní domény gov.cz. Nyní spustila samoobslužný portál, který umožňuje orgánům veřejné moci snadno registrovat nové domény státní správy pod doménu gov.cz nebo spravovat ty stávající. Proces nové registrace, který dříve trval 30 dní, se nyní zkrátil na několik minut.
IBM kupuje za 11 miliard USD (229,1 miliardy Kč) firmu Confluent zabývající se datovou infrastrukturou. Posílí tak svoji nabídku cloudových služeb a využije růstu poptávky po těchto službách, který je poháněný umělou inteligencí.
Nejvyšší správní soud (NSS) podruhé zrušil pokutu za únik zákaznických údajů z e-shopu Mall.cz. Incidentem se musí znovu zabývat Úřad pro ochranu osobních údajů (ÚOOÚ). Samotný únik ještě neznamená, že správce dat porušil svou povinnost zajistit jejich bezpečnost, plyne z rozsudku dočasně zpřístupněného na úřední desce. Úřad musí vždy posoudit, zda byla přijatá opatření přiměřená povaze rizik, stavu techniky a nákladům.
Organizace Free Software Foundation Europe (FSFE) zrušila svůj účet na 𝕏 (Twitter) s odůvodněním: "To, co mělo být původně místem pro dialog a výměnu informací, se proměnilo v centralizovanou arénu nepřátelství, dezinformací a ziskem motivovaného řízení, což je daleko od ideálů svobody, za nimiž stojíme". FSFE je aktivní na Mastodonu.
Paramount nabízí za celý Warner Bros. Discovery 30 USD na akcii, tj. celkově o 18 miliard USD více než nabízí Netflix. V hotovosti.
Nájemný botnet Aisuru prolomil další "rekord". DDoS útok na Cloudflare dosáhl 29,7 Tbps. Aisuru je tvořený až čtyřmi miliony kompromitovaných zařízení.
Iced, tj. multiplatformní GUI knihovna pro Rust, byla vydána ve verzi 0.14.0.
FEX, tj. open source emulátor umožňující spouštět aplikace pro x86 a x86_64 na architektuře ARM64, byl vydán ve verzi 2512. Před pár dny FEX oslavil sedmé narozeniny. Hlavní vývojář FEXu Ryan Houdek v oznámení poděkoval společnosti Valve za podporu. Pierre-Loup Griffais z Valve, jeden z architektů stojících za SteamOS a Steam Deckem, v rozhovoru pro The Verge potvrdil, že FEX je od svého vzniku sponzorován společností Valve.
Byla vydána nová verze 2.24 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
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.