👣 Тестовое задание для GoLang-разработчика

Описание задания
Необходимо разработать приложение, предоставляющее HTTP API для получения данных о парковках такси в г. Москва. Данные необходимо брать с этой страницы ("Актуальная версия").

Описание необходимого функционала
Приложение должно реализовывать:

▪Функционал загрузки данных из файла (локального и/или по ссылке) в хранилище данных (данные на источнике могут как удаляться, так и добавляться);

▪Обслуживание HTTP запросов к API-endpoints, которые реализуют поиск по хранимым данным;
Обслуживание HTTP запросов к роуту, возвращающему метрические данные (в формате prometheus) работы приложения.

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

Методы HTTP API должны возвращать ответ в формате json. Время обработки одного запроса к HTTP API (не загрузка данных в хранилище) - не более 2 мс. до первого байта HTTP ответа (TTFB). Проектирование самих методов API - на ваше усмотрение (минимально необходимый функционал - это поиск по global_id, id и mode).

Метрические данные должны включать в себя как минимум следующие метрики:

Общее количество обработанных запросов к API-endpoints;
Количество ошибок обработки HTTP запросов к API-endpoints (плюсом будет "разведение" по различным кодам ответов);
Данные по времени обработки HTTP запросов к API-endpoint;
Дополнительные метрики, на ваше усмотрение.

Требования к реализации

▪В качестве хранилища данных необходимо использовать Redis;
▪Все функции (экспортируемые и не экспортируемые) должны сопровождаться понятным комментарием (если возможно - на английском языке);
▪Не стоит излишне сокращать имена переменных и констант - код пишется для людей, и он должен быть максимально простым и понятным;
▪Можно использовать любые сторонние пакеты, но не использовать какой-либо фреймворк;
▪Весь ключевой функционал должен быть зафиксирован unit-тестами;
▪После завершения работы над заданием необходимо написать сопроводительную документацию по работе с приложением в файле README.md в корне репозитория;
▪Конфигурация параметров подключения к хранилищу данных должна иметь возможность управляться как флагами запуска, так и переменными окружения. Возможности конфигурирования должны быть описаны в файле README.md вашего репозитория.

Плюсами будут являться
▪Настройка CI (силами GitHub actions, TravisCI, etc) выполняющая запуск тестов и сборки на каждый коммит;
▪Автоматическая сборка Docker-образа с приложением;
▪Интуитивно-понятное разбитие коммитов - одной конкретной задаче - один коммит или PR (её правки - отдельный коммит или PR);
Написание всех текстов коммитов - на английском языке.

@Golang_google

👣 Задание на разработку демона, осуществляющего "Системный мониторинг"

Общее описание

Демон - программа, собирающая информацию о системе, на которой запущена, и отправляющая её своим клиентам по GRPC.

Архитектура
▪GRPC сервер;
▪допускается использование временных (/tmp) файлов;
▪статистика хранится в памяти, долговременное хранение не предусмотрено.

Требования
Необходимо каждые N секунд выдавать информацию, усредненную за последние M секунд.

Например, N = 5с, а M = 15с, тогда демон "молчит" первые 15 секунд, затем выдает снапшот за 0-15с; через 5с (в 20с) выдает снапшот за 5-20с; через 5с (в 25с) выдает снапшот за 10-25с и т.д.

N и M указывает клиент в запросе на получение статистики.

Что необходимо собирать:

▪Средняя загрузка системы (load average).

▪Средняя загрузка CPU (%user_mode, %system_mode, %idle).

▪Загрузка дисков:

-tps (transfers per second);
-KB/s (kilobytes (read+write) per second);

▪Информация о дисках по каждой файловой системе:

-использовано мегабайт, % от доступного количества;
-использовано inode, % от доступного количества.
▪Top talkers по сети:

- по протоколам: protocol (TCP, UDP, ICMP, etc), bytes, % от sum(bytes) за последние M), сортируем по убыванию процента;
-по трафику: source ip:port, destination ip:port, protocol, bytes per second (bps), сортируем по убыванию bps.

▪Статистика по сетевым соединениям:

- слушающие TCP & UDP сокеты: command, pid, user, protocol, port;
-количество TCP соединений, находящихся в разных состояниях (ESTAB, FIN_WAIT, SYN_RCV и пр.).

Разрешено использовать только стандартную библиотеку языка Go!
Команды, которые могут пригодиться:

$ top -b -n1
$ df -k
$ df -i
$ iostat -d -k
$ cat /proc/net/dev
$ sudo netstat -lntup
$ ss -ta
$ tcpdump -ntq -i any -P inout -l
$ tcpdump -nt -i any -P inout -ttt -l
Статистика представляет собой объекты, описанные в формате Protobuf.

Информацию необходимо выдавать всем подключенным по GRPC клиентам с использованием однонаправленного потока.

Выдавать "снапшот" системы можно как отдельными сообщениями, так и одним жирным объектом.

Сбор информации, её парсинг и пр. должен осуществляться как можно более конкурентно.

Конфигурация

▪Через аргументы командной строки можно указать, на каком порту стартует сервер.
▪Через файл можно указать, какие из подсистем сбора включены/выключены.
Тестирование

Юнит-тесты
▪по возможности мок интерфейсов и проверка вызовов конкретных методов;
▪тесты вспомогательных функций и пр.

Интеграционные тесты

▪потестировать факт потока статистики, можно без конкретных цифр;
▪можно посоздавать файлы, пооткрывать сокеты и посмотреть на изменение снапшота.

Клиент

Необходимо реализовать простой клиент, который в реальном времени получает и выводит в STDOUT статистику по одному из пунктов (например, сетевую информацию) в читаемом формате (например, в виде таблицы).

@golang_interview

👣 Тестовое задание для разработчика на Go

У сети ресторанов доставки есть множество точек, на которых готовятся заказы для клиентов. Каждый клиент хочет вместе с заказом получить чек, содержащий детальную информацию о заказе.

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

1. Сервис получает информацию о новом заказе, создаёт в БД чеки для всех принтеров точки указанной в заказе и ставит асинхронные задачи на генерацию PDF-файлов для этих чеков. Если у точки нет ни одного принтера - возвращает ошибку. Если чеки для данного заказа уже были созданы - возвращает ошибку.

2. Worker'ы с помощью wkhtmltopdf генерируют PDF-файл из HTML-шаблона. Имя файла должно иметь следущий вид <ID заказа>_<тип чека>.pdf (123456_client.pdf). Файлы должны хранится в папке media/pdf в корне проекта.

3. Приложение опрашивает сервис на наличие новых чеков. Опрос происходит по следующему пути: сначала запрашивается список чеков которые уже сгенерированы для конкретного принтера, после скачивается PDF-файл для каждого чека и отправляется на печать.

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

Сервис должен быть написан на GO
База данных - PostgreSQL
Все инфраструктурные вещи необходимые для сервиса (PostgreSQL, Redis, wkhtmltopdf) запускать в docker с помощью docker-compose, сам проект не нужно оборачивать в docker

Помимо API, должна быть админка для обеих моделей, с возможностью фильтровать чеки по принтеру, типу и статусу

📌 Модели

▪Принтер (Printer). Каждый принтер печатает только свой тип чеков. Поле api_key принимает уникальные значения, по нему однозначно определяется принтер. Для этой модели должны быть fixtures (принтеры для обоих типов чеков для нескольких точек).

Поле Тип Значение Описание
name CharField название принтера
api_key CharField ключ доступа к API
check_type CharField kitchen|client тип чека которые печатает принтер
point_id IntegerField точка к которой привязан принтер

▪Чек (Check). Информация о заказе для каждого чека хранится в JSON, нет необходимости делать отдельные модели.

Поле Тип Значение Описание
printer_id ForeignKey принтер
type CharField kitchen|client тип чека
order JSONField информация о заказе
status CharField new|rendered|printed статус чека
pdf_file FileField ссылка на созданный PDF-файл

API
Добавить описание доступных методов в файл api.yml (swagger-спецификация).

@golang_interview