CategoryProgramování

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.

🙂

Výpočet GEO vzdálenosti v JavaScriptu

Výpočet dle Haversine formula

ESLint

Dnes jsem přešel z JSHintu na ESLint. Tím asi nejpádnějším důvodem je podpora Reactu, respektive jeho JSX a lepší monžnosti konfigurovatelnosti. Musím ale dodat, že jsem se bránil do poslední chvíle. Důvodem byla třeba rychlost lintování: JSHint mi zdrojáky lintoval rychleji… A tohle je informace, kterou se nikde nedočtete.

Než jsem switchnul, pročetl jsem kde co, abych zjistil, že:

  • JSHint je fork původního JSLintu
  • ESLint je dnes už asi více používaný než JSHint, který je tady nicméně déle
  • velké a významné IT používají ESLint…

ESLint, stejně jako JSHint, fungují dobře jak v Atomu, tak i Sublime, což jsou dnes už jediné editory, které dnes používám (když nepočítám Vim…).

Co se mi asi na ESLintu o trochu víc líbí je jeho konfigurace. Konfigurační soubor můžete mít jak v JSON souboru, tak v JS, ale i v Yamlu. V rámci projektu můžete mít v root adresáři výchozí konfiguraci pro ESLint a v dalších jeho podadresářích můžete mít specifické, upravené konfiguráky dle konkrétní potřeby. Vedle toho můžete použít něčí best-practice vzorový konfigurák, ten použít jako základ a upravit jen to chcete jinak…

V ESLintu samozřejmě funkují inlajnované directivy pro linter vkládané přímo do souborů se zdrojáky, stejně jako v JSHintu.

Instalace

© 2017 pepa.holla.cz

Theme by Anders NorénUp ↑