Впереди нас ждет новый семестр, а с ним и новое расписание. Как мы знаем, оно бывает не идеальным и может содержать некоторые "неудобства" для студентов и сотрудников. Например слишком большие окна или необходимость добежать из физкультурного комплекса до билбиотеки за 10 минут перемены.
Ваша задача - написать сервис, который будет искать такие неудачные места и выдавать информацию о них. Задание будет поделено на уровни, на каждом из которых вы будете создавать все более и более совершенную версию сервиса.
На первом уровне вам будет необходимо разработать сам метод поиска таких мест и обернуть его в api. Также тут нужно будет разобраться с упаковкой вашего сервиса в docker, чтобы его можно было удобно запускать через docker compose файл.
Требования:
- Методы поиска "неудобств" в расписание. Нужно сделать обработку 2-ух - 3-ех типов подобных "узких мест", тут больше не значит лучше.
- API для получения доступа к этим методам. Ручки должны принимать необязательный query параметр для фильтрации по названию группы / ФИО преподавателя, смотря кого этот метод исследует.
- Сборка в docker образ, загрузка его на публичный dockerhub, создание docker-compose файла.
Данные нужно уметь не только получать, но и хранить. На втором уровне вам предстоит сохранять результаты поиска "неудобств" в реляционную базу данных. Мы прекрасно понимаем, что в данном конкретном случае может быть сильно удобнее хранить информацию, используя формат jsonb (postgresql) или его аналоги в других субд, но в рамках тестового задания мы хотели бы увидеть ваши навыки работы с реляционными базами данных, так что ваша база данных должна находиться хотя-бы в первой нормальной форме.
Требования:
- В сервисе реализовать background работу, которая применяет разработанные вами методы к расписанию и сохраняет результаты работы в БД. Она должна запускаться при запуске сервиса, а также по определнному расписанию.
- Результаты по запросу теперь получаются из имеющейся у вас БД, а не собираются по новой.
- В качестве БД хотелось бы видеть СУБД серверного типа развертывания (не sqlite), в идеале - postgresql.
Явное приемущество подхода с хранением данных в БД - почти моментальный ответ сервера, а главный недостаток - неактуальность данных. На этом этапе вам предстоит вернуть возможность получать актуальной состояние, как на уровне 1, но с некоторым усложнением. Как вы могли заметить запрос без фильтра по названию может выполняться долго, а иногда и прям очень долго. За такое время клиент вполне может отвалиться по таймауту. На современных ml-ных хакатонах такая проблема встает особенно остро, ибо какое-нибудь видео ml может жевать чуть-ли не несколько минут. Для того, чтобы решить эту проблему, применяется следующий подход: клиент на запрос данных не ждет полной обработки, а сразу получает некий идентификатор запроса, с которым в последствии раз в разумный промежуток времени ходит в сервис. Сервис же в это время запускает на фоне выполнение этого запроса и на вопрос клиента отдает статусы этого запроса: сначала идет статус в процессе, потом уже готово, с самим ответом.
- Реализовать вышеописанный алгоритм.
При прочтении задания у вас мог возникнуть вопрос: "Откуда же брать расписание?". В целом, вы сами вправе выбирать источник данных, однако мы рекомендуем использовать api https://schedule-of.mirea.ru для получения расписания. Программисты на C# могут воспользоваться готовой библиотекой.
Если это задание показалась вам слишком простым и не позволяет в полной мере показать свео мастерство, то предлагаем вам несколько дополнительных заданий.
В этом доп задании вам предлагается модифицировать свой сервис, чтобы он хранил не только последнее состояние, но историю изменения расписаний со временем и позволял наблюдать за улучшениями.
В этом доп задании вам предлагается модифицировать процесс "долгих запросов", разработанный на уровне 3. Нужно сделать так, чтобы сервис мог одновременно обрабатывать только один запрос, а остальные становились в очередь на ожидание. Клиентам соответственно по id такого запроса будет отдаваться статус "в очереди". В случае получения двух и более одинаковых запросов следует отдавать им один идентификатор, чтобы не выполнять одну и ту же операцию дважды.