Есть кстати еще занимательный рассказ Роберта Шекли: "Мисс Мышка и четвертое измерение" - про то как человек как раз сошел с ума складывая в голове все эти кубы
Не силен в Питоне, но кажется здесь в примере кода ошибка:
def get_post_by_id(db, user_id):
post = db.execute(
'SELECT p.id, title, body, created, author_id, username'
' FROM post p'
' WHERE p.id = ?' ,
(post_id,)
).fetchone()
Должно быть так:
def get_posts_by_user_id(db, user_id):
post = db.execute(
'SELECT p.id, title, body, created, author_id, username'
' FROM post p'
' WHERE p.author_id = ?' ,
(user_id,)
).fetchone()
или так:
def get_post_by_id(db, post_id):
post = db.execute(
'SELECT p.id, title, body, created, author_id, username'
' FROM post p'
' WHERE p.id = ?' ,
(post_id,)
).fetchone()
Там много каши с DI, IoC, которые не каждый мидл понимает
Как раз мидл будет дольше выезжать в самописную лапшу в которой непонятно как инициалируются и соединяются друг с другом компоненты типичного nodejs+express приложения. И эта самописная лапша еще может драматически отличаться между различными приложениями.
И наоборот, при использовании DI и IoC разработчик быстрее поймет консистентную структуру приложения(й) и быстрее начнет приносить пользу добавляя новые и изменяя существующие модули
Если для вас Nest — только про подключенные и готовые библиотеки из коробки, то вы не поняли nest.
Интересно, как можно было прийти к такому выводу из моего комментария?
Я говорю о том, что NestJS предлагает ядро которое содержит фактически все что было описано в статье. Плюс к этому фреймворк содержит удобные точки расширения и позволяет по определенным правилам создавать и включать плагины для чего угодно.
Я за то, чтобы взять готовое решение вместо того, чтобы скручивать роутер, swagger, логгеры, адаптер к БД и т.д. с помощью синей изоленты.
Но любая капча на распознавании картинок это попытка выдержать баланс между:
По дефолту не дать роботам совершать действия
Не заставлять клиентов оставлять свое зрение и нервы при попытке распарсить картинку глазами.
В свое время мы использовали как раз старую капчу от Яндекса и столкнулись с жалобами от клиентов, после чего я предложил и внедрил свое решение. Мое личное мнение такое: «Удобства для людей приоритетнее кейсов когда может пролезть какой-то специально обученный бот, которого можно отследить отдельными метриками».
Хм. А почему бы сразу не взять фреймворк NestJS? Не нужно соединять вместе express + typescript + routing-controllers + swagger. Там все это есть уже (или почти) из коробки в более согласованном и удобном виде.
Отличная статья. Все очень четко изложено и советы правильные.
Могу лишь добавить что на выбор библиотеки очевидно сильно влияет ее значимость для проекта. Если библиотека используется в 1-2 местах в сильно некритичной области кода, то на некоторые критерии можно закрыть глаза.
Но если это например основной фреймворк бэкенда, то здесь также помимо перечисленных вещей добавляются такие критерии как: экосистема фреймворка, наличие адаптеров для работы с системами хранения данных, очередями событий, валидаторами и прочими деталями. И цена ошибки в этом случае довольно сильно возрастает.
Объект Array содержит методы map, filter и reduce, которые являются самыми известными функциями в мире функционального программирования из-за их полезности, а также потому, что они не изменяют массив, что делает эти функции «чистыми».
Вот здесь вообще есть нюанс про то, что это справедливо для массивов с примитивными типами данных. Если на входе есть массив объектов, то в том же .filter или .map никто не запрещает как угодно модифицировать элементы массивов и никакой иммутабельности в этом случае не будет
Пока не знаю, что ответить. В моем случае отвечает на русском языке при установленном в настройках телеграмма русском. Речь идет про десктопное приложение для Mac. Если есть желание разобраться, можем создать группу в Telegram, добавить бота и поэкспериментировать.
Да, отличная идея. В принципе действительно можно отказаться от этого поля в пользу произвольного текста с мета-информацией о событии в которую можно записывать что угодно.
Еще 1 вариант — это добавление такой мета-информации отдельной командой. А еще можно например переносить мета-информацию с предыдущего события чтобы не вбивать все каждый раз, но при необходимости иметь возможность поменять ее.
Не совсем понял вопрос, но попробую ответить. Для Telegram в ответе используется язык пользователя который установлен в месенжере и соответствующий идентификатор прилетает вместе с сообщением. Так что кому-то бот отвечает на русском, а кому-то на английском. Для VK я не нашел быстрого способа определить локаль пользователя, не стал заморачиваться и захардкодил 'ru'.
Хорошая статья. Мы примерно так и сделали в новом проекте, только еще добавили использование https://ts-rest.com
Хорошая, статья. Портировал на TypeScript https://github.com/tormozz48/simlpe-neural-network
Есть кстати еще занимательный рассказ Роберта Шекли: "Мисс Мышка и четвертое измерение" - про то как человек как раз сошел с ума складывая в голове все эти кубы
Роберт Хайнлайн. "И построил он себе скрюченный домишко".
По поводу тестов. Здесь есть тонкая грань. Есть 2 крайности:
Создать врапперы для хелперов хелперов стабов и ассертов и да - в этом сложно разбираться и поддерживать.
Убрать явно повторяющиеся строки кода в однотипных тестах в отдельные понятные функции которые находятся прямо в этом же файле например.
Я видел как игнорирование пункта 2 приводило к тестовым файлам на несколько тысяч строк и тетсам на 200-300 строк. Поэтому нужно соблюдать баланс.
P.S. Написать хорошие, работающие, надежные, краткие и понятные тесты это вообще говоря часто сложнее чем основной код.
Не силен в Питоне, но кажется здесь в примере кода ошибка:
Должно быть так:
или так:
Как раз мидл будет дольше выезжать в самописную лапшу в которой непонятно как инициалируются и соединяются друг с другом компоненты типичного nodejs+express приложения. И эта самописная лапша еще может драматически отличаться между различными приложениями.
И наоборот, при использовании DI и IoC разработчик быстрее поймет консистентную структуру приложения(й) и быстрее начнет приносить пользу добавляя новые и изменяя существующие модули
Интересно, как можно было прийти к такому выводу из моего комментария?
Я говорю о том, что NestJS предлагает ядро которое содержит фактически все что было описано в статье. Плюс к этому фреймворк содержит удобные точки расширения и позволяет по определенным правилам создавать и включать плагины для чего угодно.
Я за то, чтобы взять готовое решение вместо того, чтобы скручивать роутер, swagger, логгеры, адаптер к БД и т.д. с помощью синей изоленты.
Но любая капча на распознавании картинок это попытка выдержать баланс между:
В свое время мы использовали как раз старую капчу от Яндекса и столкнулись с жалобами от клиентов, после чего я предложил и внедрил свое решение. Мое личное мнение такое: «Удобства для людей приоритетнее кейсов когда может пролезть какой-то специально обученный бот, которого можно отследить отдельными метриками».
Могу лишь добавить что на выбор библиотеки очевидно сильно влияет ее значимость для проекта. Если библиотека используется в 1-2 местах в сильно некритичной области кода, то на некоторые критерии можно закрыть глаза.
Но если это например основной фреймворк бэкенда, то здесь также помимо перечисленных вещей добавляются такие критерии как: экосистема фреймворка, наличие адаптеров для работы с системами хранения данных, очередями событий, валидаторами и прочими деталями. И цена ошибки в этом случае довольно сильно возрастает.
Вопрос 31.
Вот здесь вообще есть нюанс про то, что это справедливо для массивов с примитивными типами данных. Если на входе есть массив объектов, то в том же .filter или .map никто не запрещает как угодно модифицировать элементы массивов и никакой иммутабельности в этом случае не будет
Еще 1 вариант — это добавление такой мета-информации отдельной командой. А еще можно например переносить мета-информацию с предыдущего события чтобы не вбивать все каждый раз, но при необходимости иметь возможность поменять ее.
Просто хочу напомнить, что работа шахтера — это тяжелый и опасный труд. «Хомячком» можно скорее назвать автора статьи.