Na chvíli jsem se teď na hlavní pracovní stanici po letech se SSD vrátil k čistě rotačním diskům (HDD), protože jsem si potřeboval udělat pořádek v datech a soubory se přeci jen rychleji přesouvají v rámci jednoho souborového systému (i když je na pomalém HDD) než mezi více oddíly nebo fyzickými disky. A dostatečnou kapacitu jsem měl jen na HDD. Původní plán byl, že soubory roztřídím podle toho, jak a jak často s nimi pracuji a umístím na různě rychlé disky (v počítači jsem měl kombinaci asi šesti různých SSD a HDD disků). Úklid sice celkem úspěšný byl, ale navrhnout rozdělení souborů na různě rychlá úložiště bylo složitější. Buď bych to musel řídit ručně a mít data na více souborových systémech (původní stav jen s lépe rozmístěnými soubory) nebo si softwarově vytvořit hybridní disk (ty se prodávaly v dobách, kdy flash paměti byly drahé na to, aby se z nich poskládal celý disk – šlo o HDD+SSD v jednom SATA disku, kde SSD sloužilo jako rychlá cache pro HDD). To se dá postavit nad bcache, dm-cache, Flashcache atd. Ale protože to pracuje na úrovni blokového zařízení, nejde říct, kde mají které soubory být a funguje to automaticky. Problém je v tom, že systém neví, které soubory potřebuji číst rychle (byť třeba jednou za dlouho) a u kterých je mi to jedno (i když je můžu číst relativně často).

Nakonec jsem usoudil, že 4 TB M.2 NVMe disky už nejsou tak drahé a nejlepší a zároveň nejjednodušší bude mít všechna data na rychlém SSD/NVMe zařízení. Zároveň se ale nechci vzdát bezpečí zrcadleného pole (RAID 1). V tomto článku si tedy ukážeme, jak složit diskové pole z více různě rychlých zařízení a jak mu říct, že má číst přednostně z těch rychlých.

Git a Mercurial jsou stejná generace verzovacích systémů: distribuované VCS. Vznikly v roce 2005 jen pár měsíců po sobě. Jednou z nevýhod Gitu oproti Mercurialu je to, že nepodporuje kopírování souborů. Zatímco v Mercurialu máme hg mv a hg cp, v Gitu máme jen git mv. Soubor – myšleno včetně jeho historie – můžeme v Gitu jen přesunout, ale ne zkopírovat. Tedy alespoň ne jednoduše… V dnešním článku si ukážeme trik, jak i v Gitu soubory kopírovat včetně jejich historie nebo přesouvat jejich části jinam, což se hodí obecně, i např. v Mercurialu nebo jiných VCS.

Petrolejky, které běžně potkáváme na půdách a v kůlnách, jsou většinou buď vojenské Feuerhand (a jejich následovníci jako Meva), případně pokojové lampy jako z písničky Dáme si do bytu (1958). Tyhle lampy mají knot, hoří žlutým plamenem a kromě světla a tepla produkují občas nějaké ty saze. Vedle těchto jednoduchých petrolejek existují ale i technicky vyspělejší tlakové lampy, které svítí jasnějším světlem. Na jednu takovou se dnes podíváme.

Když nepočítám televizi a rozhlas, pro předpovědi počasí si většinou chodíme na nějakou webovou stránku, kterou si zobrazujeme v prohlížeči. Dnes si ukážeme, jak si stáhnout předpověď počasí ve formátu XML přes API poskytovatele a zobrazit si ji v textovém terminálu díky jednoduchému skriptu, který si napíšeme.

Když se řekne „jmenný prostor“, hodně lidí si představí xmlns v XML nebo balíčky v Javě odvozené od internetových domén. Jmenné prostory jsou ale obecný koncept, se kterým se setkáme prakticky všude a odvozovat je můžeme i jinak. Dobře definovaná jména (názvy) jsou pak nutným předpokladem prakticky veškerého uvažování a komunikace.

V tomto článku se podíváme na různé příklady jmenných prostorů a souvislosti mezi nimi. Ukážeme si, jak vytvořit jmenný prostor i bez placení a internetové domény – a dokonce i anonymně a bez závislosti na nějaké centrální autoritě. Nahlédneme do zajímavého světa RDF a ukážeme si, jak vytvářet URI, která budou globálně unikátní jednou provždy.

Problém s tiskárnami je, že… Nechci dnes mluvit o hardwarových závadách (jako že vám třeba zaschne náplň v inkoustové tiskárně), ale o těch softwarových. V dobách, kdy jsme běžně k počítačům připojovali jehličkové tiskárny pomocí paralelního portu, byla situace v lecčems jednodušší – s tiskárnou jsme komunikovali více napřímo a ta poslušně plnila naše příkazy (takže jsme si třeba potiskli místo papíru válec, když jsme zadali špatné rozměry). S tím, jak roste komplexita softwaru, přibývají v systému další mezičlánky – a ty občas kompenzují chyby uživatele a jindy mu přidělávají starosti. Potištěných válců ubylo, ale zmuchlaných papírů v koši je pořád dost.

Třetím dílem dnes zakončíme sérii věnovanou komplexitě softwaru (co to je, jak vzniká). Podíváme se na možná řešení tohoto problému a zejména na prevenci, protože úspěšný boj s komplexitou zpravidla začíná už v době návrhu.

Dnes se podíváme na příčiny vzniku komplexity, a navážeme tak na předchozí díl této série.

Když dělník kope příkop nebo zedník staví zeď, má se za to, že každý metr představuje část hotové práce a budoucí užitek. Jistě, občas se stane, že se příkop nebo zeď udělají někde jinde, než měly být, nicméně to není moc časté a tyto chyby se obvykle rychle odhalí. Ale když programátor píše (či jinak vnáší) kód zapojený do výsledného produktu, nemůžeme říci, že bychom se s každým dalším řádkem kódu blížili cíli. Spojitost mezi množstvím kódu a budoucí užitečností je velice nejistá.

Ba naopak – množství zdrojového kódu je třeba vnímat spíše jako negativní hodnotu a budoucí náklad, než jako hotový díl práce (pozitivní hodnota). Pokrok můžeme měřit množstvím implementovaných požadavků, ale určitě ne množstvím kódu.

Přestože mám různých baterek spoustu, chtěl jsem si udělat radost a pořídil jsem si měděnou verzi Olight S2R. Je to věc spíš do sbírky a je opravdu krásná. Má ale i jednu nepěknou vlastnost, která jde naštěstí řešit, a o tom bude tento článek.