Search
Write a publication
Pull to refresh

Comments 13

Спасибо за то, что поделились!

Запилили на хакатоне бота, его, внезапно, решили развивать - а там уже дикая простыня из if-ов) Как раз недавно слегка погуглил какие-то best practices, там как раз к стейт-машине сводится организация многоуровнего общения. И тут еще ваша статья подоспела)

Разве что у нас нет четких команд, попытались совместить с ИИ, чтобы общение шло естественным языком.

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

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

Телега на каждый апдейт отдает эти данные, если они не закрыты настройками приватности самого пользователя

У меня в ботах +- такая же система, но используется получение ввода от пользователя через ManualResetEventSlim. Может где-то избыточно, но можно сохранять состояние всей команды, всех данных.

Из главного что не увидел это ограничение на отправку сообщений пользователю и общее.

Через RateLimiting сделано общее ограничение на отправку. Для конкретного пользователя сделано через сохранение в ConcurrentDictionary<userid, datetime>. Дальше вычисляется от текущего времени в TimeSpan. Ожидание mres, потом отправка.

Для модернизации можно добавить для конкретного типа сообщений (видео, музыка, текст, etc).

Rate limiting нужен, чтобы ограничить количество запросов от конкретного пользователя?

Это мой первый бот и количество пользователей всего 6 человек, поэтому с нагрузкой вообще не работал

RateLimiting для общего ограничения, на сколько помню, 20 сообщений/сек на отправку и 200 на редактирование.

Я с этим столкнулся на этапе тестирования, поэтому сразу прогуглил и внёс изменения в свой код.

Мне моя реализация нравится чуть больше, но в целом, вы правы, хороший аналог. Просто не нашел его

Статические свойства для регистрации выглядят некрасиво, имхо.

Стандартный способ для подобных целей - атрибут. Нужные кассы декорируются атрибутом, который содержит данные необходимые для регистрации. Рефлексией выбираются все типы, декорированные нужным атрибутом и спокойно регистрируются.

В итоге у нас нет лишних статических свойств, интерфейс не замусорен непонятно чем.

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

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

Ваша разработка платная, моя OpenSource, так что тут сложно сравнивать)
Я не занимаюсь этим на коммерческой основе, просто как пет проект в свободное от работы время

Sign up to leave a comment.

Articles