CategoryJavaScript

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…

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 🙂

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

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

NodeJS: Threads, práce s vlákny

NodeJS je báječný, a to hlavně díky svému Async I/O. Dalším silným znakem je to, že NodeJS je Single Threaded Event Loop Architecture. Jednoduché, čitelné a výkoné paradigma pro webové aplikace stavějící na Request/Response modelu.

Na základě tětchto principů se NodeJS moc nehodi na takové věci, jako je Machine Learning, nebo Artificial Intelligence, jinými slovy, úlohy závislé na silné paralelizaci. Byť vzhledem k tom, že je samotný javascriptový engine napsaný v C++ a nabízí tak dost vysoký výkon.

Tedy až do teď! 🙂

Od verze 10.5.0 umí NodeJS pracovat s vlákny! Což z něj dělá prostředí vhodné i pro věci kolem strojového učení a umělé inteligence. Funkcionalitu vláken přináší modul worker_threads.

Modul je dostupný od verze 10.5.0 a jen v při spuštění s paramatrem
--experimental-worker, protože se zatím jedná o novinku.

Příklad spuštění javascriptového kódu v několika, v tomto případě ve 2 vláknech.

Z příkladu je jasné, že v procesu potomka můžete spouštět jakýkoliv javascriptový kód, sdílet s rodičovským procesem proměnné (paměť) a také posílat si navzájem zprávy. Vše, co byste po vícevláknových aplikací požadovali.

Dokumentace modulu worker_threads.

Kvalita dokumentace…

Nádherná ukázka toho, jak i rádoby dokumentace může být špatná…

Screenshot jsem pořídil ze stránek w3schools.com 🙂 Vím, že tohle není oficiální dokumentace, ale znám spoustu lidí, co odtud čerpají a berou informace odsud za ty jedině správné…

23 javascriptových návrhových vzorů

Proč návrhové vzory?

Abyste nemuseli vynalézat kolo.
Aby to co napíšte mělo hlavu a patu a rozuměli tomu i ostatní.

Pěkný článek popisující javascriptové návrhové vzory. Jednoduše a pochopitelně.

this v arrow functions

Tohle jsem viděl nesčetněkrát. Tohle vám skutečně fungovat nebude 🙂

Arrow functions jsou super, ale je dobré vědět jak fungují… Respektive vědět minimálné to, že nemají this, mino jiné, a proto se neprovede this.num++ nad num definovaném v objektu a, jak by se na první pohled mohlo zdát. this ukazuje na parent, tedy v tomto případě global, kde žádný num není 🙂

Správně tedy

Pěkný článek popisující detailně chování this kdekoliv v JS.

ES moduly v NodeJS

Modularita, co by nezbytná vlastnost jakéhokoliv programovacího jazyka pro psaní velkých aplikací, je v NodeJS zajištěna pomocí funkce require. Samotnou fyzcickou definici a implementaci pak zajišťuje CommonJS.

Takže takto v NodeJS

JavaScript a import

JavaScript, skrze svou specifikaci ECMAScript 2015 zavádí, mimo jiné, i nové klíčové slova import a export pro možnost modularizovat javasxriptový kód.
To dovoluje následující zápis kódu:

Tohle vám bude například fungovat, pokud píšete React, VueJS, nebo Typescript aplikaci, protože ta je teprve skrze nějaký transpiler kompilována do požadované verze JavaScriptu.

Nicméně v NodeJS import nefunguje… Zatím 🙂

node –experimental-modules

A tady přichází na scénu parametr příkazového řádku --experimental-modules, který vám umožní v NodeJS používat klíčové slovo import místo require. Přesně tak, jak byste jej použili v Reactí apce…
Opravdu píšu místo, protože obě možnosti zatím nejdou kombinovat.
Takže pokud spustíte NodeJS script s tímto parametrem, můžete použít novou syntaxi pro importování, ale samozřejmě i exportování na úrovni modulu:

Dalším rozdílem je samotná přípona souboru se zdrojákem. Původní require funguje v klasických .js souborech, nově import pak v souborech s příponou .mjs.
Samozřejmě můžete import přímo psát do.js souboru a spouštět pokaždé s potřebným parametren, ale je to proti zavedené konvenci a navíc, nejde na první pohlef vidět jaký způsob práce s moduly jste použili.

Moje doporučení?

Pište v TypeScriptu 🙂 budete moct v .ts souborech použít obě konstrukce pro import, ale vedle toho mnohem víc věcí, které JavaScript dělají skutečně silným programovacím jazykem.

NodeJS: MongoDB callback VS async/await

Odjakživa co píšu v NodeJS se držím callbackového zápisu asynchronních funkcí. Callback-hellu se snažím vyhnout rozumnou dekompozicí řešené úlohy a Promises zápis mě nikdy nedostal… Nicméně s jazykovou konstrukcí async/await, která se do JavaScriptu dostala ve verzi ES2017, se dá leckdy kód napsat čitelněji, pochopitelněji a tím pádem snad i bezpečněji.

Takhle by tedy mohl vypadat kód pro čtení dat z MongoDB:

Původní callback implementace

Nová async/await implementace

Resumé

Na první pohled jde vidět několik věcí: ošetření všech chyb se přesouvá jen do jednoho místa a tím odpadá mnoho opakujícího se kódu, výsledek, načtená data nejsou nikde hluboce zanořená a nemusíte řešit problém s kaskádou otevřených závorek if-else větví.
Nutno podotknout, že výhoda nového zápisu ještě více vzroste v momentě, kdy máte sérii callback dotazů a obslužný kód vám začne ještě více narůstat.

Vedle toho si samozřejmě dokáži představit kód, kde bych se dál držel callback zápisu, ale to je věc konkrétního použití.

TypeScript: unit testy s Jest

Jest je, jak píše Facebook co by jeho tvůrce, skvělý JavaScriptový testovací framework. Jedná se o přímou náhradu, či konkurenci jinému, v současné době asi rozšířenějšímu, testovacímu frameworku, kterým je Mocha.

Proč Jest?

  • méně nutné konfigurace pro okamžité použití
  • velice jednoduché vše rozjet a okamžitě začít pokrývat zdroják testmi
  • na rozdíl od Mocha obsahuje i assert knihovnu (Chai) a mock knihovnu (SinonJS)
  • performance

Nicméně žádný z těchto důvodů nebrání použítí Mocha frameworku pro váš kokrétní projekt, či tým.

Jak na to?

Instalace

Předpokádám, že už máte nějaký NodeJS projekt a v něm package.json. Pak stačí jen doinstalovat pár balíčků nasledujícím způsobem:

Hotovo 🙂

Konfigurace

Do pakcage.json vložit konfiguraci pro Jest a následně upravit sekci script:test pro spuštění testů:

Samotná konfigurace Jestu může být alternativně uložena mimo package.json přímo do jest.config.js:

Vytvořte adresář __tests__ v root adresáři vašeho projektu. Adresář s testy se může samozřejmě pojmenovat jakkoliv jinak, stačí korektně přenastavit v konfiguraci.

Hotovo 🙂

Kódování, develop, vývoj…

Založte si src adresář a v něm vytvořte svůj nějaký soubor, který bude obsahovat váš TypeScript kód. Řekněme sum.ts, pro nějaké matematické funkce…

Hotovo. Máme knihovnu, která v tuto chvíli exportuje jednu jedinou funkcionalitu pro sčítání 2 čísel.

Konečně testování

V dříve založeném adresáři __tests__ vytvořte stejně jmenující se typescriptový soubor který bude obsahovat samotné testy, tentokrát s příponou .test.ts:

Hotovo 🙂 Můžeme testovat:

Výstupem je krom informace s výsledky testů i informace o tom, jak máte svůj zdroják testy pokrytý:

TDD

V rámci TDD si pak dokážu představit, že pro každou nově vyvíjenou funkcionalitu si nejdřív napíšete její testovací sekci, ve které pokryjete všechny scénáře, kterou mahou nastat a pak teprve začnete vyvíjet a píšete tak dlouho, dokud všechny zadefinované testy nejsou zelené 🙂

Zdroje

Jest homepage, dokumentace, blog

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑