Сервис по планированию задач

Список фичей:

1. Пользователь может добавлять, удалять, закрывать и заново открывать задачи
2. Названия задач должны быть уникальными для всех пользователей (удаленные не учитываются).
3. Пользователь может получить список всех задач любого другого пользователя, кроме удаленных.
4. Пользователь может закрывать, удалять и заново открывать только свои задачи
5. Задача проходит следующие состояния: CREATED <--> CLOSED -> DELETED. При этом задача в статусе CREATED не может сразу перейти в DELETED. Задача же в DELETED больше не может переходить ни в какое состояние.

В рамках задания DELETED можно трактовать как фактическое удаление элемента, а не выставление какого-либо статуса.

Веб-сервер принимает сообщения по придуманному нами протоколу - Simple Web Protocol.

Запросы и ответы состоят из одной строки.

Формат запроса: "USER COMMAND ARG"

Формат ответа: "RESULT ARG"

Описание формата:

1. USER — имя пользователя, который осуществляет действие.
2. COMMAND — команда. Варианты команд:
   1. CREATE_TASK MyTask — создать задачу с названием MyTask
   2. CLOSE_TASK MyTask — закрыть задачу MyTask
   3. DELETE_TASK MyTask — удалить задачу MyTask
   4. REOPEN_TASK MyTask — заново открыть задачу MyTask
   5. LIST_TASK USER — Получить список задач пользователя (в статусе CREATED и CLOSED)
   6. __DELETE_ALL — Удалить информацию о всех пользователях и их задачах. Используется в тестах, чтобы «чистить» данные между их выполнением. Формат ответа для этой команды не имеет значения, так как он нигде не валидируется.
3. ARG — аргумент запроса или ответа. Может отсутствовать. Например, в запросе на создание задачи VASYA CREATE_TASK CleanRoom — это CleanRoom. А в ответе TASKS [MyTask1, MyTask2] — [MyTask1, MyTask2].
4. RESULT — ответ сервера о совершении действия. Варианты ответов.
   1. CREATED — задача успешно создана
   2. DELETED — задача успешно удалена
   3. CLOSED — задача успешно закрыта
   4. REOPENED — задача успешно открыта заново
   5. TASKS [MyTask1, MyTask2] — список задач пользователя. Если задач нет, список пустой ([]). Задачи перечислены в порядке их создания.
   6. WRONG_FORMAT — Неверный формат запроса
   7. ACCESS_DENIED — Нет прав на совершение операции
   8. ERROR — Любая другая ошибка
5. Все команды, а также имена пользователей регистрозависимые. В названии задач и имен пользователей не может быть пробелов.
6. Запросы валидируются в следующем порядке: формат запроса, право на совершение операции, все остальные проверки. Если первая проверка не прошла, остальные не выполняются.

Примеры запросов и ответов:

1. VASYA CREATE_TASK CleanRoom
   1. CREATED
2. PETYA DELETE_TASK CleanRoom
   1. ACCESS_DENIED
3. PETYA CREATE_TASK Task1
   1. CREATED
4. PETYA CREATE_TASK Task2
   1. CREATED
5. VASYA LIST_TASK PETYA
   1. TASKS [Task1, Task2]
6. VASYA CREATE_TASK CleanRoom
   1. ERROR

В данном примере состояние сервиса сохраняется между запросами, поэтому PETYA DELETE_TASK CleanRoom возвращает ACCESS_DENIED.

Definition of Done

В ServerTest объявлены тест-кейсы, которые проверяют корректность вышеописанных фич. Необходимо дописать бизнес-функциональность таким образом, чтобы все тесты проходили.

Все данные храним в оперативной памяти. Concurrency-эффекты не учитываем, так как сервер обрабатывает запросы последовательно.

Spring, прочие фреймворки, вспомогательные библиотеки, а также Service Loader использовать нельзя. Применяем только то, что уже есть в проекте.

Важно:

Перед тем, как отправлять код на проверку убедитесь, что все тесты, объявленные в проекте (а также те, что вы написали самостоятельно), успешно проходят. Когда код принят на рассмотрение, никакие изменения вносить не допускается.

Критерии, по которым работа автоматически отклоняется:

1. Хотя бы один тест не выполнился успешно (билд «красный»).
2. Тесты, которые были написаны заранее, удалены/отмечены как disabled/закомментированы.
3. В pom.xml внесены любые изменения: на CI автоматически проверяется hash-сумма.

Для сборки проекта на CI используется Java 11. Чтобы убедиться в корректности написанного вами кода, локально также рекомендуется запускать проект на Java 11.

Исключением могут являться технические проблемы. Например, build на GitHub Actions «красный» из-за проблем на сервере. Но такие вещи решаются в индивидуальном порядке.

Дополнительные баллы

Учитывается общее оформление кода, архитектурное разделение компонентов, а также наличие Unit-тестов на отдельные части проекта.

Порядок сдачи

1. Форкаем репозиторий.
2. Создаем новую ветку от master.
3. Выполняем задание и пушим изменения.
4. Создаем Pull Request из своей feature-ветки в master исходного репозитория.
5. В комментарии оставляем ФИО и почту (тегаем @SimonHarmonicMinor)
6. Ждем результатов :)

Обратите внимание, что после того, как вы тегнули @SimonHarmonicMinor, вы в то же время оповестили нас о том, что выполнили задание. Если же к моменту проверки билд оказывается «красным», задание сразу же оценивается в 0 баллов. Поэтому перед тем, как уведомлять нас о сдаче работы, пожалуйста, проверьте, что билд собирается корректно. Создание Pull Request само по себе не является сигналом, пока вы не тегните @SimonHarmonicMinor.

В случае возникновения каких-либо вопросов, пишите на почту МТС Тета.