Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2024. Ke konci roku 2024 vlastnila 305 180 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250211 mikrokódů pro své procesory řešící 5 bezpečnostních chyb.
Byla vydána nová verze 1.24 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
Jiří Eischmann upozorňuje, že GNOME nemá české překladatele: "Posledních minimálně 15 let byly překlady GNOME do češtiny ve výborném stavu. U každého vydání jsem jen hlásil, že je vše přeložené, poslední roky to platilo i pro drtivou většinu dokumentace. Poslední rok se to ale začalo zadrhávat. Přispěvatelé, kteří to dlouhé roky táhli, odešli a není nikdo, kdo by to po nich převzal. Proto jsme se rozhodli jít s pravdou ven: GNOME momentálně nemá české překladatele a pokud se toho neujme někdo nový, překlady začnou postupně upadat."
Otevřený zvukový bezztrátový kodek FLAC (Free Lossless Audio Codec, Wikipedie) byl vydán v nové verzi 1.5.0. Hlavní novinkou je podpora vícevláknového kódování. V prosinci loňského roku byl FLAC formálně specifikován v RFC 9639.
Evropská unie hodlá iniciovat investice do rozvoje umělé inteligence v hodnotě 200 miliard eur, v přepočtu zhruba pět bilionů korun. V projevu na summitu o umělé inteligenci v Paříži to v úterý řekla předsedkyně Evropské komise Ursula von der Leyenová. Umělá inteligence podle ní může přispět mimo jiné ke zvýšení konkurenceschopnosti.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.3 (Mastodon). Přehled novinek i s videi a se snímky obrazovky v oficiálním oznámení. Podrobný přehled v seznamu změn.
Lennart Poettering se na Mastodonu rozepsal o novince v systemd, na které pracuje: systemd bude umět nabootovat z obrazu disku staženého pomocí HTTP v rámci initrd.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2025.2. Nově lze zálohovat také na Google Drive a Microsoft OneDrive.
V kinech aktuálně běží animovaný film Kočičí odysea, v originálu Flow, (Wikipedie) vytvořený v Blenderu. Film získal řadu ocenění a má dvě nominace na Oscary 2025. Na ČSFD má 80 %. Režisérem je Gints Zilbalodis. Rozhovor s režisérem na stránkách Blenderu.
System.getProperty
? Okay, tu metodu nemusíte vůbec měnit, můžete si nadiktovat posloupnost návratových hodnot té metody System.getProperty
a nechat bajtkódovou magii mockovacího frameworku, ať se postará.)
Pokud používáte Javu, můžu doporučit kombinaci JUnit+Mockito+PowerMock, pokud Céčko, dobře vypadá Cmockery od Googlu (ale nezkoušel jsem), pokud něco jiného, možná poradí někdo jiný.
Až to zmáknete, tak časem zjistíte, že by bylo dobré pouštět testy automaticky při každém commitu do repozitáře a nainstalujete si nějaký continuous integration server (z javovského světa můžu doporučit TeamCity, které je do určitého omezení zdarma, ale není open-source, příp. je docela oblíbený Hudson, jehož nekorporátní verze se teď kvůli nějakým rozmíškám v Oraclu jmenuje Jenkins; Céčkaři tuším používají Buildbot, ale neznám).
Ještě později zjistíte, že některé testy běží výrazně pomaleji než jiné (typicky ty, které sahají na disk nebo do databáze, komunikují přes síť apod.) a že by nebyl špatný nápad pouštět je méně často, třeba v noci. Takové testy přesunete do vedlejšího adresáře, nazvete je integrační testy, a to, co zůstane v původním adresáři, budou unit testy. Gratuluju, jste na vyšším levelu a můžete poučovat začátečníky, jako jste byl sám. Konec dobrý, všechno dobré.
Poznámka pro odborněji zaměřené: V textu výše jsem úplně ignoroval "mimofunkční" testy (nevím, jak to líp nazvat, možná "testy mimofunkčních požadavků"?), a to prostě proto, že by to byl ještě další rozměr bordelu navíc.
System.getProperty
, tak to byl extrémní příklad. Ale ani ten se nezabývá postupem, ale prostě to je whitebox test. So what? S dependency injection (i pro takové věci jako právě systémové proměnné) a rozhraními všude je to jednodušší a nemusí se tolik sahat k těm whiteboxům, ale holt nežijeme v ideálním světě.
Takže, abychom si rozuměli. V prvním odstavci podávám užitečnou definici unit testu (ne svoji). Ve druhém odstavci upozorňuju na existenci knížky Working Effectively with Legacy Code. Ve třetím odstavci tvrdím, že namísto dlouhého studia je lepší se do toho vrhnout po hlavě, že člověk velmi brzo začne přemýšlet, jak strukturovat kód tak, aby byl testovatelný, a že s ledasčím mohou pomoci mockovací frameworky. Ve čtvrtém odstavci odkazuju na pár knihoven pro testování, v pátém odstavci zmiňuju CI a odkazuju na pár nástrojů, v šestém odstavci dělám čáru mezi unit testy a integračními testy na tom místě, kde se obvykle dělá. V sedmém odstavci zmiňuju, že jsem vůbec nezmiňoval testy mimofunkčních požadavků. V žádném odstavci nezmiňuju testy, které ověřují postup operací namísto jejich výsledku (i když i to může být někdy užitečné).
Poznámka k vašemu poslednímu odstavci: Ke špatnému kódu je klíčové napsat testy ještě před jeho přepisem, protože zcela typicky se při tom přepisu něco po**re. Detailně to rozebírá kniha, na kterou už jsem odkazoval.
Jakýkoli test je lepší než žádný test, za čímž si stojím a je mi fuk, jestli s tím třeba nesouhlasíte.Ano, s tím nesouhlasím. protože ten „jakýkoli“ test má typicky nulovou (nebo blízkou nule) vypovídací hodnotu o kódu, náklady na jeho psaní a údržbu ale zůstávají, resp. náklady na údržbu špatného testu špatného kódu jsou vyšší, dobře napsaný test není potřeba při změně implementace upravovat.
V žádném odstavci nezmiňuju testy, které ověřují postup operací namísto jejich výsledku (i když i to může být někdy užitečné).Nezmiňujete je explicitně. Ale všechny tyhle testy, které intenzivně používají mock objekty, runtime úpravy kódu, DI apod. testují postup operací a ne výsledek.
Ke špatnému kódu je klíčové napsat testy ještě před jeho přepisem, protože zcela typicky se při tom přepisu něco po**re.Pokud ovšem dokážete napsat opravdu jednotkové testy, které testují výsledek operací. Což je ale u špatného kódu velmi vzácný případ. Jinak si sice napíšete testy předem, ale ty vám po změnách kódu nebudou procházet (nebo spíš nepůjdou ani zkompilovat). Takže je budete muset pro nový kód upravit. K čemu pak ale takové testy jsou?
pokud máte objekt, který závisí na spoustě dalších složitých objektů, odpověď na otázku „jak takový objekt správně testovat“ není „doplnit mock objekty nebo stuby“, ale „rozdělit kód na menší objekty s menším počtem vazeb – a testování pak už půjde samo“Okay, tak v tomhle se neshodneme. Pokud ta refaktorizace není vyloženě triviální (ideálně jen posloupnost operací nějakého refaktorovacího nástroje, těm se dá už dneska docela věřit), jsem toho názoru, že odpověď je: Namísto těch složitých objektů použijte mocky a napište test. Potom refaktorujte. Postupujte po jednoduchých krocích, po každém kroku opravte test a ověřte, že pořád prochází. Oprava testu v takovém případě typicky znamená opravu kódu, který konstruuje strom objektů (setup fáze), možná přesun nějakých metod z jedné třídy do druhé, neznamená to, že by se ten test pořád musel překopávat od začátku do konce. Netvrdím, že mocky jsou spása všehomíra, ale jak jsem říkal, "ledacos zvládnou vyřešit".
Tiskni
Sdílej: