Domain terms (словарь предметной области)

Content (контент) — базовая единица просмотра, картинка или видео длиной до 5 минут.
Metadata (метаданные) — сопровождающая контент информация (дата/время публикации, источник, автор, язык, число пользовательских реакций, число комментариев и т.п.).
Feed (лента) — последовательность контентов, предназначенная для просмотра.

Задача

Напишите приложение на Java или/и KotlIn, которое с максимальной скоростью распознает и соберёт все мемы на немецком языке и вернёт их в качестве ленты контента, сопровождаемого метаданными, отсортированной по времени публикации от более свежих к более старым.

Термин «мемы» мы трактуем широко: это могут быть тематические картинки, комиксы, забавные видео, рисунки, производные от аниме и манги и т.п.

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

Настройка источников мемов должна быть достаточно гибкой, чтобы добавление новых можно было обеспечить редактированием конфигурационных файлов.

Предполагается, что лента отдаётся в REST-парадигме: endpoint GET /feed, возвращающий постраничный список контента для предпросмотра, и endpoint GET /feed/:contentID, возвращающий отдельные контенты с полными метаданными.

Приложение будет работать в Docker-контейнере, а значит в корне репозитория должен лежать Dockerfile и приложение должно запускаться по команде: docker run --rm -it $(docker build -q .)

Приложение должно соответствовать основным принципам 12-factor:
  • Писать логи в STDOUT без промежуточной буферизации
  • Конфигурироваться через environment-переменные
  • Не хранить состояние
  • Масштабироваться горизонтально

Под последним пунктом мы понимаем конфигурацию, когда приложение развёрнуто в кластере из нескольких хостов и запросы между ними распределяет балансировщик. Все хосты кластера получают одинаковый набор environment-переменных. Все нужные вашему приложению внешние сервисы (базы данных, кэши, объектные или файловые хранилища) также должны задаваться конфигурационными параметрами. Если что, то наш любимый стек — Redis, MongoDB и AWS S3.

Конкурсное задание должно сопровождаться файлом README с описанием сборки и запуска, пример конфигурации переменных среды можно положить рядом в файле .env.example

God-mode (AKA задачи со звёздочкой)

Если задание показалось вам слишком лёгким, вы можете добавить в него:
  • дополнительные языки: французский, испанский, итальянский, португальский, русский;
  • фронтенд для просмотра ленты;
  • сортировку ленты от более интересного контента к менее интересному (на основе метаданных);
  • противодействие rate-limiting на стороне серверов с мемами;
  • другие классные фишки на ваш выбор
Мы будем оценивать:
  • архитектурное решение;
  • качество кода;
  • производительность;
  • параллельную неблокирующую работу отдельных компонентов приложения;
  • потребление ресурсов (CPU, память, внешние хранилища)
Следующие критерии также положительно повлияют на оценку жюри:
  • наличие в git-репо актуальной истории коммитов;
  • healthcheck и readiness check;
  • endpoint с Prometheus-метриками, чем подробнее — тем лучше;
  • юнит-тесты;
  • функциональные тесты Docker-образа;
  • OpenAPI-документация;
  • подробное руководство по эксплуатации (runbook).
В процессе оценки мы запустим каждое прошедшее предварительный отбор приложение на один час в трёх экземплярах. Соберём метрики загрузки CPU, памяти и сети, а также оценим количество и качество уникального полученного контента.

Желаем удачи!
FunCode Java/Kotlin challenge
Конкурсное задание