CategoryNezařazené

NVM, NPM problém

Pro běh NodeJS runtime používám NVM, který mi dovoluje do produkce dostat novější verzi NodeJS, než je v oficiálních balíčcích použité linuxové distribuce. A je v podstatě jedno, jestli běžíte na Centosu, Fedoře nebo Debianu, protože situace je v tomto ohledu všude stejná…

Vedle toho jsem v současné době začal vytvářet a distribuovat privátní NPM balíčky s funkcionalitami, které chci opakované používat ve více projektech. NPM je super. Vyvíjím v TypeScriptu, builduji balíček do čistého JavaScriptu, přidávám definice types (respektive se při vhodné konfiguraci generují sami), aby ostatní konzumenti mého balíčku věděli jak je použít.

Konfigurace produkce

Ale v podstatě i jakéhokoliv develop stroje, kde chcete mít přístup k privátním NPM balíčkům. Aby vám vše fungovalo jak má, je potřeba jen jemně dokonfigurovat prostředí. Úprava spočívá v úpravě .bashrc a .npmrc. Nic složitého:

1. Konfiguracve NVM

Někde na konci vašeho .bashrc přidejte pro NVM následující

Tím máte NVM funkční a můžete skrze něj instalovat požadované NodeJS runtimy:

A NodeJS vám běží v poslední dostupné stabilní verzí:

2. Konfigurace NPM
Vytvořte ~/.mpmrc a do něj vložte

A do svého .bashrc přidejte následující řádek:

Hotovo 🙂

No a tady přišel problém.

Pokud zmodifikujete své, nebo produkční prostředí, tak jak jsem popsal, přestane vám NodeJS fungovat 🙂
Problém je v nevinně vypadajícím export env proměnné NPM_TOKEN na konci vašeho .basrc. Pokud jej odeberete, nebo zakomentujete, bude vám NVM opět fungovat a tím pádem j node poběží…

Řešení

Stačí přemístit v .bashrc příkaz exportující NPM_TOKEN před příkazy exportující proměnné pro NVM…
Výsledná konfigurace v .bashrc by měla vypadat takto:

Funguje 🙂

Go Lang: intro book

An Introduction to Programming in Go

NodeJS CLI: Lighthouse

Lighthouse je open source nástroj od Googlu, sloužící k měření kvality www stránek (performance, accessibility, progressive web apps a další…). Jeho tvůrci jej popisují jako automatizovaný nástroj pro zlepšování kvality webových stránek.

Standatně můžete Lighthouse použít buď jako rošíření do prohlížeče, nebo přímo v Chrome DevTools.

Oboje funguje, nicméně ani jeden ze způsobů použití tohoto nástroje není vhodné pro automatizované měření kvality, jak jej vývojáři z Goolgu proklamují.

Další nevýhodou nástroje integrovaného do prohlížeče je, že naměřené výsledky může zkreslovat aktuální stav Chrome v momentě, kdy měření provádíte. Komunikace v ostatních záložkách, využití CPU a RAM…

NPM: skuteně automatizovaný Lighthouse

No a pak přichází v potaz skutečně plně automatizovatelné měřění pomocí NPM balíčku Lighthouse

Instalace

Spuštění

Výsledek

Výsledkem je HTML stránka, která obsahuje všechny naměřené informace. Dalším plusem pro automatizované zpracování může být, krom samotného spouštění přímo z příkazové řádky i možnost výstupu naměřených hodnot do JSONU, pro jejich další zpracování.

Digitální transformace s NodeJS DevOps stackem

PayPal, Netflix a Wallmart představují způsob jak rychle transformovat legacy software.
node-js-devops-stack-transformation

TypeScript: Cannot find name ‚module‘.

Pokud si v nějakém typescriptovém modulu s vašim zdrojákem dovolíte tohle:

Okamžitě na vás začně kompilér upozorňpvat, že nemůže najít název modelu.


Chyba je jasná: TypeScript neví nic o CommonJS modulu, na kterém staví NodeJS a na který se ve zdrojáku odvoláváte.

Řešení

Korektním řešením je doinstalování balíčků s NodeJS typy:

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?

nodejshosting.cz

Výpočet GEO vzdálenosti v JavaScriptu

Výpočet dle Haversine formula

Základy CURL

Pokud píšete nějakou REST aplikaci a potřebujete nějak komunikovat se serverem, a tím myslím třeba něajak efektivně mu posílat data, a třeba i dávkově, a nevyhovuje vám HTTPie nevyhovuje, nebo inklinujete k něčemu tradičnímu, pak rozhodně zkuste CURL.

CURL je moncný nástroj, který toho umí mnohem víc, než jen odesílání POST requestů. Samozřejmostí je modifikace hlaviček a například také SSL komunikace.

Clock cycles consumed by typical system tasks

L1-cache 3 cycles
L2-cache 14 cycles
RAM 250 cycles
Disk 41,000,000 cycles
Network 240,000,000 cycles

Autor: Ryan Dahls

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑