кстати, как-то можно из коробки обпромисифаить все сразу в одну строчку или птичку в конфигурации какой-то?

зачем использовать deprecated?

не надо использовать, раньше ее использовали, когда небыло современных стандартов. Где кстати инфо по поводу что она deprecated_?

util.promisify

Я про то, что не надо забивать асинхронные гвозди камнем, когда у вас есть молоток

ну как сказать я вот давеча подкаст слушал нодовский за асинки как раз там подымались интересыне темы

правда он не всё-всё промисифицирует

util.promisify

я понимаю чт промисифай, можно ли его применить сразу ко всему апи а не обворачивать отдельно?

по моему нет

но есть bluebird

так вот там вопрос был элементарный - какой-нить fs.exist есть, но как-то не айс что оно сделает throw если файла нету

(бзв я себе об это как раз ногу отстрелил недавно)

try { if (await fs.exist(path){ lala } catch (e) { // not exist } в принципе согласен что калечно

const exist = await fs.exist(path) - так ок выглядит

Ну и что? Если человеку так удобнее пусть пишет так. Или код не сработает??

Неиллюзорный шанс что тимлид палкой будет пиздить за такое

так вот там вопрос был элементарный - какой-нить fs.exist есть, но как-то не айс что оно сделает throw если файла нету

всмсле не айс? ращве с коллбэками не надо было ошибки хэндлить?

всмсле не айс? ращве с коллбэками не надо было ошибки хэндлить?

не ну тут вопрос в другом - отсутствие файла это не ошибка а предсказуемый валидный результат - там в подкасте речь шла как раз о том что не все там так легко в апи лихо на асинк авейт лоб в лоб меняется

асинк авейт это ок но в меру и с умом

exist это вообще антипаттернт в большенстве случаев

надо делать сразу операцию и хэндлить ENOENT

всмсле не айс? ращве с коллбэками не надо было ошибки хэндлить?

не совсем надо было - ниче страшного не было если файла нет, ну да эррор но не throw ведь который потенциально к реджектед промис/апп креш приведет

я понимаю чт промисифай, можно ли его применить сразу ко всему апи а не обворачивать отдельно?

Самый "лучший" подход который видел function requirePromise(modName, fnName) { return require('util').promisify(require(modName)[fnName]); } const stat = requirePromise('fs', 'stat'); const writeFile = requirePromise('fs', 'writeFile'); const appendFile = requirePromise('fs', 'appendFile');

т е нода с коллбеками толерантна к ошибками вроде как, в случае с промисами как я понял со слов авторов это чуть более чревато крешем

Самый "лучший" подход который видел function requirePromise(modName, fnName) { return require('util').promisify(require(modName)[fnName]); } const stat = requirePromise('fs', 'stat'); const writeFile = requirePromise('fs', 'writeFile'); const appendFile = requirePromise('fs', 'appendFile');

да, наверное, я в принципе как-то так и делаю, но все равно хотелось из коробки без лишних плясок

Наврятли будет

т е нода с коллбеками толерантна к ошибками вроде как, в случае с промисами как я понял со слов авторов это чуть более чревато крешем

Вот тут немного не понимаю в чем проблема, в чем здесь отличие от callback версии?

Вот тут немного не понимаю в чем проблема, в чем здесь отличие от callback версии?

если в коллбек прилетит еррор и его никак не похендлить и просто заигнорить апка не закрешится, в случае с промисами если там явно в кеч не завернуть и что-то внутри выстрелило/зареджектилось то апка упадет с анхендлд реджекшен

это уже стиль хэндлинга ошибок разный просто

просто с коллбеками независимо от наличия эррора человек напишет коллбек хендлящий удачное выполнение, в случае с промисами - это обязательное требование хендлить ошибку иначе все упадет

это уже стиль хэндлинга ошибок разный просто

речь не о стиле хендлинга а о том что будет если его нет

в коллбэках он есть по умолчанию просто

если в коллбек прилетит еррор и его никак не похендлить и просто заигнорить апка не закрешится, в случае с промисами если там явно в кеч не завернуть и что-то внутри выстрелило/зареджектилось то апка упадет с анхендлд реджекшен

неборабатывать error в callback нельзя, это нужно всегда делать

т.к ошибка приходит параметром

его не может не быть

просто с коллбеками независимо от наличия эррора человек напишет коллбек хендлящий удачное выполнение, в случае с промисами - это обязательное требование хендлить ошибку иначе все упадет

без async/await ничего падать не будет

Неиллюзорный шанс что тимлид палкой будет пиздить за такое

Чувак только начал js учить при чем тут тимлид

неборабатывать error в callback нельзя, это нужно всегда делать

нужно, но если этого не сделать, то нода не загнется, разве нет?

Чувак только начал js учить при чем тут тимлид

Раз начал, то надо правильно учиться

в случае с асинк авейт - выстрелит throw и в случае отсутствия кетча все упадет

нужно, но если этого не сделать, то нода не загнется, разве нет?

Ничего хорошего от этого не будет :)

Не упавшее приложение != рабочее

Ничего хорошего от этого не будет :)

ну это уже другой вопрос но это был комент на тему толрантности ноды к ошибкам

да, приложение будет полунерабочее вероятно

в случае с асинк авейт - выстрелит throw и в случае отсутствия кетча все упадет

в случае с коллбэком у тебя неявный кэтч на другом уровне который передает ошибку параметром

я ж не говорю что это хорошо или плохо, а только о том что нода толерантна к этому (пока что)

Так толерантности нет. Просто где-то легче забыть обработать, гдето сложнее :)

Так толерантности нет. Просто где-то легче забыть обработать, гдето сложнее :)

ну как нет если скрипт не грохнется и будет спокойно работать дальше хотя лучше бы ему возможно было упасть, это и есть толерантность к ошибкам

ошибка есть но пофиг пляшем :3

Раз начал, то надо правильно учиться

Snake case не будет корректно работать?

ну как нет если скрипт не грохнется и будет спокойно работать дальше хотя лучше бы ему возможно было упасть, это и есть толерантность к ошибкам

Нет, толерантность к ошибкам это когда система "востанавливается" и продолжает работать, нут восстановления как такового нет. Но я понимаю о чем вы

camelCase

Нет, толерантность к ошибкам это когда система "востанавливается" и продолжает работать, нут восстановления как такового нет. Но я понимаю о чем вы

ошибка упала, ошибка не похендлена, система продолжает работу. Что именно тут надо понимать под восстановлением тогда?

ошибка упала, ошибка не похендлена, система продолжает работу. Что именно тут надо понимать под восстановлением тогда?

К примеру HTML не валидный - тэги сами закрываются или еще что (это и есть восстановление).. в случае с необработаной ошибкой файлы сами не закроются

К примеру HTML не валидный - тэги сами закрываются или еще что (это и есть восстановление).. в случае с необработаной ошибкой файлы сами не закроются

возможно тут уже пошла путаница слов при переводе - речь не шла про fault tolerance

Вот да. Я думаю тут тупо терминология пошла.

я просто говорю что было в подкасте и не более, видимо имели ввиду именно что нода просто "терпима" к ошибкам и не падуча, а не о восстановлениях

вообще это дело наверное линтером отчасти разруливается когда есть err неиспользованый в коде, хотя это как-то и не совсем по назначению и косвенно, но лучше чем никак

Кто работал с rabbitmq для закрытия соед подтверждение после отправки сообщения можно получить только используя СonfirmСhannel?

describe('isSome', async function() { it('Should return false', function() { assert.equal(await foo(arg), false) }) }) почему mocha ругается на await, на async не ругается

describe('isSome', async function() { it('Should return false', function() { assert.equal(await foo(arg), false) }) }) почему mocha ругается на await, на async не ругается

у тебя не там авейт

function() { assert.equal(await foo(arg), false) }

сделай async function() { assert.equal(await foo(arg), false) }

в смысле наоборот авейт там где надо а асинк нет

что то не понял

ааааааа

вот так вот кодить 5 часов без продыху

(: еще и в выходной

ERROR: S client not available

Друзья, такая проблема. Из базы выкачиваю элементы, перебираю циклом и каждый элемент отправляю через сокет. Когда элементов не много, все ок, но когда их много - приложение подвисает. Насколько я понимаю, в очередь событий подряд встают события цикла. Как можно было бы сделать , чтоб пока не завершится текущая итерация, следующая итерация не ставилась в очередь событий, и таким образом, итерация попадает в очередь, следующие события в очереди не относятся к циклу т.е. нод продолжает обрабатывать остальные запросы, как только итерация завершается, в очередь встает следующая итерация ждет своего череда и так далее. Надеюсь понятно объяснил, и надеюсь, что я правильно понимаю этот механизм.

Друзья, такая проблема. Из базы выкачиваю элементы, перебираю циклом и каждый элемент отправляю через сокет. Когда элементов не много, все ок, но когда их много - приложение подвисает. Насколько я понимаю, в очередь событий подряд встают события цикла. Как можно было бы сделать , чтоб пока не завершится текущая итерация, следующая итерация не ставилась в очередь событий, и таким образом, итерация попадает в очередь, следующие события в очереди не относятся к циклу т.е. нод продолжает обрабатывать остальные запросы, как только итерация завершается, в очередь встает следующая итерация ждет своего череда и так далее. Надеюсь понятно объяснил, и надеюсь, что я правильно понимаю этот механизм.

async js

там есть асинхронные очереди и что угодно

Приехал в Ригу. Кто нибудь знает есть ли тут какой нибудь портал с информацией об it тусовках?

Приехал в Ригу. Кто нибудь знает есть ли тут какой нибудь портал с информацией об it тусовках?

чето как-то не тот чат, да? :D

вангую должен быть Рига js какой-нибудь и гуглиться с первой строчки

https://www.meetup.com/RigaJS/?_cookie-check=vCwkuYbZ2aJBaYID

нет пути

чето как-то не тот чат, да? :D

А хз куда еще писать. На тусовку по joomla я точно не хочу))

А хз куда еще писать. На тусовку по joomla я точно не хочу))

ну сурьезно же гуглится с первой строчки

https://www.meetup.com/RigaJS/?_cookie-check=vCwkuYbZ2aJBaYID

Оу, спасибо) я что то затупил)

Оу, спасибо) я что то затупил)

да не за что но я не оттуда поэтому за правдивость инфы не отвечаю

ну сурьезно же гуглится с первой строчки

После вчерашней встрече я еще не отдуплился))

на фейсбуке каком-нить еще омжно вбить Riga javascript например, тоже наверняка чето найдется

Ебать вы тут развели Если вкратце: 1. Async модуль говно. Deprecated говно 2. camelCase для всего, что связано с js. SQL- SNEAK_CASE, ок, но для JS- camelCase 3. В Promise + async/await хэндлинг ошибок еще лучше (гибче (охуеннее)), чем в колбеках

лол

и шо бы мы без гуру делали

Приехал в Ригу. Кто нибудь знает есть ли тут какой нибудь портал с информацией об it тусовках?

Нах тебе вообще с ИТшниками тусовать? Просто тусуй бары там, студентки, итд

Нах тебе вообще с ИТшниками тусовать? Просто тусуй бары там, студентки, итд

Ну начать то надо с чего- то) по барам в любом случае успею)

Приехал в Ригу. Кто нибудь знает есть ли тут какой нибудь портал с информацией об it тусовках?

Meetup

Есть

А что?

Кстати, ты где остановился?

Кстати, ты где остановился?

У матери) изначально то я ее проведать приехал))

У матери) изначально то я ее проведать приехал))

И на сколько ты тут?

И на сколько ты тут?

До 13)

До 13)

А 14го премьера зв))

Чотк чо

А 14го премьера зв))

Гм... кк даже обломно) хотелось бы посмотреть в кино в оригинальной озвучке)

Гм... кк даже обломно) хотелось бы посмотреть в кино в оригинальной озвучке)

На английском же, ну у нас тут

Вот тебе и оригинальная озвучка