ALMAD: handle error a process res je jen pseudo kod, aby to tam neprekazelo :) na gist jsem uplne zapomnel, uz jsem to tam preklopil: https://gist.github.com/anonymous/8407413

Poradil bys prosim, jak se zbavit tech closures, aby tam nezustavalo nic viset a nepolykalo to pamet? Diky.

KEEPER: Yup, potrebujes se zbavit tech closures.

Co ma BTW delat "process run" a "handle error"? ;)

Zdravim, potrebuju vytvorit script, ktery by nepretrzite stahoval data (json) z url, max vsak jednou za 2s, abych nezahltil server. Zjednodusene jsem si to predstavoval nejak takhle:

[JavaScript] var https = require('https'); var limit = 2 * 1000; function fetch(cb) { - Pastebin.com
http://pastebin.com/F27dyNir

Pokud tenhle script ale spustim, s kazdym requestem se zvysi pamet node processu, coz moc nenahrava tomu, ze by to melo bezet nonstop :) Predpokladam, ze to neni uplne normalni a nekde mam chybu. Mam takovy podezreni, ze to bude zpusobovat ta rekurze, ale nevim, jak to provyst jinak. Node mam 0.10.24.

Predem diky za radu.

Jsme jeden z nejranejsich uzivatelu node v CR. Hledame nove kolegy.

Nekteri mozna neskonci primo v node.js, ale vzdycky budete zatracene blizko.

Apiary — Jobs
http://apiary.io/jobs

Ahoj, hledám node.js developera na různé jednorázové zakázky pro jeden projekt co rozbíhám. Ideálně pokud by měl zájem o herní vývoj.
První by byla rozběhnutí a konfigurace https://github.com/nodejitsu/node-http-proxy na virtuálním serveru.

EGGH: Ahoj, toto forum je o server-side javascripte, na svoj request skus [ client side scripts (JavaScript) ]

kazdopadne to co chces urobit je viacmenej blbost, niektore prehliadace nativne blokuju window.open , lebo je to user hijack/spam metoda.
Nepotrebujes otvorit viac ako prave 1 okno, urobit prave 1 redirect adt. ak ano, mas to zrejme spatne premyslene.

Ahoj, snad jsem tu správně. Pokouším se vytvořit odkaz, na který když kliknu, tak se mi v prohlížeči otevře více oken s více stránkami. Např. když kliknu na odkaz, tak se mi otevře stránka seznam.cz, google.com, ebay.com, aukro.cz atd. Našel jsem na návod tady ale vždy se mi otevřou max. 2 linky i když jich tam mám 15 - prohlížeč opera. V IE se otevře jen první. V čem je chyba?

ve výsledku to tedy pak vypadá, že jsou balíky duplicitní (a určitě jsou), ale častokrát jeden balíček potřebuje nějaký jiný v jedné verzi a druhý zase chce verzi úplně jinou

mam dotaz k npm: nainstaluju si nejaky packages (D3, Cube, ...) do ~/node_modules/ nacez v adresari package pustim npm install a nainstaluji se zavislosti do ~/node_modules/*/node_modules/. Proc? Mnozi se mi duplicitni baliky v ~/node_modules/*/node_modules/, muzu je proste kopirovat do ~/node_modules/ ?

Bohužel nad tím jsem zatím moc nepřemýšlel, jak modelovat tu socketovou komunikaci. Spíš se tak nějak spoléhám, že to namodeluji právě pomocí BDD specifikace, která bude schopna ověřit, že vše funguje jak má. Chci to celé psát hodně modulárně, takže počítám z využitím socket namespace docela extenzivně.

Asi jsem nepochopil, co myslíš tím spec up front a že to není zadarmo.

Jak jsem psal, plánuju to tak, že veškeré mocky/stuby se budou injectovat pouze pro unit testy. Jakmile bude potřeba projet integrační testy, tak se tyhle simulace vyhodí a bude to (aspoň doufám), komunikovat proti živému zdroji.

Docela velkou šanci také vidím v tom, že pro architekturu jsem zvolil ECS, takže vše bude dost na sobě nezavislé a bude se to dobře testovat. Testování DOM mě momentálně trápí skutečně nejmíň ze všeho. Jak jsem psal, UI nebude nijak extenzivní a rozsáhlé. Většina bude o backendu, který se naštěstí dobře testuje.

AREX: Kdybys mel napady jak to vyresit, tak dej vedet -- jak vyresit realtime API / jak popsat message-based workflow resime uz nejakou dobu a furt nas nenapada nic dostatecne dobreho :/

AREX: Na to BDD jenom pozor ze to je vlastne dost narocny spec up front. Nic proti tomu, jenom ze to neni zadarmo (jako nci).

AREX: My projeli ruzna komba zombie/phantomjs/par jinych bazmeku, nicmene ve vsech ten server pod tim vzdycky bezel. IMHO to na *integracni* testy je potreba, jinak testujes v podstate jenom jednotkove...

Nejvetsi problem techhle testu je stejne 1) fakt ze DOM je API na coz neni frontend uplne stavenej a je potreba, aby s tim byli vsichi srozumeni 2) rychlost.

AREX: To je v pohodě dost často se řiká mock všemu :)

MARYO: Jo, máš pravdu, stuby budou lepší, trochu jsem poplet terminologii :)

AREX: Sice jsem to ještě nepoužil, ale až budu dělat příště REST API, určitě to vyzkouším, každej to chválil. Tohleto oddělení jsme dřív řešili tak, že jsme použili na straně klienta driver s testovacíma datama v local storage.

Ten socket.io už je trochu specifičtější problém no a žádný udělátko co by ti udělalo server na to asi nebude, nemám s tim moc zkušenost... Ale vzhledem k tomu, že akci může vyvolat i server, tak by se to asi blbě testovalo :)

Takže bych řekl, že nejlepší bude stubnout metody socket.io. V tom by mohl pomoct Sinon nebo Jasmine. Socket.io je vlastně pub-sub. Takže hned ten první a pár dalších příkladů.

Sinon.JS - Documentation
http://sinonjs.org/docs/#stubs

MARYO: Akorát teď koukám, že to stejně nebudu moct tolik využít. Chceme totiž využívat socket.io pro největší část komunikace. Apiary vypadá, že je pořád stavěná na bázi request / response, což u socketů není.

MARYO: Díky, to vypadá velice zajímavě, nevěděl jsem o tom.

Screencast apiary demo—by apiary.io
http://docs.screencast.apiary.io/

AREX: Aha, pochopil jsem to špatně. Namockovat server je určitě dobrá myšlenka.
http://apiary.io/ znáš?

MARYO: No jelikož uživatelské rozhraní bude spíš jednoduší, tak testy UI mě momentálně tolik netrápí. Tedy ani Cucumber bych do toho zatím tolik nemotal, ale časem na něj taky dojde řada počítám.

Nicméně tak nějak se mi líbí ta představa, že klient nebude závislý na serverové implementaci. Chtěl bych totiž celkové workflow nastavit tak, že se napíše specifikace v BDD stylu pro server. Pak zatímco jeden developer bude bouchat serverovou implementaci podle toho, tak další člověk si vezme tu specifikaci a pomocí mocku bude vyvíjet klienta aniž by musel čekat, až bude implementace serveru připravena.

Z mojí zkušenosti vím, že moc dobře nefunguje, když vývojáři serveru musejí být s implementací napřed a pak při chybách se k tomu vracet a dělat fixy. Navíc počítám, že mocky by se psali do separatního souboru, takže jakmile by server měl svojí implementaci, mocky by se odstavili a testy by proběhly proti tomu. Nahlášené bugy serveru se pak budou fixovat a klientský vývojář si zase zapne mocky a může pokračovat nerušeně dál.