Skip to content

Latest commit

 

History

History
266 lines (229 loc) · 34.4 KB

README.md

File metadata and controls

266 lines (229 loc) · 34.4 KB
Raw

Ссылка на сайт откуда был взят курс

Основная цель - сделать бота из Задания 3

  • [[Полезные ресурсы]]
  • [[Отчеты]]

Итого пройдено:

  • ghcup

    • ghc
    • cabal
    • haskell language sever
    • stack

  • О Haskell по-человечески

  • Выполнение обязательных ката на codewars (Задание 1)

  • [x]

  • [x]

  • [x]

  • codewars хПрофиль codewars

Задание 1.1 Первичная теория

Задание 1.2 Первичная практика

  • Выполнение не обязательных ката на codewars
    • [[cw-0000_0008 Valid Braces]]
    • [[cw-0000_0009 Product of consecutive Fib numbers]]
    • [[cw-0000_0010 Reverse words]]
    • Snail неизвестно мин^[Интересная с задача с простым условием, для которой сразу понятен императивный алгоритм с вложенными циклами, но не сразу — функциональный. Помечена как 4-ый кью, но на самом деле достаточно первых глав LYAH и умения работать со списками.]
    • Equal sides of array неизвестно мин^[В задаче нужно найти индекс элемента в списке, где сумма элементов списка слева будет равна сумме элементов списка справа от найденного элемента. Если же такого элемента нет, то вывести -1. В этой кате можно отработать работу со списками, поискать вспомогательные функции в модуле Data.List или же просто посмотреть интересные решение других людей.]
    • Go so far around to the right that you end up left неизвестно мин^[Необходимо реализовать левую свертку через правую. Для решения нужно ознакомиться с реализацией обеих сверток и хорошо понимать, как работает каждая из них. Для решения нужно хорошо разобраться в принципе работы обеих сверток, так как использовать reverse = читерить.]
    • Take a Ten Minute Walk неизвестно мин^[Нужно проверить предложенный маршрут (движение по сторонам света) на два условия: длительность (10 минут при минуте на одно перемещение) и совпадение начальной и конечной точки (вернуться туда, откуда пришёл). Тренирует работу со списками или использование Data.List.]
    • Highest Rank Number in an Array неизвестно мин^[Небольшая ката для практики бесточечного стиля и работы со стандартными модулями типа Data.List, Data.Ord и т.д. на ваш выбор.]
    • Duplicate Encoder неизвестно мин^[Простая ката, нацеленная на поиск дубликатов в массиве, что часто встречается в реальных задачах.]
    • Next bigger number with the same digits неизвестно мин^[Ката с очевидным брутфорс-решением. Попытайтесь найти наиболее оптимальный алгоритм, потому как если написать слишком просто, то все тесты пройти не успеет.]
    • Find The Parity Outlier неизвестно мин^[У FindOutlier множестово разных решений функциями из Data.List, или можно в лоб, сверткой, тренирует паттерн матчинг и функции как объекты первого класса.]
    • Most frequently used words in a text неизвестно мин^[Достаточно простая ката для 4 кью. Тренирует обработку строки с использованием Data.Char и Data.List.]
    • Fibonacci, Tribonacci and friends неизвестно мин^[Логическое продолжение каты Tribonacci, достаточно интересное и неординарное решение, тренирует мозги.]
    • Sortable Shapes неизвестно мин^[Это простая ката 6 кью (30 минут на решение достаточно) позволит Вам потренироваться в создании пользовательского типа данных. Основной результат - это понимание реализации каких классов нужно предусмотреть для созданного типа, чтобы данные могли отправляться в функцию sort.]
    • Recurrence relations неизвестно мин
    • Simple Fun #74: Growing Plant неизвестно мин
    • Coloured Triangles неизвестно мин
    • Digital Root неизвестно мин
    • Twice linear неизвестно мин
    • Playing with laziness неизвестно мин
    • Break camelCase неизвестно мин
    • CamelCase Method неизвестно мин
    • Speed Control неизвестно мин

Более глубокая теория

Обязательно

Необязательно

Задание 2: задачки по языку

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

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

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

  • консоль: сообщение пользователя вводится со стандартного ввода, ответ бота выводится в стандартный вывод (например, с помощью 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-тестами, которые бы покрывали главные use-case каждого модуля в приложении.
  7. Конфиги должны быть вынесены в отдельный файл с возможностью переписать локально какие-нибудь значения, но не изменять файлы из git-репозитория, чтобы случайно не запушить пароль или токен.
  8. Проект должен поддерживать логи разных уровней, все ключевые моменты должны грамотно логироваться, логи должны легко конфигурироваться хотя бы так, чтобы можно было включать/выключать логи до определенного уровня (например, показывать все от DEBUG и выше, или показывать все от WARN и выше).
  9. Для понятной архитектуры рекомендуем использовать Handle Pattern, так как мы применяем его в большинстве своих проектов.
  10. Чтобы добиться понятной архитектуры проекта, и получить тестируемый код, также можно применять различные техники (паттерны) описанные сообществом:
  11. Полезно почитать требования к проекту из задания 5 (код-ревью). На старте проекта необязательно забивать себе ими голову — потом успеете, но, все-таки, если знать их заранее, придется меньше исправлять.

Источники

Задание 4 Сайт (Пока не перенесено)

Задание 5 Ревью

не будет пока не сделаю задания 3 и 4

Задание 6 От себя

Что нужно будет сделать когда будет время