Статья говорит, что in/our есть, но использовать их не нужно. А если нужно, то использовать с осторожностью. Так если они всё-таки нужны, то хотелось бы реальные примеры где они помогают.
Да, это безусловно субъективное. И применительно к обсуждаемому приложению я не вижу большого числа жаргонизмов. Но, как мне кажется, если заменить жаргонизмы на родные слова,то это никого раздражать не будет. А раз это снизит напряжение аудитории, то надо делать :)
Сверьтесь со словарем и не тащите ненужный мусор. Например, "замьютить чат" можно заменить на "выключить уведомления". Возможно, молодежь это не раздражает, но когда тебе за 40 все эти словечки выглядят ка ляпы, на которые акцентируется внимание и морщится мозг. Программа ориентирована не только на 20-летних же?
Постоянно дрюкать огромную таблицу в базе на предмет наличия ключа идемпотентности будет сильно тормозить брокер. Если складывать в redis set или lru-кэш в памяти, то их память будет пухнуть под высокой нагрузкой. Нет ли каких-то готовых подходов к реализации идемпотентности?
Например, если у вас есть какое-то публичное api, то можно сделать метод генерации ключа и использовать завязанную на timestamp генерацию (uuid v7 или что-то свое). В этом случае за старым ключом можно сходить в базу, а за свежим в redis. Но это первое что пришло в голову, может кто-то уже погружался в тему и знает типовые промышленные подходы?
Имеется в виду какая-то рабочая база данных? Если вообще ни к какой БД не привязываться, то можно поломать слой сохранения/считывания данных и в тестах это не увидеть. Или вы имеете в виду, что для тестов надо всегда разворачивать какую-то базу с нуля?
Не у всех заводится. Я пробовал несколько раз уже. То elastic-apm-node какую-то метрику нереализованную использовал. Пофиксили. Сейчас на express споткнулся. Он пакет depd используется (зачем я хз), а тот завязан на формат stack-trace (объекты Callsite у node и строки с переносами у bun) и снова не заводится.
Понятно, что express уже давно можно было бы заменить на fastify или что-то иное, но у нас пока так.
В статье дается какой-то класс, но не видно как этот инструмент применяется. Нет примеров встраивания.
По самому классу, код не выглядит ни отшлифованным, ни готовым к использованию в промышленной системе.
Несколько примеров.
Использование console.log. Для системы с централизованным логированием весь этот вывод должен направляться в класс/интерфейс логгера с учетом уровней логирования.
Обработка ошибок. Наверняка часть ошибок не обязана выбрасываться наружу, а может быть обработана на месте, например, через повтор операции (бывает что сеть дала сбой и надо сделать переподключение/переотправку).
Часть последовательных await может быть объединена в Promise.all(). Например, вот эти две строки:
Чего из предложений js действительно не хватает, так это принятие Temporal всеми браузерами и нодой. Как в базу пойдешь за датой рождения, так драйвер тебе дату-время дает то со смещением часового пояса, то без.
Зачем этим вообще заниматься мессенджеру? Его задача заблокировать доступ к переписке чужим органам и открыть своим. Теже тенденции сейчас и в Европе происходят.
А всякими анализами программ и чего-либо еще могут и другие заниматься (во что я вообще не верю), например, ruStore.
Из статьи можно сделать вывод, что страны готовы тратить без особых ограничений. Раз они в гонке, то хотят получить какой-то приз за первенство в чем-то, чего еще никто не достиг, но в чем каждый уверен. Возможно, они бегут за AGI? А поскольку вкладываются в стартапы, то ищут новые идеи и запас времени еще есть.
Javascript не ограничивается фронтендом, а указанные в статье библиотеки нацелены лишь на него. Так и написали бы в заголовке, что речь только о фронте.
С ноды 20.не_помню_минор (в 22 тоже) есть экспериментальная опция загрузки esm через require. А так согласен, что гемор полный. Особенно когда тебе на выходе еще и бинарник получить надо. Всякие pkg начинают глючить.
Как раз в этом году покупал похожие стулья на дачу. Прочитал статью и теперь не понимаю эту экономику маркетплейса (мегамаркет): 4 стула по 23190 - кешбэк бонусами 12437 (54%).
Цена стула получается 2688. Суда по статье это почти себестоимость. А тут еще логистика + бесплатная доставка до квартиры.
Как получается такая цена? Инвестиции маркетплейса в долю рынка? Демпинг продавца? Но по другим позициям у них наоборот дороше тех же озон и wildberries (например, в разделе одежда ряд позиций дешевле на озон в 2 раза).
Статья говорит, что in/our есть, но использовать их не нужно. А если нужно, то использовать с осторожностью. Так если они всё-таки нужны, то хотелось бы реальные примеры где они помогают.
Да, это безусловно субъективное. И применительно к обсуждаемому приложению я не вижу большого числа жаргонизмов. Но, как мне кажется, если заменить жаргонизмы на родные слова,то это никого раздражать не будет. А раз это снизит напряжение аудитории, то надо делать :)
Сверьтесь со словарем и не тащите ненужный мусор. Например, "замьютить чат" можно заменить на "выключить уведомления". Возможно, молодежь это не раздражает, но когда тебе за 40 все эти словечки выглядят ка ляпы, на которые акцентируется внимание и морщится мозг. Программа ориентирована не только на 20-летних же?
Постоянно дрюкать огромную таблицу в базе на предмет наличия ключа идемпотентности будет сильно тормозить брокер. Если складывать в redis set или lru-кэш в памяти, то их память будет пухнуть под высокой нагрузкой. Нет ли каких-то готовых подходов к реализации идемпотентности?
Например, если у вас есть какое-то публичное api, то можно сделать метод генерации ключа и использовать завязанную на timestamp генерацию (uuid v7 или что-то свое). В этом случае за старым ключом можно сходить в базу, а за свежим в redis. Но это первое что пришло в голову, может кто-то уже погружался в тему и знает типовые промышленные подходы?
Имеется в виду какая-то рабочая база данных? Если вообще ни к какой БД не привязываться, то можно поломать слой сохранения/считывания данных и в тестах это не увидеть. Или вы имеете в виду, что для тестов надо всегда разворачивать какую-то базу с нуля?
Не у всех заводится. Я пробовал несколько раз уже. То elastic-apm-node какую-то метрику нереализованную использовал. Пофиксили. Сейчас на express споткнулся. Он пакет depd используется (зачем я хз), а тот завязан на формат stack-trace (объекты Callsite у node и строки с переносами у bun) и снова не заводится.
Понятно, что express уже давно можно было бы заменить на fastify или что-то иное, но у нас пока так.
В статье дается какой-то класс, но не видно как этот инструмент применяется. Нет примеров встраивания.
По самому классу, код не выглядит ни отшлифованным, ни готовым к использованию в промышленной системе.
Несколько примеров.
Использование
console.log. Для системы с централизованным логированием весь этот вывод должен направляться в класс/интерфейс логгера с учетом уровней логирования.Обработка ошибок. Наверняка часть ошибок не обязана выбрасываться наружу, а может быть обработана на месте, например, через повтор операции (бывает что сеть дала сбой и надо сделать переподключение/переотправку).
Часть последовательных await может быть объединена в Promise.all(). Например, вот эти две строки:
Тут нам ничего не мешает создавать или проверять наличие таблицы пока выполняется какая-то сторонняя обработка.
Вот тут не ясно зачем вам await внутри callback если вы и так промис ждете из него, а обработку ошибок внутри callback не делаете:
У вас в close делается освобождение занятых классом ресурсов. Для этого в typescript завели специальный инструмент.
Чего из предложений js действительно не хватает, так это принятие Temporal всеми браузерами и нодой. Как в базу пойдешь за датой рождения, так драйвер тебе дату-время дает то со смещением часового пояса, то без.
Зачем этим вообще заниматься мессенджеру? Его задача заблокировать доступ к переписке чужим органам и открыть своим. Теже тенденции сейчас и в Европе происходят.
А всякими анализами программ и чего-либо еще могут и другие заниматься (во что я вообще не верю), например, ruStore.
А здесь не так сказано:
https://developer.android.com/reference/android/Manifest.permission
Allows applications to disable the keyguard if it is not secure.
Я это читаю как если нет защиты, то снимет блокировку, иначе нет. Кому в итоге верить?
Из статьи можно сделать вывод, что страны готовы тратить без особых ограничений. Раз они в гонке, то хотят получить какой-то приз за первенство в чем-то, чего еще никто не достиг, но в чем каждый уверен. Возможно, они бегут за AGI? А поскольку вкладываются в стартапы, то ищут новые идеи и запас времени еще есть.
Во сколько примерно обходится станок целиком? На ваши детали есть понятная разумная цена, но там еще много чего требуется докупить в других местах.
Возможно, у вас есть готовая смета?
Почему нельзя прервать процесс поиска через AbortController?
Что-то вроде gitlab с ассистентом получилось?
Javascript не ограничивается фронтендом, а указанные в статье библиотеки нацелены лишь на него. Так и написали бы в заголовке, что речь только о фронте.
С ноды 20.не_помню_минор (в 22 тоже) есть экспериментальная опция загрузки esm через require. А так согласен, что гемор полный. Особенно когда тебе на выходе еще и бинарник получить надо. Всякие pkg начинают глючить.
Как раз в этом году покупал похожие стулья на дачу. Прочитал статью и теперь не понимаю эту экономику маркетплейса (мегамаркет): 4 стула по 23190 - кешбэк бонусами 12437 (54%).
Цена стула получается 2688. Суда по статье это почти себестоимость. А тут еще логистика + бесплатная доставка до квартиры.
Как получается такая цена? Инвестиции маркетплейса в долю рынка? Демпинг продавца? Но по другим позициям у них наоборот дороше тех же озон и wildberries (например, в разделе одежда ряд позиций дешевле на озон в 2 раза).
Не ясно чем принципиально отличается от NestJs. Почему нельзя было накрутить требуемую функциональность поверх Nest.
Исходя из примеров все очень близко.
Полагаю, что это требования по системному дизайну. Для него есть roadmap по изучению на популярном ресурсе: https://roadmap.sh/system-design
А нельзя уволочь на луну/марс? Там, как мне кажется, даже старье могло бы пригодиться.