AuthorPepa

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…

Muzika mě táhne… chtěl bych umět třeba na trumpetu.

A nebojte se vydržet do 1:20. Stojí to za to.

Budoucnost organizací: něco málo o lídrech

Lídři musejí být ochotni zcela odevzdat svou moc skupině. Už nemohou ovládat nebo kamkoliv směrovat výsledek. Musejí naprosto důvěřovat, že skupina dokáže prostřednictvím společného vnímání přijít s lepšími odpovědmi, než jaké by vymysleli oni sami…

Jen málo lídru v dnešních organizací je na něco takového připraveno..

Strategie diktovaná shora prozatím zůstává tou výchozí a bezpečnou možností pro lídry, kteří si chtějí udržet kontrolu…

Výsledky výzkumů i zkušenosti z praxe opakovaně prokazují, že projekty změn diktované shora povětšinou selhávají…

— Frederic Laloux, Budoucnost organizací.

Vím, že tohle není o IT, ale je to pro mě a myslím si, že v dnešní době pro daleko více lidé aktuální téme.

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…

Co by každý programátor měl znát

Našel jsem velice hezký, ne až moc dlouhý, článek, popisujicí některé základní koncepty, návrhy v OS, o kterých si myslím, že by měl znát, nebo asponň měl mít minimální povědomí, každý, kdo se rozhodne profesionálně programovat.

Hloubka těchto znalostí a míra dalších, pak odděluje jednotlivé programátory na stupnici HEJA!…….OUPS!

A myslet si, že pokud píšeš v JavaScriptu, nebo nedej bože v PHP, tak se tě to netýká, tak to je opravdu omyl. Velký omyl!

Těch znalostí by mělo být samozřejmě daleko víc. Ne jen týkající se OS, ale dalších témat. Myslím si, že právě komplexnost, tedy rozsah znalostí a jejích hloubka každého kdo se snaží o dobrý kód posouvá na oné stupnici blíže k označení HEJA!.

Zároveň si uvědomuji, že ono posouvání je dlouhodobý a tvrdý proces. Musí tě to bavit 🙂

Proč tento článek?
Mám takový nějaký divný pocit, jako by všechny kolem zachvátil virus povrchnosti, který dává všem falešnou představu znalosti a neumožňuje jim opravdového prohlédnutí. A to se asi netýká jen IT. Je to asi obecnější jev. Lidi se díky tomuto viru nejsou schopni ponořit hlouběji, a proto nezažívají uau efekty, který je nutný na cestě od OUPS! k HEJA! A pokud budete dlouho OUPS!, pak asi těřko můžete být spokojený, natož šťastný.
HEJA! je to ještě o programování? Jasně že je! 🙂

Z shell

Vedle samotného vývoje se zabývám devops činnostmi, ke kterým patří různé práce na strojích v drtivé většině s OS Linux. Hodně času trávím v sehllu. Na většině serverech je výchozím shellem bash a mě až do nedávné doby nenapadlo nevyzkoušet žádný jiný shell. A že jich je….

Až do minulého týdne. Po velmi dlouhé době jsem se vrátil k zshellu. Podařilo se mi dotáhnout instalaci až do konce a jsem nadšený… Nejenže zshel vystřídal na mém mekovi stantdartní a defaultní bash, ale nainstaloval jsem si jej i na ostatní servery, na kterých provádím nějaký deploy.

Jednu z nejsilnějších stránek zshellu vidím super konfigurovatelnost promptu a jeho možnosti vizualizace. Prompt v zshellu vypadá opravdu skvěle. A nakonfigurovat jej je skutečně hračka.

zshell

Na první pohled vidím, že nejsme na svém stroji, ale na nějakém serveru, vidím kde jsem, ale co je největší přínios, hned vidím kde jsem v gitu, na jaké jsem branchi a jak si na něm vedu. Mám aktuální zdrojáky? Nejsem v nějaké změně dopředu? Integrace promptu s zsehllem je super!

Vedle toho jsem si dokonfiguroval pravou stranu promptu: odebral jsem všechny možné skopičiny a nahradil jej jen jednoduchou notifikací informace s návratovou hodnotou provedeného příkazu.

Další drobnost, ketrá potěší. Už žádné echo $?, ale jasně zobrazený výsledek i s exit statusem…

A těch drobností je mnohem. Víc.

zshell: instalace

1. instalace samotného zshellu

Pokud jste na mackovi stačí jen přes brew:

A pak už jen výměna defaultního bash za zshell:

2. instalace oh-my-zshell

Oh My Zsh je skvělá nadstavba pro zshel!

3. instalace themes pro oh-my-zshell

4. kustomizace promptu

Finální úprava konfigurace v ~/.zshrc

5. změna fontu v terminálu

Aby se všechny znaky korektně zobrazovaly, je potřeba si v terminálu nastavit font, který tyto znaky umí. Jedná se o fonty, které obsahují ve svém názvu slovo Powerline. Odkaz na fonty najdeš níže.

font

iTerm2 -> Preferences -> Profiles -> Text -> Font

6. doinstalovani pluginu

je pak jeětě potřeba do sekce plugins pridat zsh-autosuggestions a zsh-syntax-highlighting

Hotovo!

Může se hodit:
Powerlevel9k
Powerline fonts
Oh My Zsh

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑