CategoryProgramování

sleep(), nebo wait() v NodeJS

Znáte to: čas od času byste rádi na něco počkali. A zrovna to čekání není moc v souladu s asynchronní povahou samotného NodeJS.

NodeJS, narozdíl od sleep v PHP, nebo time.sleep v Pythonu, žádnou takovou funkcionalitu, zaplať pán bůh, nemá.

Proč byste měli třeba čekat?
Modelová situace: někde na vaší API, nebo někde úplně mimo váš dosah, spustíte například nějakým POST requestem proces, který nevíte kdy skončí, nebo jak dlouho bude trvat. Takže vám nezbude nic jiného, než se stále dokola ptát na nějakém endpointu, jestli už proces nedoběhl a API má pro vás data. No a abyste APInu nezahltily tunou nic neřešících requestů a nedostali se tak třeba na nějaký black list, je dobré mezi odesláním každého requestu nějakou dobu počkat a opakovaně se ptát až po nějakém rozumném časovém intervalu.

Třeba takto

Srdcem tohoto jednoduchého konceptu je jen využití Promise a díky syntax sugaru async/await, to pak celé vypadá takto imperativně, pochopitelně, pro každého péhápkáře 😀

Kód je tak dlouhý, protože v něm demonstruju krom samotnéo sleep() i vše kolem…

Go Lang: Scheduling

Skvělý dvoudílná miniseriál a schedulingu v Go.
Pokud to myslíte s Go vážne, pak by vás tohle nemělo minout.

1. díl
2. díl

JavaScript: funkcionální map trochu jinak

Jsem si jistý, že všichni znají metodu map.

Jedná se o funkcionální přístup, který nahrazuji tento imperativní přístup:

A tohle je map

Věřím, že všem známý a na první pohled jasný příklad funkcionálního programování, kdy ani tak neříkám jak, ale co se má udělat.

A teď trochu jinak

Tak předně jsem přesvědčen o tom, že tento funkcionální přístup je pro tyto druhy výpočtu, nebo něčeho takového, asi lepším zápisem. Ale také se uvědomuji, že i spousta těch, co třeba už dnes po té co se od klasického PHP for loopu dostali až sem, neví přesně co vidí, respektive co používají.

Výše zmíněný kód s funkcí map se dá napsat i takto:

Furt to dělá to stejné, že? 🙂
Ale zápis už je jiný. Vlastně není. 🙂

Věděli jste, že parametrem metody map je funkce? Jo jo, je mi to jasné. všichni kýváte, že samozřejmě ano…
Dyť přece funkcionální programování, vole….

Proč o tom vůbec píšu?

Jedním z důvodů je, že pokud si tento drobný, samozřejmý detail uvědomíte, pak můžete psát třeba i takto:

Líbí?

Pokud ano, pak máte nakročeno nejenom k tomu, že skutečně pochopíte funkcionální programování, ale že jednou budete schopni skutečně psát i větší aplikace a nezaseknete se, jako většina ve stádiu hele kámo, já umím procházet polem. 🙂

Takže ještě jednou: Proč?

Jak se chcete dostat k takovým věcem, jeko je modularizace kódu, jeho dekompozice, nebo možná třeba jen refaktoring, když neuvidíte věci jak je máte vidět?

Myslím si, že pokud se naučíte hledat drobnosti a budete skutečně vidět detaily, může se z vás jednou skutečně stát dobrý programátor 🙂

Je GO lang opravdu tak rychlý?

Před nějakou dobou jsem měřil rychlost JavaScriptových enginů v růyných prohlížečích a NodeJS. Více zde.

Vedlo toho jsem se letos začal věnovat více i Go, a proto jsem rychle přepsal základní test for loop smyčky do goučka a cvičně to otestoval…

Testovaný kód

A výsledek je zde:

Vedle toho jsem cičně znovu spustil původní test v TypeScriptu a dostal jsem následující výsledek:

První závěr

Go skutečně rychlejší je. Nicméně ne o tolik, kolik bych čekal, když slyším všechny o Go básnit. Což je dobrá zprává pro všechny příznivce JavaScriptu, či TypeScriptu.
Tím samozřejmě nesnižuji Go. Libí se mi.

Vedle toho je mi jasné, že moje tesováné je hodně zjednodušené 🙂
Na druhou stranu aspoň nějaké testování… Vůbec v době, kdy je internet plný samých důveryhodných informací.

Vedle toho

Vytvořil jsem z Go zdrojáku i binárku pro svého Meka a otestoval i tu:

Opakovaně jsem spouštěl test jak v interpreteru, tak jako binárku.

Pak jsem otestoval i na VPSku s Centos 7 a dostal se následujícím výsledkům:

Hola!

Zajímavým zjištěním je že můj zkompilovaný test není rychlejší než kód běžící v interpretu. Potvrzeno i na jiném stroji.

Opět připomínám: měřil jsem velice jednoduchou funkcionalitu, ale v každém případě je to minimálně zajímavé zjištěmí, o kterém jsem přesvědčen, že mnoho z těch, co diskutují do aleluja, vůbec neudělali…

Proč

Mimo jiné jsem chtěl poukázat na fakt, že je leckdy docela jednoduché a asi nejpřímočarejší si napsat své vlastní testy na vybrané aspekty, na kterých vám záleží. A těmi nemusí být vždy jen samotná rychlost, ale například i memory usage, nebo propustnost, či cokoliv jiného.

NodeJS: neodchycené výjimky

Premisa 1: JavaScript, potažmo TypeScript, je komplexní, mocný programovací jazyk. Krom všeho možného 🙂
Premisa 2: všichni děláme chyby…

Je dobré o chybách vědět.
A to je cílem tohoto kódu:

Tento krátký kód se postará o obsluhu všech neodchycených výjimek kdekoliv v aplikaci. A proto je dobré jej umístit někam do míst startu aplikace, aby vše, co je španě, někde nepropadlo. V samotné funkci obsluhy výjimky pak může být cokoliv co vám dává smysl: výstup do konsole, notifikace někam přes sít, či cokoliv jiného co vám dává smysl.

Více zde.

Objektové programování vs funkcionální programování

Nemám tyhle debaty o programování rád, ale čas od času jsem do nich i já nějakým způsobem zavlečen a musím se v nich, respektive k nim vyjadřít.

Takže předně

Každé programovací paradigma má své nějaké základní parametry, vlastnosti, respektive přímo důvody vzniku, které jej více či méně kvalifikuje pro řešení daného problému. Tohle je si potřeba uvědomit hned a postupovat podle toho. Z toho může po povrchní úvaze, bez hlubších teoretických znalostí vyplynout, že v podstatě vše jde napsat v čemkoliv. Což může být určitě taky pravda…

Na druhou stranu není dobré se dostat do extrému, kdy na základě výše popsané situace s univerzálnosti a všestranností porgramovacích jazyků, dojdete k názoru, že pak je vlastně jedno v čem píšete, a proto vše co píšete, nebo budete psát, budete psát striktně dle jednoho jediného paradigmatu.

Do této pasti se obvykle dostávají buď juniorští programátoři, v lepším případě dobře teoreticky připraveni, ale bez praktických zkušeností, které by jim pomohly identifikovat potřebné signály, které by je vedli k adekvátnějším závěrům, nebo naopak rádoby seniorní programátoři, kteří na nějakou teorii, kterou možná kdysi znali už zapomněli, a vidí jen to svoje.

Co z toho vyplývá?

Vedle každodenního psaní kódu je potřeba se stále vzdělávat. Znát věci nejen prakticky, ale vědět proč a jak fungují. Vědět, co stojí za jejich fungováním. A čím hlouběji půjdete, tím lépe. V dlouhodobém měřítku na tom rozhodně vyděláte.

A tady se dostávám k jednomu z programátorských doporučení: kterýkoliv programátor by se měl každý rok pokusit naučit nějaký nový programovací jazyk. Studiem nového jazyka si osvojujete nová paradigmata, která rozšiřují váši teoretickou znalost. Vedle toho vám tyto nově nabité poznatky dovolí podívat se na každodenně řešené úkoly novým úhlem pohledu a umožní vám úkol řešit novým způsobem, nebo i novým paradigmatem. Možná i novým programovacím jazykem… 🙂

A kde začít?

Našel jsem velice pěkný článek, který se dá použít jako materiál pro vlastní argumenty k těmto diskusím…

Kam dál?

Funkcionální programování
Deklarativní programování
Imperativní programování
Strojový kód
Referenční transparentnost
Strukturované programování
Objektově orientované programování
Multiparadigmatický programovací jazyk

Tenhle ví o programování skutečně všechno…

TypeScript: async funkce s interface

A takhle by mohla vypadat vaše async funkce pracující se složitějšími datovými strukturami realizovanými pomocí interfaces:

Async/await nebo callback? Oboje!

Pokud chcete nabídnout svoji funkcionalitu skutečně širokému obecenstvu, pak byste je asi neměli nutit do vámi vybraného modele použití formou callbacku, nebo promises, ale nabídněte hned obě.

Nic složitého. Stačí nabídnout interface funkce, kde budete detekovat její parametry a podle nich, respektive volání s nimi, zjistíte jak daný konzument vaší funkcionality hodlá použít a podle toho vyberete implementaci samotné funkce:

Samozřejmě lze napsat i kompaktněji:

JavaScript: proměnná jako klíč v objektu

Pokud byste chtěli v objektu nějak dynamicky generovat název klíče, pak takto:

TypeScript: typovost skrze interface a její rozšíření

Jednou z hezkých věcí v TypeScriptu je možnost definovat vlastní datové typy a to hned dvěmi způsoby: skrze type, nebo pomocí interface.

Čas od času se může stát, že potřebujte vámi definovaný typ rozšířit o nějkou vlastnost a nechcete kvůli tomu vytvářet další, nový datový typ. Pak se vám bude hodit konstrukce využívající operátor &, která přesně tohle dělá.

Hezké je, že můžete takto spojovat více již nadefinovaných typů, a spojovat můžete i více než 2 typy, ale můžete rozšířit daný typ jen o konkrétní požadované nové položky.

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑