Backend-разработка

Задание 3: бот

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

Бот должен уметь работать с сообщениями через несколько механизмов доставки:

• консоль: сообщение пользователя вводится со стандартного ввода, ответ бота выводится в стандартный вывод (например, с помощью getLine и putStrLn).

• Telegram: https://core.telegram.org/bots/api#poll

Вместо Telegram можно выбрать VK (см. документацию) или Slack.

Функциональные требования

• Пользователь может отправить команду /help и увидеть текст, описывающий бота.

• Пользователь может отправить команду /repeat, и в ответ бот отправит, какое сейчас выбрано значение повторов и вопрос, сколько раз повторять сообщение в дальнейшем. К вопросу будут прилагаться кнопки для выбора ответа (кнопки с цифрами от 1 до 5). После выбора пользователем все ответы бота должны дублировать сообщение пользователя указанное кол-во раз. Кол-во повторов должно быть индивидуальным для каждого пользователя, т. е. если один пользователь выбрал 3 повторения, то второму мы по-прежнему показываем начальное кол-во сообщений.

• Все должно быть максимально кастомизируемо через конфиги:

  • Сообщение, отправляемое в ответ на /help.

  • Вопрос по команде /repeat.

  • Начальное кол-во повторов на каждый ответ.

• Бот должен уметь повторять только текстовые сообщения и какой-нибудь один вид мультимедийных сообщений (например, стикеры или картинки). Остальные виды сообщений можно игнорировать. Конечно, этот пункт не распространяется на сообщения из консоли.

Технические требования

• Можно взять за основу шаблон проекта. Он содержит "скелет" логики бота и некоторые тесты. Запустите stack test и попробуйте исправить логику, чтобы тесты начали проходить. Шаблон можно как угодно править по своему усмотрению, а можно не использовать совсем.

• Для основного кода проекта (кроме тестов) использовать только библиотеки из стандартной поставки Haskell Platform и три сторонние:

  • Для отправки http-запросов

  • Для парсинга json

  • Для работы с конфигом.

• Все остальное должно быть сделано по максимуму без библиотек. Для тестов можете использовать любой удобный вам инструмент (hspec, HUnit, etc).

• Обновления от Телеграма получать не посредством веб-хуков, а посредством поллинга. Отправлять запрос за апдейтами телеграму, тот сам будет ставить ответ на паузу, если обновок нет, и отвечать сразу, как только что-то появилось. Ну или отвечать пустым массивом по таймауту. Это требование вкупе с тем, что в следующем задании надо будет свой сервер на Warp реализовать, поможет лучше понять, что такое модель поллинга и модель пуша (через веб-хуки), в чем преимущества и недостатки каждой из моделей.

• Результатом должно быть одно приложение, а не два. В каком режиме его запускать (Telegram или консоль), определяется параметром в конфиге или опцией командной строки.

Следующие технические требования также распространяются и на следующее задание "Веб-сервер"

• Проект должен быть в отдельном репозитории на github, во время выполнения задания коммиты делать как можно чаще, как минимум раз в день, когда написана хоть строчка кода.

• Использовать stack, все используемые библиотеки должны быть зафиксированы в файле package.yaml, сам проект должен быть инициирован командой stack new, которая создает базовую структуру Haskell-проекта.

• Для разворачивания должно быть достаточно клонирования репозитория и запуска stack build. Обязательно проверить это правило клонированием репозитория в отдельную папку у себя и запуска stack build — результатом должны быть собранные и рабочие бинарники.

• У каждого проекта должно быть README с описанием того, как разворачивать проект локально и как его запускать, а так же с описанием базовой структуры, чтобы новичок мог легко разобраться (представьте, что после вас проект будет поддерживать совсем нулевой джуниор). Все должно быть на английском.

• 1. Проект должен иметь файл .gitignore, куда внесены все автогенерируемые файлы проекта, локальные конфиги и т.д. Обязательно добавьте туда следующие папки (даже если вы не пользуетесь редактором VSCode, им пользуемся мы и это правило для нашего удобства при проверке):

  • .vscode

  • .history

• Проект должен быть покрыт unit-тестами, которые бы покрывали главные use-case каждого модуля в приложении.

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

• Проект должен поддерживать логи разных уровней, все ключевые моменты должны грамотно логироваться, логи должны легко конфигурироваться хотя бы так, чтобы можно было включать/выключать логи до определенного уровня (например, показывать все от DEBUG и выше, или показывать все от WARN и выше).

• Для понятной архитектуры рекомендуем использовать Handle Pattern, так как мы применяем его в большинстве своих проектов.

• Чтобы добиться понятной архитектуры проекта, и получить тестируемый код, также можно применять различные техники (паттерны) описанные сообществом:

  • The Service Pattern.

  • The ReaderT Design Pattern (Discussion).

  • Three Layer Haskell Cake.

• Полезно почитать требования к проекту из задания 5 (код-ревью). На старте проекта необязательно забивать себе ими голову — потом успеете, но, все-таки, если знать их заранее, придется меньше исправлять.