CategoryProgramování

For loop v TS, JS (performance)

V ES6 je nově for of loop, který iteruje nad čímkoliv, co umí iterovat, jako je např. pole a objekt.
A to mě vedlo ke krátkému a opravdu jednoduchému testu, ve kterém jsem si ověřil výkonost jedotlivých for loop konstrukcí.

Výsledky

Env NodeJS Safari Chrome Firefox
Create time 497 209 507 2793
For in 1421 7606 1534 6575
For of 11 36 31 10643
For 11 46 34 8724

Všechny časy jsou v ms.

Několik rychlých závěrů

  • Firefox už dlouho nepoužívám a do testu jsem jej vložil jen pro úplnost. Pozitivní zjištění: o nic jsem nepřišel…
  • Je super, jak je NodeJS opravdu dobře zoptimalizovaný a na prováděný kód téměř nemá žádný vliv prostředí.
  • Chrome: V8 společná s NodeJS je znát. Výkonový rozdíl vyplývá z prostředí ve kterém kód běží a dá se pochopit.
  • Safari má vlastní JS engine SquirrelFish, který je opravdu dobrý…

Poznámka na závěr

Ze zvědavosti jsem chtěl takto otestovat i PHP.

Při pokusu vytvořit pole s 10.000.000 čísly (tak jak jsem to dělal v JS) jsem se dočkal chybové hlášky Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 134217736 bytes) in /Users/pepa/test/looptest/test.php on line 7 a tím jsem testování v PHP odpískal.

Pravdou je, že jsem ještě zkusil zmenšít velikost vytvářeného pole na 10.000, tedy tisíckrát meněí. Jo! Pole se vytvořit podařilo. Pak jsem se zarazil. Tohle chceš vážně testovat?

ts-check: na cestě od JavaScriptu k TypeScriptu

Pokud svůj javascriptový kód obohatíte o JSDoc minimálně na úrovni dokumnetace funkcí, pak pomocí direktivy // @ts-check získáte typovou kontrolu, kterou nabízí například TypeScript. Jasně, že na tak kompletní, ale jakýsi posun k typovosti tu je.

Pokud pak jeětě použijete /** @type {number} */ nad řádkem s deklarací proměnné, získáte i statické typování na úrovni jendotlivých proměnných.

Nutno dodat, že tohle funguje jen v MS Visual Code editoru… Ale kdo dnes pro kódování v JS, nebo TS používá něco jiného 🙂
Direktiva ts-check musí být na začátku JS souboru.

Při volání funkce pak editor korektně podtrhne nevalidní parametr, který je jiného typu, než bylo specifikováno v JSDoc komentáři.

Editor pak i proměnou okomentovanou specifikací typu pak korektně označí chybou v místech, kde se snažíte přiřadit nekorektní hodnotu.

SocketIO v NodeJS (předpověď počasí)

Našel jsem moc hezký článek jednoduše popisující SocketIO. Takže jestli hledáte technologické řešení, jak komunikovat s návštevníkem vaší www stránky v reálném čase, pak věřte, že to už nejde jednodušeji…

MS Visual Code klávesové zkratky

Zkrakta Vyznam
⇧⌘V Nahled MD souboru
⌘K V MD view the preview side-by-side

Microsoft Visual Studio Code

Alternativně jsem vedle Atomu začal používat Microsoft Visual Studio Code.

Několika prvních postřehů:

  1. Editor je pěkně rýchlý…
  2. Jeho konfigurační možnosti vypadají srovnatelně s Atomem…
  3. Existují stejné pluginy, které používám v Atomu, ale s různými klávesovými zkratkami. Dá se přenastavit a editor pro key-binding je povedený, přehledný…

Jediný problém, na který jsem narazil, nicméně jej hned odstranil bylo, že jsem nemohl v iTermu pohodlně spouštět Code přimo s obsahem daného aktuálního adresáře.
Řešením je přidání následující funkce do .bash_profile a pak už spustíte MSVS Code odkudkoliv jednoduše zadáním příkazu code

NodeJS: NODE_ENV dev || production

Taková ta uplná klasika: vyvíjíte aplikaci na svém stroji, kde máte samozřejmě úplně jinou konfiguraci, než na produkčním serveru, respektive také odlišnou od konfigurace kolegy, který se snaží psát pod Windejsi.
Tou jinou konfigirací může být cokoliv. Od propojení na externí služby až po způsob logování toho co a jak chcete vidět. Jasně že na developu vás zajíma víc věcí, které chcete na produkci vidět až když řešíte nějaký problém…

A řeči o tom, že byste měli kontejnerovat, dokrovat a tak vás taky nebaví. Nevidím jediný důvod, proč bych měl na svém lokále sestavovat nějaký dokr a pak spouštět virtuální stroj… WTF! Jediné co chci je spustit apku na mém mekovi prostě jinak nakonfigurovanou, ale funkčně pokud možná co nejvíc identickou s produkčním prostředím…

Dřív jsem rozdílnou konfiguraci do aplikace zaváděl skrze parametr příkazové řadky. Vstupní JS modul aplikace rozparsoval parametry příkazové řádky. Pokud našel parametr udávající soubor s konfigurací, pak se jej pokusil naimportovat. Pokud nic takové, pak natáhnul nějakou defaultní konfiguraci… Super. Funguje skvěle a umožnuje opravdu dobře nakonfigurovat kde co a to pokaždé úplně jinak. Prostě jak je libo…

Jenže jsem línější a línější a i tohle mi připadalo jako opruz. Je to přece jen nějaký kód navíc.. Já vím, že ne moc, ale je… Stačilo mi prostě něco lehčího.

NODE_ENV

A tak jsem se vrátil k NODE_ENV. Ne že bych o ní nevěděl, ale protože jsem vytvářel přece jen složitější struktury, mírně jsem podcenil možnosti této enviroment proměnné, a proto jí nějak moc rychle přeskočil. Chyba. NODE_ENV mi umožňuje dál lenošit a odpadl problém s konfigurací.

Jediné co jsem musel ořešit je jak NODE_ENV propašovat v různých způsobech spouštění, či využívání přímo do aplikace. Apku spouštím různě a nechtěl jsem se připravit o konfort kastomizovaných konfiguráků specifikovaných z příkazové řádky.

Základní implementace v package.json skrze sekci script:

Pokdud spouštíte apku z shellu, pak takto:

No a pokud potřebujete NODE_ENV sdílet s dalšími nástroji, jako je gulp, nebo cokoliv jiného, pak:

Samotný JS kód se pak k proměnné prostředí dostane odkudkoliv skrze globální promenou process, která obsahuje celý ENV, včetně toho co sami nějak nadefinujete:

Takže můj konfig dnes může vypadat i takto:

Samozřejmě se i tohle dá napsát jinak, dle libosti… 🙂

Nicméně tohle je obecný přístup, kterým se dá do vaší apky propašovat jakákoliv proměnná z prostředí operačního systému…

__main__ v NodeJS

Kdysi jsem tady popisoval jak v NodeJS připodobnit chování runtime při spouštění daného modulu. Něco, co se běžně v Pythonu dělá takto, ale v NodeJS se to moc nevidí:

Původně jsem v NodeJS tohle řešil následovně:

Další, možná o něco lépe vypadající řešení

Tahle podmínka mi prostě připadá logičtější 🙂

A k čemu je to dobré?

No třeba k samotnému testování… Jsem líný a někdy mi dělá problém dokopat se udělat nějaké testování nad modulem, kyterý je přece úplně jasnej: tady nemůže být žádná chyba…. A právě proto přímo dodaného modulu napíšu tuhle podmínku, která má nějakou sekci, která se provádí jen v případě, že modul spouštím přímo pod NodeJS a nerequiruji ho do nějakého dalšího, nadřazeného modulu.

Geolokalizace IP adresy

Z důvodů pořešení nějakých bezpečnostních praktik jsem potřeboval nějak blíže geolokalizovat IP přihlašovaného uživatele, respektive záškodníka, abych věděl odkud se fyzicky přihlašuje:

NodeJS: geolokalizace IP adresy

Python: geolokalizace IP adresy

Zvýšení limitu RAM pro NodeJS aplikaci

Defaultně dostane NodeJS script maximálně 1.76GB RAM na 64bitovém systému. Což je asi na jednovláknové aplikace dost, nicméně se vám může stát, tak jako mě, že potřebujete zaalokovat nějaké opravdu větší pole a byť máte stroj s 16GB RAM, Node vám vráti chybu při pokusu alokovat paměť.

Pak se vám bude hodit parametr příkazové řádky –max_old_space_size, který V8 říká kolik si má vzít RAMky a posune defaultní limit na vámi zadanou hodnotu:

Jaký je rozdíl mezi Javou a JavaScriptem?

Q: What’s the difference between JavaScript and Java?

A: One is essentially a toy, designed for writing small piecess of code, and traditionally used and abused by inexperienced programmers. The other is scripting language for browser.

🙂

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑