Kalanišovy stránky
POSTŘEHY, NÁVODY a tak...
Tak v téhle oblasti se budou nacházet různé tipy a popisy věcí, co se mi kde zdařily.
 | automaticke_testovani.htm | | cakephp.htm | | digital_na_prutovku.htm |
| elektrika.htm | | git.htm | | hate_nested.htm |
| jaky_prohlizec.htm | | joomla.htm | | kwebcms.htm |
| linux.htm | | opencart.htm | | opensource_a_penize.htm |
Verzování dat
V rámci práce s daty ve verzovacím systému vzniká problém jejich proměnlivosti u jednotlivých uživatelů. To se řešit v zásadě dá, ale každá z těch cest prostě pouze obchází jeden hluboce uložený principiální problém. Databáze vzniky jako skladiště dat s možností jejich odstraňování zevnitř a ne jen ze začátku či konce. Avšak reálně toto většina počítačů neumí provést a ani umět nemůže - na vině je totiž fyzické rozložení dat v paměti a možnosti přístupu k nim. Na vyšších úrovních se to projevuje jako nutnost celý soubor vzít, označit část, která už není potřeba či kam vložit část novou, která už někde je, a uložit ho se změněnými částmi. To chce až nezanedbatelně málo reálného místa (HD videa). Proto vznikla databázová úložiště, kde algoritmy zajišťují, že prázdné místo není problém. Avšak je to tímto kompaktní blok, který nelze snadno verzovat. A vzniká problém - jak triviálně přenášet mezi uživateli změny v datech takového blobu?
- Nultý způsob je nemít databázi jako blob. Taky to jde. Pak totiž stačí normální nástroje.
- První způsob je na toto se vykašlat a prostě data neverzovat. Dojede to hned při první změně struktur.
- Druhý způsob jsou migrace; tím se sice zajistí, že struktura nebude na kousíčky, avšak samotná data to stále neřeší. Navíc musí být zajištěné její spuštění.
- Třetí způsob jsou dumpy. Tedy rozšířená migrace s tím, že se do každé verze přidá dump databáze. Řeší sice data, ale ve chvíli, kdy je commitů víc, citelně narůstá i velikost dat, co se verzují.
- Čtvrtý způsob je replikace. Tohle je fajn když to funguje, nastavovat replikace velkých databází vývojářům je víc než otrava. I s věcmi jako je Docker.
- Pátý způsob je záznam jednotlivých transakcí. Tím myslím všechny dotazy, které vykonávají nad daty úpravy (INSER, UPDATE, ALTER, DELETE, ...). Na to je však potřeba mít ohackované předávání příkazů databázi. A programátoři těchto předávek jsou jedni z opravdu nejlínějších, navíc by museli znát, kam dotazy odsypat. A po stáhnutí je třeba tyto transakce provést a při nahrání doufat, že nenastane konflikt s někým dalším. Dnes v souvislosti s GDPR asi jediný rozumný způsob.
Ideální řešení tohle bohužel nemá. Ten čtverečkovaný papír můžete stříhat od začátku, od konce, můžete ho s opravami přepsat, ale nic do něj nedocpete nebo nevyhodíte, čtverečků je totiž jen konečný počet a pozice jsou dané. Navíc je v počítačích problém tvrdší o to, že se dá přistoupit pouze k sadě sousedních čtverečků, ne jenom k jednomu.
Daňové kecy
Stát chce svůj desátek. Tečka. Je to o to horší, že ty státy jsou dva a každý daní po svém. Plus je, že právě DPH počítají naprosto stejně. V praxi to pro mne znamenalo odladit dotaz, který generuje ceny s daní v závislosti na více faktorech. Základní jsou: stát expedující, stát doručení a stát fakturační. Další závislostí je měna, ve které je to celé provedeno. V každém případě mi tato sranda zabrala celý týden.
E-maily v Oppice
Nadávejme dokola. Náš Velký bráška Malý-měkký měl jednoho dne úžasný nápad. Doplní do produtů Office i poštovního klienta. Jenže on to zase až tak není poštovní klient, jako spíš software na organizaci a spolupráci ve firmě a klienta pošty má jen jako bonus. A s tímto paskvilem, kde se skloubil Schedule32+ a MSMail (znalci vědí), bylo potřeba začít komunikovat. Zpočátku to šlo, protože výtvor jménem Outlook používal poměrně rozumně HTML kódování na formátování zpráv. Ovšem někoho napadlo, že by tenhle klient mohl na zprávy žačít používat formátování textového editoru. Ehm. Takto došlo k poměrně kuriózní situaci, kdy regulérní maily, které jsou naformátované jako webové stránky, se zobrazovaly korektně v osekané verzi jménem OutlookExpress a v plnotučném Outlooku se rozsypaly.
Fór je jednoduchý. Starší Outlook používal (a Express stále ještě používá) jako zobrazovací jádro webový prohlížeč. Velký klient ale používá jádro Wordu. Ha. Word formátuje každou entitu extra. Entitami myslím třeba buňky tabulky nebo odstavce. Nerad používá styly. Takže donutit to k ostylování znamená vyplnit styl pro každou entitu extra. A to je ještě potřeba počítat s chováním defaultních hodnot. Tímto nám jednoduchý mail nakyne asi pětkrát. Většinu řeší plaintext, ale pak přijde někdo, kdo má hlavu jen pro vizáž a komplikace vzadu ignoruje a zábava má délku klidně jednoho dne.
PushPad
Vedení přišlo na Facebook a tam dostalo možnost obdržet nějaké notifikace přímo do prohlížeče. I zaplo tuto možnost. Po nějaké době při otevření prohlížeče vyhopsaly na dotyčné zprávy o posledních aktivitách. Osobně jsem toto viděl velmi vzápětí, když na mne začaly po otevření anonymního okna Chromu na extra stroji skákat upozornění. Netřeba dodávat, že aby notifikace skákala v anonymním okně, je prostě chyba toho, kdo tu funkcionalitu navrhl. Obzvlášť, když jí tam nelze schválit.
Tak, tím je jasno, co je vlastně PushPad. Je to služba nabízející API, přes které umožňuje předávat uživateli do prohlížeče notifikace. A to tak, aby jeden nebláznil s javascriptemm, přes který se to celé řídí. Hezkou vlastností jsou obložená odeslání a tagy. Odložená odeslání prostě znamenají, že se notifikace pošela se zpožděním - třeba zítra. Tagy jsou předpřipravené sady slov, podle nichž lze odeslat notifikaci skupině uživatelů (my to máme třeba na typ stroje a stát). Takže ne jako u twitteru, kde popisují obsah.
Výhrada je k dokumentaci, kde se tvrdí, že k definování cílového uživatele stačí jeho ID v našem systému. Ne. Chce to jako pole uživatelů. Dále vždy chce tagy, ač jsou označené jako volitelné. Tedy v případě nevyužití je třeba je nastavit na null. Tyto hacky jsou označené na Stack Overflow pod javascriptem a že jsou nutné pro php se jeden nikde nedozví. Ve chvíli, kdy jeden splní včechny závislosti, je s tím práce celkem triviální. Prostě se dodají texty a pokud možno absolutní cesty k obrázkům, případně datumy a celé se to pošle.
Zkoušení je též problematické. Prohlížeče totiž notifikace povolují jen s normálním prohlížením a ne v anonymních režimech. A pak notifikace vyskakují i po otevření anonymního okna. V nastavení je třeba mít vůbec zapnutý příjem, pak správně jak doménu, tak port a tohle nastavení je celkem zahrabané. Dotaz na notifikaci totiž neprovede stránka ale prohlížeč.
ReactJS - jak obejít požadavek na statická data
TL-DR: Trik je jednoduchý - do state inicializujte třídu, která je připojená jako modul a bude data podle potřeby vracet. Pro React je to statický link a tak se nevzteká. To, že se vevnitř upravují, ho už nezajímá.
React je stavový. A čeká, že po načtení dat bude měnit stavy. Ne data. Ty jsou u něj statická. Avšak je zde reálný požadavek na změnu dat (pager, search). Jak v takovém případě postupovat? Sám se při změnách dat totiž dost vzteká a nechce, aby mu do nich někdo hrabal. Kolegové frontendisti sestrojili v rámci možností "vohejbák" a zadrátovali tuto funkčnost do kódu. Netřeba říkat, že znovupoužitelnost pro další části byla prakticky na 0. A protože měli k tomu i haldu dalších úkolů, bylo snazší (a hlavně rychlejší), abych si potřebné části dopsal sám. Dlouho jsem laboroval, jakým způsobem vyhledávání řešit. To, že je potřeba React pro každou změnu (a tedy i každý console.log) kompilovat, vůbec nepomáhalo. Nakonec jsem zkusil, jestli jde do state nacpat kromě běžných věcí (hodnota, funkce) i celá třída. Dá. A tato třída nemusí být nějak extra na Reactu závislá. Takže pak React po načtení komponenty si lízne data a dá je třídě. Ta podle dalších nastavené připraví podmínky pro vrácená data. A komponenta si pak řekne o data třídě. Nedochází ji, že tyto data už prošla aplikací filtrů. A to je přesně onen krok, na který si React běžně stěžuje. Takhle vidí pouhý balík dat, ke kterému se může už chovat staticky. Zkoušel jsem tu třídu dávat i do ostatních možných míst, ale tam to blblo.
Likvidace hesla u Win8 a Win10
Návod funguje pro lokální účty na stroji. Ale to zpravidla stačí.
Taková drobná nutnost. Občas je potřeba odstranit heslo na uživatelově stroji. Buď opravdu zavazí nebo se poškodilo úložiště hesel (můj případ - seděl na poškozeném sektoru na disku). Takže i přes opakované zapisování dodaného a odzkoušeného hesla ho nechtěl stroj přijmout. Jak dál? Sežene se NTPasswd Recovery a spustí se. U Win7 a nižších je vše v klidu. U těchto nových nikoliv. Trik je v tom, že tyto Windows aby rychle startovaly, tak normálně hibernují a ne že to opravdu vypnou. A nechávají "poškozený" žurnál NTFS. A takový disk Linux nedovolí otevřít k zápisu. Proto je potřeba na daný disk ještě poštvat "ntfsfix" z ntfstools. A to už chce nějakou Live distribuci. Po ošetření žurnálu vše funguje. Pak teprve mohlo dojít na normální microsoftí "chkdsk".
Další hint je BIOS/EFI. Většina LiveCD startuje v režimu BIOS. Jen některá umí EFI. Proto je potřeba mezi startováním Win a LiveCD v EFI Setupu stroje (už to není BIOS) toto přepínat.
Anti-Agile rant
Mám problém. Spousta manažerů začala používat Scrum jako hlavní způsob řízení vývojove. Jenže někteří (jako já) prostě po ránu netuší, co že vlastně budou dělat. Protože do jejich práce můžou přijít (a zhusta chodí) i požadavky z dalších zdrojů, které jsou však ve finále dost jednotvárné. Navíc je vývojář na hraně mezi umělcem (kvalitní kód JE elegantní) a řemeslníkem. Řemeslník zajišťuje, aby to celé chodilo, a umělec zajišťuje, aby to i vypadalo. Řemeslník nemá s agile problém, protože dostává dodanou práci, kterou má vykonat. Problém je u umělce. Umělec-tvůrce potřebuje různé podněty a ne že bude bouchat jak za pásem. To je pro něj nejlepší cesta k vyhoření. Tvůrce není stroj, do kterého když hodíte nějaké zdroje, tak z něj na požádání vypadne výsledek. A externí požadavky to zpravidla nezachrání, spíš vedou k další frustraci. A dovolená jen na 5 týdnů v roce tohle opravdu nezalepí.
Teď (září 2021) se mi to dějě při vývojí KWCMS3. Skáču mezi projekty, protože potřebuji počkat na nápad na ono elegantní řešení. Ale předtím jsem si musel dát prakticky 2 měsíce pauzu, protože mi ty nápady došly. Z předchozího zaměstnání jsem nejspíš vyhořel. Když jsem se vzpamatoval a podařilo se mi s KWCMS pohnout, tak stejně zase narážím na jednotvárnost. Proto trochu nepozorně přeskakuji na další projekty - součásti, které to k chodu stejně potřebovat bude. Takže místo toho, abych stavěl modul na obrázky po nabouchání několika předchozích modulů, jsem řešil naprosto nesouvisející RemoteRequest, kde jsem doplnil http autentizace a udělal si výhled pro možné budoucí akce. Kdy se k tomu ale dostanu, nevím. Taky jsem se z nervů pustil do věcí v mnou nenáviděném JavaScriptu. Když se napíše pořádně, není to taková hrůza. To ale neznamená, že ho chci mít jako primární jazyk! Ale to hodně odbočuji.
Celé agile je podle mne pokus o implementaci řízení kátedrály do vývoje stylu tržiště. Rozkouskovat to na menší celky, které půjde udělat a hodnotit v rozumné době. Idea hezká jen do chvíle, kdy přijde na to, že tržiště znamená skákat mezi cíli a ne se soustředit na ten jeden - hotový produkt. Vývoj na tržišti daleko chaotičtější, než v katedrále. A produkt na tržišti nemusí být nikdy hotový.
Added 23/9: Tak průser s vyhořením je prý daleko většího rázu.
Added 22/5: Taky nepomáhá špatné provádění, bordel v plánu a nucení introvertů ->. Ideální je nějaký async nástroj, kde se dají zakládat vlákna.
Klíč - Hodnota
Klíč a hodnota. Dvě poměrně základní věci, do nichž lze skrýt spoustu popisování. Základ zkratek. V programování koncept, který umožňuje jednoznačně určit nějakou danou hromádku dat. Tímto konceptem se dá popsat spousta věcí, neboť umožňuje logické třídění a velmi rychlé dohledávání - pokud znáte parametry. Nad touto dvojicí se pak dělají pak tabulky s hashema, které slouží k rychlému dohledávání položek.
Jednou z velmi zajímavých variant je strom. Ve stromech (jako jsou třeba cesty na diskách) určuje finální uložení dat (souborů). Ve stromu je klíčem cesta a hodnotou pak samotný obsah prvku. Ale to není jediná věc. Klíče se dají různě seskupovat, čímž vznikají větve. A ona větev je pak vlastně složka. Neboli obráceně - složka je vlastně balík záznamů, které mají stejnou část klíče (zpravidla počáteční a zpravidla nějak oddělenou). Největší radost bývá strom stromu či jeho varianty - to dostanete meme "chceme hlouběji".
Další zajímavou variantou jsou pak různé hashovací tabulky, které umožňují pseudonáhodný přístup k datům. To zpravidla slouží ke snižování zátěže cílových strojů.
Obojí se pak dá najít v různých databázových systémech - včetně derivátů MySQL. Stromy se přistupuje (uživatel:heslo@doména.databáze.tabulka.sloupec ; vidíte zpravidla jen "sloupec" nebo "tabulka.sloupec") a hashovací tabulky jsou indexy. LDAP a jeho rodič X.500 na tomhle přímo stojí. XML jakožto strom využívá.
KWCMS má na tohle zajímavý přístup - je vidět u uživatelů a i je tam hlubinně popsán. Cesta s oddělovačem na konci je složka, soubor různých klíčů (včetně dalších složek). Oddělovač na začátku hlásí, že je "od kořene". Vtipné je, když se to slepí - pak to totiž udělá nepřerušenou cestu. S tím byly podle mého názoru stavěny první Unixy. Mountpoint je jen soubor odkazující na cíl na jiném stroji, kde se začíná jeho "kořenem".
Programování bez programů - verze pro neznalé
Před 150 lety zemřel matematik, který navrhl parní počítač
Příchod hackerů: na počátku byla Ada
Jako co si představit programy? A jako co si představit programování? ČT nastolila ve videu o Adě otázku, jak vysvětlit programátorské principy, když někdo absolutně nemá tucha, o co vlastně jde. Mě stačilo najít analogii. A tou jsou nepřekvapivě cesty. Protože stroje jsou nejlepší pro opakující se rutinní činnosti, která by lidskou hlavu zničila. A pak jde jen o to, že program je popis kroků vedoucích k výsledku. Jako co si tedy představit programy? Jako cesty k nějakému zamýšleným cílům. A jako co si představit programování? Jako stavbu těchto cest. Fór je, že tohle uvažování má vždy nějaký konečný stav. Na cestě se můžou nacházet 2 věci - zpracovávající závody (instrukce, funkce) a formané se zbožím (data). To máme doly (vstupy), mlýny (sčítačky), továrny (násobičky), křižovatky (skoky a podmínky) a města (výstupy). Každá továrna pak má sama o sobě nějaké vstupy a výstupy a vnitřní procesy na zpracování. Takže je to variace na matematickou funkci. Dá se to abstrahovat ještě víc, ale to zavání nepřehledností. Avšak když hrajete simulátory jako jsou Factorio nebo OpenTTD, tak vlastně taky programujete. Skládáte jednotlivé kostičky a z nich pak tvoříte větší celky. O ničem dalším pak skutečné programování není.
Úrovně programátorů
Na setkání Posobota jsme narazili na téma úrovně programátorů. Tak jak je to podle mne:
- Zelenáč - Trápí se se syntaxí jazyka
- Junior - Sytaxi zvládá, má problém s principy, neviděl moc kódu
- Medior - Zvládá principy, má chlív v knihovnách, potkal různý kód, zažil i nějaké průsery, zvládá spíš základní rozkládání aplikace
- Senior - Umí s knihovnami, potkal hodně kódu, zažil hromadu průserů včetně těch drahých, umí navrhnout správné rozložení aplikace do celku
- Architekt - Umí navrhnout rozložení aplikace včetně komunikace s okolím a ví, co tam přijde, dokáže správným návrhem omezit škody nižších úrovní
Není to o titulech (i když ty zjednodušují některé kroky), je to fakt o zkušenostech.
Hate na cURL
cURL je knihovna. Na dotazy na další stroje. Chová se jako nijak nezatížený prohlížeč. Dostane od aplikace požadavek na stránku a získá pro ni odpověď ze serveru. Zatím OK. Nebo...
cURL neumí HTTP/2 a HTTP/3. S ní to neotestujete. K v2 asi ještě ohnout půjde, k v3 už ne - je tam změna protokolu dole. cURL jede na TCP, v3 je nad UDP.
cURL je v PHP implementováno jako externí součást. To znamená, že na serveru nemusí být. A dokonce i v jednom případě nebyla.
V PHP máte několik možností, jak se téhle knihovně vyhnout. Za prvé sockety. Ať už ve variantě dřevák socket_* nebo trochu výše pfsockopen() a file api. Pokud jste někdy dělali logovací systém, co posílá informace po UDP (třeba Graylog), tak tam je jedna možnost. Za druhé volání file_get_contents() a případně wrappery pro něj. V prvním případě skládáte dotaz podobně jako cURL, v druhém dáváte už jen potřebné části s tím, že parametry směrem na server putují v poli $context. Krep proxy využívá právě tuhle cestu.
cURL má ještě jednu vadu a to, že je to základní varianta pro knihovnu Guzzle, která je braná jako standard pro dotazování na vzdálené stroje. Přitom, jak je tu vidět, není potřeba. Navíc mám vedle RemoteRequest, který dělá rozhraní právě nad sockety a v kombinaci s lepidlem RemoteRequestPsr je schopen Guzzle nahradit.
Asynchroní provádění dotazů není problém cURL nebo jiných variant a v téhle úrovni ho stejně nevyřešíte, protože php je z principu synchroní a čeká na výsledek volání.