Klávesové zkratky na tomto webu - rozšířené Na obsah stránky

TypeScript a typový sebeklam

|

Tak, jak je to v historii už zvykem, světová scéna opět konverguje k řešení, které je nešťastné. Ať už je to nepochopitelný vzestup Pythonu, kvůli Data Science, na který je objektivně nevhodným jazykem, nebo TypeScript na poli web developmentu. Programátoři podléhají módním trendům více než vědě a inženýrskému přístupu.

Lidí bez patřičných znalostí Computer Science a praktických zkušeností je moře, které neustále zvedá svou hladinu. Většina podléhá efektu stáda a rozhoduje se na základě marketingových masáží výrobců špatných IDE a jazyků a drahých konzultačních služeb. V davu přetrvává přesvědčení, že silné statické typy zlepšují návrh a zaručují funkčnost. Ve skutečnosti návrh neskutečně komplikují a to co dokáží, je eliminovat chyby na úrovni překlepů. Realita je taková, že tyto jazyky a frameworky jsou navržené tak, aby generovaly práci lidem zvaným XY Developer Evangelist a Enterprise XY Consultant, kteří jsou generátory nemalých zisků těchto výrobců.

Nástroje typu TypeScript slibují statickou analýzu a typovou bezpečnost v silně dynamickém světě. Tam, kde je agilita a dynamičnost vaší konkurenční výhodou, si dobrovolně lámete ruce pomocí enterprise návrhových vzorů, zavíráte dveře jednoduchému návrhu, kvůli schopnosti odhalit pár překlepů. TypeScript vám nepomůže se správným/lepším návrhem architektury, který má 100× větší dopad na vaši produktivitu a výslednou efektivitu. Místo toho vám dodává pocit falešného bezpečí. Ano, falešného, protože TypeScript nemá vliv na runtime, kde stále existují coercions a dynamičnost, kde vám (nejen) po drátě přijde úplně něco jinýho, než říkají vaše typy. TypeScript vás dokonce nenechá přeložit naprosto korektní program, který neodpovídá jeho omezené schopnosti popsat skutečné typy.

Lidi raději věří lži než aby žili v nejistotě…

Související studijní materiál

Typové systémy v dynamických jazycích

Efektivní programování s dynamickými jazyky

Generování Twitter Card obrázků

|

Sociální média umožňují (v rámci boje o uživatelovu pozornost) postovat bohaté příspěvky. V případě Twitteru jde o tzv. Twitter Cards, které umožňují nahradit odkaz požadovanými metadaty. Mezi ně patří název, popisek a obrázek. Můžete si dokonce vybrat, jestli chcete čtvercovou ikonu nebo pořádnej 2:1 billboard. No a protože jsem attention hore, rozhodl jsem se pro ten větší formát…

Jenže se mi nechce lozit po fotobankách a hledat nějakou bechderoucí fotečku, která s mými tématy bude asi těžko souviset. Takže jsem musel vymyslet něco jinýho. Docela se mi líbí, jak na feedu vypadaj vložený prezentace ze Speakerdecku. A protože se mi vyloženě líbí, jak vypadaj moje prezentace, tak jsem se rozhodl, že to obšlehnu. Aby se na první pohled dalo poznat, že nejde o prezentaci, ale o blog, rozhodl jsem se pro jinou barvu pozadí. Ale bílá futura zůstává. :)

Tak, nápad by byl, teď už jen jak ho realizovat?

Nejprve jsem si říkal, že bych mohl udělat šablonu ve Figmě a přes jejich API generovat obrázky. Jenže se mi nechce (zatím) učit se jejich API a zavádět vzdálená volání do generátoru, když jsem se jim tak šikovně vyhnul u obsahu. Ok, tak zkusím generovat obrázky pomocí Clojure. To se mi zase nechce low level komponovat bitmapa a navíc, jak dostanu Futuru na integrační server? Přes SVGčko? Sakra…

No, jsem přece web developer. Fonty dostanu přes Typekit Adobe Fonts, stejně jako na webu. Vytvořím tedy kompozici v HTML a obrázky budu típat pomocí Puppeteera! Doplnil jsem do generátoru webu, aby připravil JSON s daty, které budu potřebovat pro generování obrázků. Pak jsem napsal script, kterej otevře stránku a ve smyčce, projde data z JSONu, vloží je do DOMu a udělá screenshot. Není to úplně nejrychlejší řešení, ale 30 s na cca 470 článků není taky úplně nejhorší čas.

Nový život pro rarouš.weblog

|

Kdysi dávno (už to bude 15let) jsem vytvořil blogovadlo postavený nad ASP.NET a s tím jsem začal i blogovat. Původně se blog (po vzoru Mraveniště a Sovy v síti) jmenoval Liščí nora. Což moc dlouho nevydrželo a za nějakou dobu se ustálil název rarouš.weblog.

Blogovadlo fungovalo celkem dlouho, ale časem jsem ztratil přístup k serveru, na kterém běželo a postupně stránky začínaly uhnívat. Po tom, co se mi podařilo získat dumpy databáze a kompletního obsahu ze serveru, jsem vytvořil svůj první Clojure program, který vzal XML dump z MSSQL a vygeneroval z něj EDN s články. Následoval můj první Clojure web, který z toho EDN on demand generoval stránky. Výhoda byla, že jsem byl schopný zachovat původní URL – vč. fallbacků do historie. Hostoval jsme to na Heroku a pak jsem to přesunul do Docker Cloudu.

Problém ale byl s psaním nových článků. Publikování nového článku spočívalo v ruční editaci XML dumpu, kam jsem musel vložit článek v Texy formátu a zároveň i HTML verzi, kterou jsem získal na http://texy.info/try. To všechno jsem musel XML encodovat. Zkrátka s tím bylo sraní a přestalo mě to bavit. Tak jsem skoro přestal psát. Občas jsem něco vypustil přímo z Quipu, kde píšu většinu všeho.

Během loňského jara jsem začal psát nový generátor, který vzal původní dump a vygeneroval z něj soubory pro každý článek zvlášť i s jejich metadaty. Výstupem je Texy soubor s hlavičkou, ve které je EDN. Protože nesnáším YAML. A protože jsem měl 450+ článků napsaných v Texy.

V létě jsem přestal používat Facebook, zavřel LinkedIn a vracím se ke starým návykům, používat Feedly a Pocket. Vypnout informační šum a naladit se na kvalitu ručního výběru.

Fast forward do konce loňského roku, kdy jsem začal psát generátor webu. První problém byl, jak přetavit Texy do HTML? Původní myšlenka byla, že vytvořím AWS lambdu, kde poběží Texy a bude mi vracet HTML na základě mých požadavků. No, není to moc schůdná cesta, protože není úplně jednoduché dostat do lambdy PHP extenze. Druhá myšlenka byla, místo lambdy využít Fargate a mít to v kontejneru.

Vzdálená volání jsou ale drahá. Nejen na čas, ale v případě Fargate i na peníze. Takže jsem skončil u volání Texy scriptu přes shell. Navíc volat Texy pro každý článek zvlášť neslo taky slušný overhead. Nakonec jsem to vyřešil jedním batch-callem, kterej zprocesuje všechny články najednou. Rázem jsem se dostal z desítek minut na desítky sekund. Nakonec jsem musel připravit Docker image pro běh v CircleCI, který podporuje jak Clojure Tools Deps, tak PHP.

A už to lítá.

Nový backend

Základem je Pulumi program, který připraví infrastrukturu. Zatím tam je jen S3 bucket a patřičná Policy, ale až dodělají podporu Cloudflare, bude se správa CDN a DNS provádět tudy. Druhá část, jak už jsme naznačil, je Circle CI, které spustí script generátoru a v dalším kroku provede Gulpové transformace nad assety. V posledním kroku se udělá sync do S3 a je to venku.

Screenshot: Delivery pipeline

Upravený frontend

Moc věcí se nezměnilo, hlavně jsem obměnil typografii. Na další věci se dostane postupně. Co se změnilo zásadně, je struktura adres a stránek blogu. Přešel jsem na hierarchický model rok/měsíc/den/slug. Když si odmažete jednotlivé segmenty najdete tam indexy pro vybrané časové období. Taky jsme přešel z nesmyslných kategorií na štítky. Ačkoliv jsem se dříve snažil štítkovat, tak v tom moc žádný systém nebyl. Proto jsem značnou část článků prošel a přeštítkoval. Vznikly tak nové rubriky, tématicky doufám vytříbenější, které najdete dole v patičce. Ta se asi brzo taky dočká značné aktualizace. :)

Spousta věcí je spíchnutá narychlo, vím o spoustě drobných vad, ale psaní a čtení nejsou na překážku.

Oprašte své RSS čtečky, je čas se vrátit ke kořenům!

Návštěva v CZ Podcastu po pěti letech

|

Jednoho lednového odpoledne mi Filemon povídá, že jde s Dagim točit CZ Podcast a že nemaj hosta. Jestli nechci povědět něco o Pull Requestech. A já si řekl: „proč ne?“ Tak jsem se po pěti letech vrátil k jejich mikrofonu a výsledek si můžete poslechnout tady:

Jak jsme dali práci robotům

|

Jednou ze zajímavostí IT je, že se snaží automatizovat rutinní práci lidí a dávat jim více možností soustředit se na činnosti s větší hodnotou. Nebo jim práci brát. :-/ Když se nad tím člověk zamyslí, je celkem paradoxní, jak málo tohle IT lidi dělají sami sobě. Často se topí v rutinní práci a ještě se předhánějí v tom, kdo jí dělá víc nebo hůř… :)

Poslední dobou jsem sledoval, jak nám – s rostoucím počtem projektů, na kterých děláme – rostou náklady na údržbu. A tak jsem hledal řešení, jak ten maintenance overhead snížit. Aniž bychom kvůli tomu museli nabírat více lidí nebo přetěžovat lidi, co už máme. A jako řešení se ukázali roboti!

Screenshot nastavení Github Security Checku

Začalo to jednoduchým zaškrtnutím checkboxu v nastavení repository na Githubu. “Ano, kontrolujte mi prosím závislosti, jestli nemají známé bezpečnostní díry.” A jejda, najednou se ukázalo, že některé projekty, které byly několik měsíců bez údržby (zdánlivě ji nepotřebovaly), mají bezpečnostní díry. To nám, ale ve skutečnosti náklady na maintenance ještě zvýšilo, lidi museli začít řešit problémy, které byly u ledu…

Screenshot Pull Requestu od Dependabota

Tak jsem začal hledat řešení, které by nám mohlo pomoci a našel jsem Dependabota. Dependabot je robot, kterého si pozvete do projektu a on vám pomáhá s údržbou závislostí. Začali jsme s lehkou nedůvěrou, co to s našimi službami udělá. Nechali jsme každé ráno Dependabota dělat pull requesty s aktualizacemi jednotlivých závislostí.

filters:
  branches:
    only: master

Museli jsme upravit build scripty, aby nám PR neprotekly na dev prostředí, ale aby se jen provedly všechny testy, které v pipelině máme. Naštěstí Travis CI i CircleCI mají koncept filtrů na branche, takže to byl de-facto three-liner. A pak už každé ráno chodily pull requesty. Občas některé testy neprošly. Občas se některé aplikace rozbily, i když testy prošly. Takže jsme museli zlepšit naše integrační testy.

Z počáteční záplavy (Dependabot má „sane default“ na max 5 PR za den) pull requestů se stalo občasné rutinní schvalování. Vzhledem k tomu, že několik měsíců už jsou jeho kontribuce spolehlivé, nemá cenu jej v práci blokovat. Dependabota jsem přepnul do módu Live Update a automatický merge PR, pokud všechno vypadá ok. A o rutinní práci se nemusím starat. Malou krátkodobou investicí do robustnější test suite jsem se zbavil rutinní práce a můžu se věnovat té opravdu užitečné.