Skip to content

Latest commit

 

History

History
153 lines (108 loc) · 11.3 KB

bot-task.md

File metadata and controls

153 lines (108 loc) · 11.3 KB

Третье задание: бот

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

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

  • консоль: сообщение пользователя вводится со стандартного ввода, ответ бота выводится в стандартный вывод (например, с помощью getLine и putStrLn).
  • Telegram: https://core.telegram.org/bots/api#poll

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

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

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

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

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

    1. Сообщение, отправляемое в ответ на /help.
    2. Вопрос по команде /repeat.
    3. Начальное кол-во повторов на каждый ответ.

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

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

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

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

    1. Для отправки http-запросов
    2. Для парсинга json
    3. Для работы с конфигом.

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

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

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

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

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

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

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

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

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

    • .vscode
    • .history

  6. Проект должен быть покрыт unit-тестами, которые проверяют корректность бизнес логики. Например, тестировать функцию отправки сообщений через Telegram API не требуется, но должны быть тесты, проверяющие, что в ответ на команду /repeat, пользователю будет отправлен запрос на выбор числа повторений.

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

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

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

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

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

Источники