Za poslední dny, i když se to nezdá, jsem na blogu udělal 116 commitů ve 24 pull requestech. Něco z toho je vidět přímo tady na webu, to podstatné se ale odehrálo pod kapotou. Ale nejdřív prostý výčet toho, co se povedlo:

Co je hotové

• audio jako plnohodnotný typ postu, citace s atribucí a chat posty
• tvrdá zalomení a task listy v markdownu
• médium si post nárokuje jen tehdy, když je text opravdu popisek — 104 starých příspěvků se tím přesunulo do správného typu
• menu ukazuje jen typy, které web skutečně má, takže AUDIO ani CHAT tu zatím neuvidíte; objeví se samy s prvním takovým postem
• aktivní položka v menu je konečně barevně odlišená a první položka se jmenuje Vše, ne Domů
• časová zóna se respektuje i při zobrazení, nejen při zápisu
• naplánované publikování — draft s budoucím datem se pustí ven sám
• vlastní favicon a ikona pro plochu na iOS
• widget s posledními příspěvky z Bluesky a obecný widget na jakékoliv RSS

Pod kapotou — z nástroje pro jeden blog je projekt

Tohle je ta část, kvůli které se ty čtyři dny nedají shrnout do odrážky.

Nástroj, o kterém jsem tu celou dobu psal, přestal být nástrojem jen pro tenhle web. Vytáhl jsem engine do separátního repozitáře pod názvem blog.sh, dal mu licenci MIT a od 30. července je veřejný.

Skoro to i platilo. Skoro — protože to znamená, že v kódu nesmí zůstat nic mého. Barvy webu, které byly natvrdo v CSS, se přestěhovaly do konfigurace: sedm barev pro světlý a sedm pro tmavý režim, zbytek se z nich dopočítá.

Všechny texty se přeložily do skutečných locale souborů, takže engine mluví česky, anglicky a nově i německy — a to jak na webu, tak i v průvodci v terminálu. Konfigurace a grafika každé instalace žijí mimo git, aby si kdokoliv mohl aktualizovat kód, aniž by si přepsal vlastní banner.

Nejlepší test je druhá instalace, takže existuje: blogsh.app, web o tomto enginu, postavený tímto enginem. Dva weby na jednom kódu odhalí za týden víc než měsíc přemýšlení, co by se mohlo pokazit.

Změnil se i způsob, jakým se sem dostávají změny. Dřív jsem kód na server kopíroval rsyncem. Dnes je server obyčejný git klon a nová verze se nasazuje git pullem — sean.cz sleduje moji pracovní větev, blogsh.app jen to, co je vydané.

Z jednoho migračního skriptu se také mezitím stal celý importní podsystém. Umí sedm zdrojů — Bluesky, Mastodon, Pixelfed, Tumblr, Twitter/X, WordPress s RSS a od včerejška Instagram — a ke každému se dostanete jak průvodcem, tak skriptem, přičemž pod tím běží jediná implementace. Import taky přestal být operace, kterou spustíte omylem: potvrzuje se opsáním počtu příspěvků, ne stiskem y. Když jednou naliju do webu dva tisíce cizích postů, chci to mít na svědomí vědomě.

Podobně se otevřelo nasazování. Surfer, který tenhle web hostuje, byl původně jediná možnost; dnes jsou vedle něj místní adresář, rsync, git (a tím i GitHub Pages), rclone a SFTP. Pojistky proti tomu, aby rozbitý build smazal půlku webu, platí pro všechny stejně.

A protože komentáře pod články sem tahám z Mastodonu, dostala stejnou možnost i druhá síť: web může komentáře a oznamovací příspěvky vést přes Bluesky. Buď jedno, nebo druhé — sčítat reakce ze dvou sítí do jednoho vlákna nedává smysl.

Nakonec terminál. Průvodce, o kterém jsem psal minule jako o číslovaném menu, umí šipky, jednoklávesové odpovědi a vlastní QR kód — po založení draftu se rozsvítí na obrazovce a jeho vyfocením mám náhled rozepsaného textu v telefonu. Žádná knihovna, ten kodér je taky součást repozitáře.

Zbytek těch čtyř dnů spolykala dokumentace a testování na cizích strojích — instalace na Macu, na Linuxu a na Windows přes WSL. Cíl je jednoduchý: kdo si to chce nainstalovat, ať to zvládne bez ptaní.

Chyby, které to vytáhlo na světlo

• nový příspěvek se stejným názvem ve stejném roce tiše přepsal ten starší
• nedotčený draft se publikoval, jako by měl ručně zadané datum, a přišel tím o oznamovací příspěvek — tedy i o komentáře
• odstavec zabalený do <div> se rozsekal na blok za každý kus a cestou přišel o tučné písmo
• HTML entity, které nebyly v převodní tabulce, mizely i s písmenem uprostřed slova
• příliš dlouhý nadpis vyrobil čtyřsetznakovou adresu příspěvku
• náhled importu hlásil nula médií, tedy přesně to číslo, kvůli kterému náhled existuje
• neodpovězený dotaz na zdroj importu vybral poslední položku místo toho, aby akci zrušil
• drafty nešlo smazat z nabídky hned po uložení
• politika obsahu tiše blokovala skript s překlady, takže se texty vykreslované v prohlížeči zobrazovaly prázdné a nic to nehlásilo

Co dál?

Soustředil jsem se teď na release verze 1.0, přípravu webu ./blog.sh, něco designu, a také už připravuji další funkcionality. Pár nápadů už mám. Hlavně ale zítra bude ten den, kdy to všechno vypustím do světa a jsem zvědavý, zda budou vůbec nějaké reakce a zda budou pozitivní, a nebo ne. Těším se, a zároveň mám i obavy. Uvidíme.

Když jsem tu naposledy psal o tom, jak je tenhle blog postavený, manage-post.sh uměl v podstatě tři věci: napsat, upravit a smazat. Fungovalo to, ale mělo to pár much, na které jsem přišel až za provozu — a protože je psaní kódu k tomuhle blogu skoro stejná zábava jako psaní příspěvků, sedl jsem si a předělal to. Tenhle post je o tom, jak s příspěvkem pracuju teď.

Draft, ne rovnou na web

add nikdy nepublikuje rovnou. Vždycky vznikne draft s vlastní skrytou adresou (/draft/<náhodný token>/...) — dá se otevřít z telefonu i uprostřed rozepsaného textu, ale nikdo jiný ji neuhodne, protože není nikde odkazovaná ani v žádném výpisu. Teprve když jsem s textem hotový, přijde na řadu skutečná otázka: publikovat, nechat rozepsané jako draft, nebo se vrátit zpátky do editoru.

Publish uměl jednu ošklivou věc

Tohle byla ta nejzávažnější chyba, na kterou jsem přišel: publish post publikoval okamžitě, jakmile jsem vybral slug ze seznamu. Žádný náhled, žádné "jsi si jistý" — jen holé rozhodnutí udělané za mě. Chtěl jsem se ale ještě podívat, jak draft vypadá, než ho pustím ven. Teď publish udělá přesně to, co add po založení — ukáže náhled a zeptá se, co dál. Skutečnou publikaci spouští až vědomá volba v tom menu, ne samotné zavolání příkazu.

Unpublish — zpátky do šuplíku

Přibyla i opačná operace: unpublish vrátí publikovaný příspěvek zpátky do draftu. Hodí se, když si po publikaci všimnu překlepu, který nechci opravovat narychlo, nebo když se rozhodnu text ještě pořádně přepracovat. Součástí je i smazání přidruženého tootu na Mastodonu přes jeho API — jinak by po dobu, než příspěvek zase publikuju, na síti visel odkaz na stránku, která dočasně neexistuje. Při další publikaci navíc dostane nové, aktuální datum — chová se to jako čerstvě napsaný text, ne jako by se jen tiše přemístil v archivu.

Koš místo nevratného smazání

delete dřív smazal JSON i všechna přidružená média natvrdo. Žádný git u obsahu, žádná záloha — jeden překlep ve slugu a je to pryč. Teď delete přesouvá všechno do trash/, a restore <slug> to vrátí přesně tam, kde to bylo. Není to plnohodnotná historie verzí, jen jedna úroveň zpět — ale přesně to mi chybělo.

Toot na požádání

Někdy zůstane příspěvek bez tootu zajišťujícího vaše reakce z Mastodonu — třeba u starých migrovaných věcí z Tumblru, nebo když se odeslání tootu při publikaci nepovede (výpadek sítě, expirovaný token). Dřív jsem s tím nemohl nic dělat jinak než ručně. Nový příkaz toot <slug> pošle komentářový toot dodatečně, ke komukoliv publikovanému, kdykoliv. Existující toot ale nikdy nepřepíše — když už jeden je, druhý se neposílá, protože pro to není důvod.

Průvodce pro dny, kdy zapomenu příkazy

Nástroj má dnes devět různých akcí a nechci si je pamatovat nazpaměť pokaždé, když sednu k psaní. Stačí teď spustit ./blog.sh bez ničeho a naskočí jednoduché číslované menu — vyberu si, co chci udělat, a po dokončení se vrátím zpátky do stejného menu, dokud neřeknu konec. Přesná stejná logika jako předtím u CLI, jen v přívětivější podobě pro dny, kdy nechci nic ťukat z hlavy.

Přejmenování a co bude dál

Nakonec i drobnost: manage-post.sh jsem přejmenoval na blog.sh — název, který sedí líp k tomu, co ten nástroj dneska umí, a protože nezůstal svázaný jen s prací nad jedním příspěvkem. Zbytek pojmenování v repozitáři (deploy-web.sh, refresh-sidebar.sh) jsem záměrně nechal být — dělají jinou, úzce vymezenou práci a přejmenování by tomu nic nepřidalo.

Chtěl jsem tu změnit barvu odkazů. Jeden řádek ve stylech. Spustil jsem deployment a s hrůzou v očích koukal, jak se na server nahrává šest tisíc souborů.

Nic se nerozbilo, ale bylo jasné, že něco je velký špatný.

Může za to vychytávka

Každá stránka měla v hlavičce otisk obsahu stylů:

<link rel="stylesheet" href="/assets/css/site.css?v=a3f9c21b04">

Když se styly změní, změní se adresa a prohlížeč si stáhne novou verzi místo té nacachované. Dal jsem to tam schválně a byl na to docela pyšný.

Jenže se tím otisk propsal do každé stránky webu. Změním jeden znak v CSS, změní se všech 6 228 stránek — a deploy skript, který umí posílat jen to, co se skutečně změnilo, to poslušně pošle všechno.

Když jsem se podíval, co vlastně moje úložiště posílá prohlížečům, došlo mi to:

$ curl -sI https://sean.cz/assets/css/site.css
cache-control: public, max-age=0
etag: W/"409e-19f9a201251"

max-age=0 znamená, že se prohlížeč u každého načtení stejně ptá, jestli se soubor nezměnil. Ta vychytávka nebyla nikdy potřeba. Řešila problém, který jsem neměl, a způsobila ten, co jsem měl.

Nový příspěvek přepsal celý archiv

Stránky výpisu se stránkovaly odshora: deset nejnovějších na první stranu, dalších deset na druhou. Nový příspěvek se zařadí na začátek a posune všechno ostatní — hranice všech 328 stran se posunou s ním. Nový post tak znamenal přepsat cca 435 souborů.

Spravilo se to obrácením směru. Desítky se teď počítají od nejstaršího příspěvku, takže nejstarší desítka je navždycky stejná a nový text se přidá jen do té poslední, rozepsané stránky.

Daň je, že /page/1/ dneska znamená nejstarší příspěvky, ale to nevadí, protože se na ně chodí přes „Novější / Starší".

Věc, kterou jsem nečekal

Při ověřování jsem přidal zkušební příspěvek a čekal devět změněných souborů. Vyšlo jich 65 — a byly mezi nimi stránky, které s tím textem nemohly mít nic společného.

Ukázalo se, že když web přegeneruju dvakrát za sebou, pokaždé vyleze trochu jiný výsledek. Příspěvky se řadí podle data a Ruby negarantuje, který ze dvou se stejným datem skončí první. A po stěhování z Tumblru a Twitteru má 110 příspěvků úplně stejné datum jako nějaký jiný.

Nic nezměním, spustím build a přesto mám změněné soubory. Vůbec jsem to netušil. Oprava je jeden řádek: když je datum stejné, rozhodne jméno příspěvku.

Měřit, ne hádat

Byl jsem si jistý, co bude nejdražší operací — kopírování 384 MB fotek. Změřil jsem to a představa se rozsypala. Fotky: jedna sekunda.

Nejdražší bylo mazání složky s hotovým webem, 3,8 sekundy. Build ji vždycky smazal celou a hned do ní nasypal zpátky skoro totožných 7 700 souborů. Teď se nemaže; zapisuje se jen to, co se opravdu liší.

Dvě věci mimo rychlost

Komentáře pod články tahám z Mastodonu a jméno autora jsem vkládal do stránky bez ošetření. Jenže jméno účtu si nastavuje kdokoli ve Fediverse — stačilo se přejmenovat na kus kódu, odpovědět mi na toot a nechat si ho spustit v prohlížeči každému čtenáři. Učebnicová díra. Zavřeno.

A postranní panel si tahal poslední tooty a commity přímo v prohlížeči návštěvníka: čtyři a víc dotazů na cizí služby při každém otevření jakékoli stránky. GitHub navíc nepřihlášené pouští jen šedesátkrát za hodinu, takže ta kartička po chvíli mizela. Teď si data stáhne server.

Jak to dopadlo

• změna stylů: z 6 228 souborů na jeden
• nový příspěvek: z ~435 na sedm až devět
• přegenerování beze změny obsahu: z desítek tiše změněných souborů na nulu
• dotazy na cizí služby při otevření stránky: ze čtyř a víc na žádný
• obrázky stažené na úvodní stránce: z desítek na jeden
• build: ze třinácti sekund na sedm a půl

Dvě poučení. Byl jsem si jistý, že problém jsou fotky, a byla to složka, na kterou bych nesáhl ani po dlouhém přemýšlení. A to prohazování pořadí nikdy nespadlo, nic nenahlásilo, nic nerozbilo — jen potichu dělalo práci navíc.

---

Jestli jste četli Jak je postavený tenhle blog, tak ho tenhle článek na pár místech přepisuje — tooty ani commity už se v prohlížeči netahají a složka s hotovým webem se nemaže. Původní text nechávám být; popisoval stav, který tehdy platil.

Podíval jsem se po letech na svůj blog a zjistil, že pro samý microblogging na Twitteru a Mastodonu ten blog vlastně umírá. Protože ho ale mám rád, a chci si ho ponechat i
nadále, rozhodl jsem se, že je čas ho předělat, a to z gruntu.

Nejen nový, lepší, čitelnější design, ale kompletní přesun z Tumbleru, kam jsem byl tak nějak donucen se přesunout kvůli konci Posterous, na vlastní kód. Pár dnů už prgám, a
výsledky se dostavují.

Navíc jsem na nový blog přemigroval obsah nejen z mého starého blogu, ale i některých side projektů, pár tisíc tweetů (takže mohu s klidným svědomím promazat svůj Twitter) a
dost možná i některé další, pokud se mi podaří dohledat exporty.

Co se pozadí týče, učím se Markdown, protože nové posty budou tvořeny právě s jeho pomocí - prostě jen základní formátování, url, obrázek, a to je všechno.

A poběží to, a to doufám že již brzy, na Surferu od OSCloud, tak držte palce...d8-D

Na novém blogu nebudou klasické komentáře, např. přes Disqus, ale přes Fediverse.

Myšlenka je taková, že nový blog post po publikování vytvoří post obsahující odkaz na něj na mém Mastodonu, a moji čtenáři pak, pokud budou chtít,
budou moci reagovat právě na tento post, a jejich reakce se pak budou zobrazovat v komentářové sekci pod postem.

Tento post jen ověří, zda to, co jsme naprgali, skutečně funguje, a nebo zda to ještě potřebuje trochu péče...d8-D

Dnes je to přesně na den 6 let, co jsem začal používat Twitter. Zároveň je to skoro přesně také datum, kdy začal postupný konec mého oblíbeného blogu dodlaně.cz věnovanému chytrým telefonům a komunikátorům (dříve také komunikátory.cz). Nebylo to sice jen kvůli Twitteru, ale tak nějak shodou okolností k tomu prostě došlo, a to bych nyní chtěl změnit.

Říkal jsem si už delší dobu, že by to zase chtělo něco dělat, neflákat se, vždyť jediné, co se změnilo v mé denní rutině je čas, který mohu psaní věnovat, vše ostatní zůstalo. Každý den přečtu kvanta tweetů, některé jen zběžně, některé velmi pečlivě a občas dám na Twitter nebo Facebook, že mne ten či onen článek zaujal. A tady tak trochu narážím.

Většinou se mi totiž líbí technologické články, což samo o sobě není špatně ani dobře, ale je tu jiný problém. Mí přátelé obecně nejsou zcela zaměření jen na technologie, ale zejména na spoustu různých jiných oborů a tak od nic nedostávám kdovíjakou zpětnou vazbu, což je samozřejmě frustrující a celkem na ho**y..d8-D

Přemýšlel jsem chvíli, ověřoval možnosti a schopnosti, a napalo mne využít svou starou dobrou doménu, svůj původní starý twittaccount a vytvořit na nich tweetblog, kde budou právě takové odkazy v množství cca 5 kusů denně. Posty budou publikovány průběžně tak, aby pokryly celý den a i když se na dodlaně zastavíte několikrát denně, najdete tam vždy něco nového.

Zároveň není potřeba kdovíjak řešit redakční systém, grafiku, systém komentářů (ano, příspěvky můžete okomentovat..d8-D), jediné co potřebujete je prostě účet na Twittru a vědět, že na doméně dodlaně.cz je pro vás vždy (věřím tomu) připraveno zajímavé čtení.

Zaměření dodlaně zůstává i nadále, takže to budou linky týkající se chytrých telefonů, ale také tabletů, laptopů, operačních systémů pro ně, někdy ale dojde i k přesahu do dalších oborů, pokud mne něco hooodně zaujme..d8-D

Tak se na vás těším, přijďte, a přijďte v hojné míře..d8-D

Kdysi dávno začala psát má žena Pavlína několik příspěvků na tento blog a myslím si, že i čtivě. Časem jsme si i řekli, že by chtěla mít svůj vlastní blog, nějak jsme to ale nikdy nedotáhli, a to i přesto, že jsme pro ni vymysleli a načrtnuli design toho blogu i jejího osobního avatara.

V posledních týdnech, během převodu z Posterous a krátce poté, jsem se kromě svým blogům věnoval i té staré myšlence na blog pro Pavlínu, a zapracoval jsem na něm. Její blog se jmenuje Greta’s Garb/\ge a ke shlédnutí je zde. Přesunul jsem tam všechny dřívější Pavlíniny články, a pak také její instagramí fotografie, které si tu a tam na blog posílá.

A Pavlína si ten blog opravdu vzala za svůj a už tam odpublikovala i několik nových příspěvků, z čehož máme radost oba, takže vy, kdo chcete, nezapomeňte se podívat na adresu greticka.tumblr.com a všechno si to hezky přečíst..d8-D

Po přesunu svého blogu z Posterous jsem se mu v posledním týdnu trochu věnoval a vyladil k naprosté dokonalosti (rozuměj konečně to vypadá tak, že jsem s ním spokojený) můj "staronový" vzhled.

Původní design, který, jak jsem zjistitl z datumu původních zdrojů, jsem vytvořil již v roce 2005, jsem lehce refreshnul, aby nevypadal až tak staře, vrátil nahoru na titulku velkýho brejláče a je to opět skvělé..d8-D

Celé je to ještě doplněné o poslední tweety, náhledy do Instagramu, diskuse na DISQUS, možnost uveřejnění příspěvku na Twitter, Facebook, G+ a Pinterest a odkazy na mé oblíbené sociální sítě.

Také jsem si řekl, že mě blogování bavilo a tak že se jím zase budu trochu bavit, a třeba to pobaví i někoho dalšího, což by bylo asi úplně nejlepší.

Tak nezbývá než doufat, že to já a Tumblr vydržíme a že nebudu muset příspěvky přenášet v dohledné době někam jinam.

Rád fotografuji, to není žádná novinka, jen konstatování něčeho, co o mně někteří lidé již ví. Každý, kdo fotografuje (vím, říká se tomu fotograf, ale označovat se tak bych si opravdu netroufl), má spoustu fotografií, a občas se stane, že je s některou i spokojen a chce ji zveřejnit.

I já se dostal do tohoto stavu a proto jsem přeměnil svůj bohužel neúspěšný projekt 365 (ano, nevydržel jsem to, 365x po sobě je hrozně dlouho) na SeanoPholio, webové folio mých “nejlepších” fotografií. Na této adrese tedy budete nacházet fotografie, které já sám považuji za povedené.

Fotografie budou průběžně přibývat, to slibuji, nebudou se ale všechny objevovat jako nové příspěvky, protože jsem se rozhodl, že jednotlivé fotografie budu publikovat podle data pořízení. To mi dává větší smysl a umožní to vám i mě pozorovat, zda jsem se s tím focením někam posunul.

Že na webu jsou i nové fotografie tak nebude zřejmé na první pohled, stav si ale snadno ověříte pomocí pohledu do Archivu, kde budou vidět nové archivní položky.

Nezbývá tedy než doufat, že se vám moje fotografie budou líbit, že se na SeanoPholio budete rádi a často vracet a že mi do komentářů budete psát  i své názory na moje focení.