игнишн+турбофан - нет

смена одного на другое рушит предсказуемость

Просто не знакомы с новым пайплайном, оттуда все проблемы Дошло

Выходит, что игнишн только в 10 lts появится?

:/ в 8 судя по результатам голосования

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

в8 на кранкшафте не будет мейнейниться

и ничего не ломается

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

Ладно, я и соображаю хреново, и даже то, что читал и изучил, не могу вспомнить

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

Синхронизация календаря убрала бы у третьего пункта один минус и убрала бы второй пункт.

Но проблемы бы всё равно остались.

Но хотя и так примерно всё ясно.

Под uWebSocket может кто подскажет RPC?

ребят, есть кто пишет телеграм ботов? Кто юзает параметр url в запросе answerCallbackQuery? У меня телега регается ошибкой URL_INVALID ? вчера все работало :(

Есть тут нодбекендеры которые юзают ооп подход в ноде?

Вопрос есть

Сразу задавай вопрос.

Нафига вы это делаете

Отличный вопрос

Т.е зачем вам вообще ооп в ноде

за тем же, зачем ООП вообще

Фп рулет?

А зачем ооп вообще?

А фп?

Чтобы делать в классе по 20 методов, из которых от силы 2 будут использовать?

Вот так наброс

Я просто не могу понять

А внятный ответ мне никто из коллег так и не дал

Ты бы литературу попробовал почитать для начала

Чтобы делать в классе по 20 методов, из которых от силы 2 будут использовать?

А зачем так делать то?

:facepalm:

А зачем так делать то?

Ну это ж классика ооп

фп головного мозга детектед

Тебе точно нужно почитать книжки

Чтобы делать в классе по 20 методов, из которых от силы 2 будут использовать?

Если по SOLID раскидывать, ничего такого не случится

Если по SOLID раскидывать, ничего такого не случится

Можешь чуть подробнее?

Можешь чуть подробнее?

Мы сейчас пишем проект на TS, и решили делать все по канону: SOLID, KISS, YAGNI и даже DI применяем. Разбили все на модули, все зависимости обернули в интерфейсы. И ,вроде, пока все очень хорошо идет.

Мы сейчас пишем проект на TS, и решили делать все по канону: SOLID, KISS, YAGNI и даже DI применяем. Разбили все на модули, все зависимости обернули в интерфейсы. И ,вроде, пока все очень хорошо идет.

и покрывать юнит тестами стало проще

А зачем ооп вообще?

Я использую классы для синглтона. И не только

и покрывать юнит тестами стало проще

Спасибо, подкинул информации для подумать, сори что сразу не ответил - телефон отвалился

Нет такого ощущения что кода слишком много?

Что разработка сама по себе идёт медленнее чем могла бы быть?

Мнe что-то подсказываeт, что там избыточности должно быть много

солиды и прочee хорошо, когда у вас вотeрфолл и вы знаeтe конeчныe трeбования

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

Пацан с козырей зашёл

А вы ведётесь

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

например?

Пацан с козырей зашёл

))

А что мешает покрывать тестами функции?

например?

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

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

Ну так обычно и пишeтсы класс, только здeсь от TS'а толку 0. TS добавит исключительно возможность описать интeрфeйс и использовать в DI маппинг IClass->ApiClass

Возможность описывать интерфейсы дорогого стоит

Возможность описывать интерфейсы дорогого стоит

я вообщe нe к этому вeл:) а к тому, что в случаe JS(TS) нe всeгда солид лучшe помeси частичного солида и вастичного фп

Ну так то да

js с его модульностью же не про чистое ООП, особенно на стороне сервера

https://www.еріс.com/ все видели?

Ппц

Я думал так нельзя же комбинировать

CYRILLIC SMALL LETTER IE CYRILLIC SMALL LETTER ER CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I CYRILLIC SMALL LETTER ES

Я думал так нельзя же комбинировать

Там и не комбинировано.

Это кириллицей всё набрано.

Аа, точно

Аа, точно

slack мочит такое

ERROR: S client not available

Поэтому наверное и vk.com

Хотя скоро и в доменах 1 уровня будет бардак

Есть же js2.coffee

Такой ошибки ни к кого не было? Server/userver.js: ../deps/uv/src/unix/core.c:101: uv_close: Assertion `!uv__is_closing(handle)' failed.

в pm2 первый запуск крашится

а потом все ок

хз почему так

Причем только в пм, если просто запускать все ок

Господа, требуется ваша помощь. Как выглядит задача на стороне Frontend части: 1. Открывается диалоговое окно. 2. Пользователь перемещает изображения (Drag & Drop). 3. Пользователь добавляет к каждому изображению определенные метки (не важно, но они есть к каждому изображению, а изображений может быть достаточное количество). 4. Пользователь отправляет данные на сервер. Вопрос касается стороны сервера. Каким образом сопоставлять изображения и параметры к нему? Пришла в мысль следующая штука: 1. photos - array files 2. fields - {"image1": ..., "image2": ..., etc.}

Но вариант не правильный.

Другого не смог найти и придумать.

И как правильно Frontend части?

Использую Koa 2 и koa-better-body

файлы и филды летят у тебя массивами

массивами объектов

просто к каждому элементу файлов пускай соответсвует элемент массива

филдов

Да, так и есть в принципе.

Сейчас с мержем уже работаю)

я слоу, только сейчас увидел)

Ребята, подскажите пожалуйста: как с сервера отдавать динамически сгенерированный архив ? К примеру: на s3 лежит огромное кол-во файлов(скажем картинки). Юзер отправляет timestamp на сервер => сервак в базе ищет новые файлы => собирает архив (скажем в 1gb+) и отдает его юзеру. Но ведь в этом случае при большом кол-ве пользователей будут проблемы с производительностью. Как нужно правильно работать с таким кейсом ?

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

обычно да. Уникальный

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

а что, если закэшировать архивы заранее

опиши кейс подробнее

как сами картинки собираются? по какому параметру?

типа последние загруженные?

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

и так повторять

Сервер отдает апдейты клиенту. Админ на веб-клиенте добавляет юниты с описанием и картинками. Юнит сохраняется/обновляется в базе с новым timestamp. Клиентская часть запрашивает обновления: отправляет timestamp последнего своего обновления на сервер => сервер ищет в базе последние юниты, timestamp которых больше того, что отправил клиент => генерирует новый архив с файлами Проблема в том, что если добовлять юниты нужно будет часто, а клиентов много, будет очень много архивов (одному клиенту может понадобиться апдейт, со вчерашнего дня; другому — месяц назад; третьему — год) И хранить все в кэше будет трудно (я предпологаю). Я вижу только: 1) Действительно все кешировать, но не знаю — делают ли так в таких случаях (кажется что объем кеша будет расти непомерно) 2) Тупо увеличивать количество инстансов с нагрузкой 3) Не знаю: а можно ли отдавать файлы каждый по отдельности ? Не в архиве ? Скажем нужно отдать 1000 картинок => пусть клиент обращается на s3 за ними сам. Так можно делать ?

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