День открытых дверей
Всё о курсе «Разработчик Python»

Анализатор логов. Жил-был чудный веб-интерфейс, и все у него было хорошо: в него входили пользователи, что-то там кликали, переходили по ссылкам, получали результат. Но со временем некоторые его странички стали тупить и долго грузиться. Менеджеры часто жалуются, мол, «вот тут список долго грузился» или «интерфейсик тупит, поиск не работает». Но так трудно отделить те случаи, где проблемы на их стороне, а где действительно виноват веб-сервис. В логи reverse proxy перед интерфейсом (nginx) добавили время запроса (`$request_time` в `nginx`, http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format). Теперь можно распарсить логи и провести первичный анализ, выявив подозрительные URL'ы.

Про логи:

* Семпл лога: `nginx-access-ui.log-20170630.gz`
* Шаблон названия логов: `nginx-access-ui.log-YYYYMMDD.gz`
* Так вышло, что логи могут быть и plain (т. е. «сырые», без сжатия) и gzip
* Лог ротируется раз в день
* Опять же так вышло, что логи интерфейса лежат в папке с логами других сервисов

Про отчет:

* count — сколько раз встречается URL, абсолютное значение
* count_perc — сколько раз встречается URL, в процентах относительно общего числа запросов
* time_sum — суммарный $request_time для данного URL'а, абсолютное значение
* time_perc — суммарный $request_time для данного URL'а, в процентах относительно общего $request_time всех запросов
* time_avg — средний $request_time для данного URL'а
* time_max — максимальный $request_time для данного URL'а
* time_med — медиана $request_time для данного URL'а


*Задание*: реализовать анализатор логов `log_analyzer.py`.

__Основная функциональность__:

1. Скрипт обрабатывает при запуске последний (со самой свежей датой в имени, не по mtime файла!) лог в `LOG_DIR`, в результате работы должен получится отчет как в `report-2017.06.30.html` (для корректной работы нужно будет найти и принести себе на диск `jquery.tablesorter.min.js`). То есть скрипт читает лог, парсит нужные поля, считает необходимую статистику по url'ам и рендерит шаблон `report.html` (в шаблоне нужно только подставить `$table_json`) в `report-YYYY.MM.DD.html`, где дата в названии соответствует дате обработанного файла логов. Ситуация, что логов на обработку нет, возможна, это не должно являться ошибкой.
2. Готовые отчеты лежат в `REPORT_DIR`. В отчет попадает `REPORT_SIZE` URL'ов с наибольшим суммарным временем обработки (`time_sum`).
3. Скрипту должно быть возможно указать считать конфиг из другого файла, передав его путь через `--config`. У пути конфига должно быть дефолтное значение. Если файл не существует или непарсится, нужно выходить с ошибкой.
4. В переменной `config` находится конфиг по умолчанию. В конфиге, считанном из файла, могут быть переопределены переменные дефолтного конфига (некоторые, все или никакие, т. е. файл может быть пустой), и они имеют более высокий приоритет по сравнению с дефолтным конфигом. Таким образом, результирующий конфиг получается слиянием конфига из файла и дефолтного, с приоритетом конфига из файла. Ситуацию, когда конфига на диске не оказалось, нужно исключить.
5. Использовать конфиг как глобальную переменную запрещено, т. е. обращаться в своем функционале к нему так, как будто он глобальный, нельзя. Нужно передавать как аргумент.
6. Использовать сторонние библиотеки для реализации основного функционала запрещено, за исключением `structlog`.
7. (задание со «звездочкой») Если скрипт удачно обработал, то работу не переделывает при повторном запуске.

__Мониторинг__:

1. Скрипт должен писать структурированные логи в JSON через [structlog](https://www.structlog.org/en/stable/why.html) (плюс рекомендуется познакомиться с утилитой [jq](https://jqlang.github.io/jq/)). Допускается только использование уровней `debug`, `info`, `error`. Путь до лог-файла указывается в конфиге, если не указан, лог должен писаться в stdout.
2. Все возможные «неожиданные» ошибки должны попадать в лог вместе с трейсбеком. Имеются в виду ошибки, непредусмотренные логикой работы, приводящие к остановке обработки и выходу: баги, нажатие Ctrl+C, кончилось место на диске и т. п.
3. (задание со «звездочкой») Должно быть предусмотрено оповещение о том, что большую часть анализируемого лога не удалось распарсить (например, потому что сменился формат логирования). Для этого нужно задаться относительным (в долях/процентах) порогом ошибок парсинга и при его превышании писать в лог, затем выходить.

__Тестирование__:

На скрипт должны быть написаны тесты с использованием библиотеки `pytest`. Тестируемые кейсы и структура тестов определяется самостоятельно (без фанатизма, достаточно каких-нибудь разумных тестов, занятия про тестирование ждут нас впереди).

__Оформление__:

1. Задать проекту типовую структуру (можно ориентироваться https://realpython.com/python-application-layouts/ или свои любимые крупные проекты на github).
2. Настроить pre-commit хуки, как минимум линтер, black, isort, mypy и poetry.
3. Настроить CI со стандартными проверками: линтер, black, isort, mypy — и запуском тестов.
4. Написать README.md с его кратким описанием и примерами запуска.
5. Настройку и управление зависимостями провести через poetry и pyproject.toml (ну и, возможно, setup.cfg).
6. Подготовить Makefile для удобного запуска линтовки, тестов (и тестового покрытия) и самого приложения.
7. (задание со «звездочкой») Подготовить Dockerfile, собранный образ должен уметь по подключенным через volume входным данным (директория с логами, конфиг) выдавать в этот же или другой volume отчет.


*Цель задания*: получить (прокачать) навык создания полноценного проекта. То есть проекта, наполненнго адекватным кодом, который удобно расширять и поддерживать, протестированного, пригодного для мониторинга, имеющего стандартную структуру, минимальное описание и настроенный CI. Совпадение всех чисел с приведенным примером отчета целью не является (лишь бы похожи были =)



__Распространенные проблемы__:

* Не стоит делать свои кастомные классы ошибок, это иногда (!) имеет смысл для библиотек, но не для задач подобного рода.
* Ограничьтесь уровнями логирования DEBUG, INFO и ERROR: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
* Не выходите через sys.exit не из main. Это затрудняет тестирование и переиспользование кода.
* Чтобы отрендерить шаблон, не надо итерироваться по всем его строкам и искать место замены, можно воспользоваться, например, https://docs.python.org/3/library/string.html#string.Template.safe_substitute.
* Функцию, которая будет парсить лог, желательно сделать генератором и передать в качестве аргумента функции создателю отчета.
* Не забывайте про кодировки, когда читаете лог и пишете отчет.
* Из функции, которая будет искать последний лог, удобно возвращать namedtuple/dataclass с указанием пути до него, распаршенной через datetime даты из имени файла и расширением, например.
* Распаршенная дата из имени лог-файла пригодится, чтобы составить путь до отчета, это можно сделать «за один присест», не нужно проходится по всем файлам и что-то искать.
* Протестируйте функцию поиска лога, она не должна возвращать .bz2 файлы и т. п. Этого можно добиться правильной регуляркой.
* Найти самый свежий лог можно за один проход по файлам, без использования glob, сортировки и т. п.
* Нужный открыватель лога (open/gzip.open) перед парсингом можно выбрать через тернарный оператор.
* Проверка на превышение процента ошибок при парсинге выполняется один раз, в конце чтения файла, а не на каждую строчку/ошибку.
* Коммитить толстые бинари (например nginx-access-ui.log-20170630.gz) в git не стоит, он для исходного кода, в основном.

__Полезные ссылки__:

* https://docs.python.org/3/library/statistics.html
* https://jesseduffield.com/Beginners-Guide-To-Abstraction/
* https://melevir.medium.com/короче-говоря-принцип-единой-ответсвенности-92840ac55baa
* https://melevir.medium.com/python-стиль-кода-1af07092836e
* https://melevir.medium.com/дизайн-функций-a63bc9588e11
* https://www.youtube.com/watch?v=o9pEzgHorH0 Stop Writing Classes
* https://leontrolski.github.io/mostly-pointless.html
* https://blog.guilatrova.dev/handling-exceptions-in-python-like-a-pro/
* https://mitelman.engineering/blog/python-best-practice/automating-python-best-practices-for-a-new-project/
* https://medium.com/@vanflymen/blazing-fast-ci-with-github-actions-poetry-black-and-pytest-9e74299dd4a5

## Deadline
Задание желательно сдать в течение недели. Код, отправленный на ревью в это время, рассматривается в первом приоритете. Нарушение делайна не карается. Пытаться сдать ДЗ можно до конца курса. Код, отправленный с опозданием, когда по плану предполагается работа над более актуальным ДЗ, будет рассматриваться в более низком приоритете без гарантий по высокой скорости проверки.

## Обратная связь
Cтудент коммитит все необходимое в свой github/gitlab репозитарий. Далее необходимо зайти в ЛК, найти занятие, ДЗ по которому выполнялось, нажать “Чат с преподавателем” и отправить ссылку. После этого ревью и общение на тему ДЗ будет происходить в рамках этого чата.


### Материалы для выполнения ДЗ:

[https://gitlab.com/otus.private/python-advanced-homeworks/-/tree/4ba19c1e0b2be7609f098c2c3461de30878a5aab/homework_01_log_analyzer](https://gitlab.com/otus.private/python-advanced-homeworks/-/tree/4ba19c1e0b2be7609f098c2c3461de30878a5aab/homework_01_log_analyzer)

Тренажер по аннотации типов. *Задание*: пройти максимальное количество упражнений на аннотацию типов в тренажере https://python-type-challenges.zeabur.app.

*Цель задания*: набить руку на стандартных (и не очень) кейсах по типизации, попробовать на практике различные возможности языка по аннотации.

__Оформление__:
Так как на сайте тренажера нет никакого ЛК, то предлагается решенные задания сохранить в свой репозиторий (по модулю на каждое задание), настроить CI, который будет проверять аннотации с помощью mypy или pyright, а также обеспечить условия, при которых в локальном репозитории по команде `make typing` в контейнере запускалась бы аналогичная проверка типов.

## Deadline
Задание желательно сдать в течение недели. Код, отправленный на ревью в это время, рассматривается в первом приоритете. Нарушение делайна не карается. Пытаться сдать ДЗ можно до конца курса. Код, отправленный с опозданием, когда по плану предполагается работа над более актуальным ДЗ, будет рассматриваться в более низком приоритете без гарантий по высокой скорости проверки.

## Обратная связь
Cтудент коммитит все необходимое в свой github/gitlab-репозиторий. Далее необходимо зайти в ЛК, найти занятие, ДЗ по которому выполнялось, нажать «Чат с преподавателем» и отправить ссылку. После этого ревью и общение на тему ДЗ будет происходить в рамках этого чата.

API скоринга. *Задание*: реализовать декларативный язык описания и систему валидации запросов к HTTP API сервиса скоринга. Шаблон уже есть в api.py, тесты в test.py, функционал подсчета скора в scoring.py. API необычно тем, что пользователи дергают методы POST запросами. Чтобы получить результат, пользователь отправляет в POST запросе валидный JSON определенного формата на локейшн /method.

*Disclaimer*: данное API ни в коей мере не являет собой best practice реализации подобных вещей и намеренно сделано «странно» в некоторых местах.

*Цель задания*: применить знания по ООП на практике, получить навык разработки нетривиальных объектно-ориентированных программ. Это даст возможность быстрее и лучше понимать сторонний код (библиотеки или сервисы часто бывают написаны с примененем ООП парадигмы или ее элементов), а также допускать меньше ошибок при проектировании сложных систем.

### Структура запроса

```json
{
"account": "<имя компании партнера>",
"login": "<имя пользователя>",
"method": "<имя метода>",
"token": "<аутентификационный токен>",
"arguments": {<словарь с аргументами вызываемого метода>}
}
```

* account — строка, опционально, может быть пустым
* login — строка, обязательно, может быть пустым
* method — строка, обязательно, может быть пустым
* token — строка, обязательно, может быть пустым
* arguments — словарь (объект в терминах json), обязательно, может быть пустым

### Валидация

Запрос валиден, если валидны все поля по отдельности

#### Структура ответа

OK:

```json
{"code": <числовой код>, "response": {<ответ вызываемого метода>}}
```

Ошибка:

```json
{"code": <числовой код>, "error": {<сообщение об ошибке>}}
```

### Аутентификация:

Смотри `check_auth` в шаблоне. В случае если не пройдена, нужно возвращать

```json
{"code": 403, "error": "Forbidden"}
```

## Методы

### online_score

__Аргументы__:

* phone — строка или число, длиной 11, начинается с 7, опционально, может быть пустым
* email — строка, в которой есть @, опционально, может быть пустым
* first_name — строка, опционально, может быть пустым
* last_name — строка, опционально, может быть пустым
* birthday — дата в формате DD.MM.YYYY, с которой прошло не больше 70 лет, опционально, может быть пустым
* gender — число 0, 1 или 2, опционально, может быть пустым

__Валидация аргументов__

Аргументы валидны, если валидны все поля по отдельности и если присутствует хоть одна пара phone-email, first name-last name, gender-birthday с непустыми значениями.

__Контекст__

В словарь контекста должна прописываться запись "has" — список полей, которые были не пустые для данного запроса

__Ответ__

В ответ выдается число, полученное вызовом функции `get_score` (см. scoring.py). Но если пользователь админ (см. `check_auth`), то нужно всегда отдавать 42

```json
{
"score": <число>
}
```

Или если запрос пришел от валидного пользователя admin

```json
{
"score": 42
}
```

Или если произошла ошибка валидации

```json
{
"code": 422,
"error": "<сообщение о том, какое поле(я) невалидно(ы) и как именно>"
}
```

__Пример запроса__:

```sh
curl -X POST -H "Content-Type: application/json" -d '{"account": "horns&hoofs", "login": "h&f", "method": "online_score", "token": "55cc9ce545bcd144300fe9efc28e65d415b923ebb6be1e19d2750a2c03e80dd209a27954dca045e5bb12418e7d89b6d718a9e35af34e14e1d5bcd5a08f21fc95", "arguments": {"phone": "79175002040", "email": "stupnikov@otus.ru", "first_name": "Стансилав", "last_name": "Ступников", "birthday": "01.01.1990", "gender": 1}}' http://127.0.0.1:8080/method/
```

__Пример ответа__:

```json
{
"code": 200,
"response": {
"score": 5.0
}
}
}
```

### clients_interests

__Аргументы__:

* client_ids — массив чисел, обязательно, не пустое
* date — дата в формате DD.MM.YYYY, опционально, может быть пустым

__Валидация аругементов__:

Аргументы валидны, если валидны все поля по отдельности.

__Контекст__:

В словарь контекста должна прописываться запись "nclients" — количество id'шников, переданных в запрос

В ответ выдается словарь `<id клиента>:<список интересов>`. Список генерировать вызовом функции `get_interests` (см. scoring.py).

```json
{
"client_id1": ["interest1", "interest2", ...],
"client_id2": [...],
"client_idN": [...],
}
```

Или если произошла ошибка валидации

```json
{
"code": 422,
"error": "<сообщение о том, какое поле(я) невалидно(ы) и как именно>"
}
```

__Пример запроса__:

```sh
$ curl -X POST -H "Content-Type: application/json" -d '{"account": "horns&hoofs", "login": "admin", "method": "clients_interests", "token": "d3573aff1555cd67dccf21b95fe8c4dc8732f33fd4e32461b7fe6a71d83c947688515e36774c00fb630b039fe2223c991f045f13f24091386050205c324687a0", "arguments": {"client_ids": [1,2,3,4], "date": "20.07.2017"}}' http://127.0.0.1:8080/method/
```

__Пример ответа__:

```json
{
"code": 200,
"response": {
"1": ["books", "hi-tech"],
"2": ["pets", "tv"],
"3": ["travel", "music"],
"4": ["cinema", "geek"]
}
}
```

### Логирование

1. Скрипт должен писать логи через библиотеку logging в формате `'[%(asctime)s] %(levelname)s %(message)s'` c датой в виде `'%Y.%m.%d %H:%M:%S'`. Допускается только использование уровней `info`, `error` и `exception`. Путь до лог-файла указывается в конфиге, если не указан, лог должен писаться в stdout.

## Распространенные проблемы

* Суть ДЗ в том, чтобы объявить поля один раз и не дублировать больше в init или еще где-либо. Это, например (но не обязательно именно так), можно сделать с помощью метакласса, который при создании класса все Field соберет в массив, по которому можно будет итерироваться и валидировать.

## Deadline
Задание нужно сдать через неделю. То есть ДЗ, выданное в понедельник, нужно сдать до следующего занятия в понедельник. Код, отправленный на ревью в это время, рассматривается в первом приоритете. Нарушение делайна (пока) не карается, пытаться сдать ДЗ можно до конца курсы. Но код, отправленный с опозданием, когда по плану предполагается работа над более актуальным ДЗ, будет рассматриваться в более низком приоритете без гарантий по высокой скорости проверки.

## Обратная связь
Cтудент коммитит все необходимое в свой github/gitlab репозитарий. Далее необходимо зайти в ЛК, найти занятие, ДЗ по которому выполнялось, нажать “Чат с преподавателем” и отправить ссылку. После этого ревью и общение на тему ДЗ будет происходить в рамках этого чата.


### Материалы для выполнения ДЗ:

[https://gitlab.com/otus.private/python-advanced-homeworks/-/tree/9a7c6a1536f2ea81cdb4a6068a62f65938e43b9d/api_scoring](https://gitlab.com/otus.private/python-advanced-homeworks/-/tree/9a7c6a1536f2ea81cdb4a6068a62f65938e43b9d/api_scoring)

Тестирование. *Задание*: протестировать HTTP API сервиса скоринга. Шаблон уже есть в test.py, само API реализовывалось в прошлой части ДЗ. Тесты, выданные ранее, можно считать функциональными и уже готовыми.
1. Необходимо разработать модульные (unit) тесты на основной функционал. Разрешается пользоваться любым тестовым фреймворком: unittest, nosetests, pytest.
2. Обязательно необходимо реализовать через декоратор функционал запуска кейса с разными тест-векторами (либо, в качестве альтернативы, сделать то же самое через фикстуры в pytest). Если берете готовый cases, то его надо допилить так, чтобы при падении теста было ясно, какой кейс упал.

```
@cases([
{"account": "horns&hoofs", "login": "h&f", "method": "online_score", "token": "", "arguments": {}},
{"account": "horns&hoofs", "login": "h&f", "method": "online_score", "token": "sdd", "arguments": {}},
{"account": "horns&hoofs", "login": "admin", "method": "online_score", "token": "", "arguments": {}},
])
def test_bad_auth(self, request):
...
```

3. Store, который был захардкожен в None, наконец обретает смысл! Нужно реализовать в store.py общение с любым клиент-серверным key-value хранилищем (Tarantool, Memcached, Redis, etc.) согласно интерфейсу, заданному в обновленном scoring.py. Обращение к хранилищу не должно падать из-за разорванного соединения (т.е. store должен пытаться переподключаться N раз, прежде чем сдаться) и запросы не должны залипать (нужно использовать timeout'ы, где возможно).
* У store есть отдельно `get` и `cache_get`. В реальной системе, аналогом которой является API из ДЗ, есть отдельный кеш и отдельный key-value storage. Методы названы по-разному, чтобы показать, что есть разница. В данном случае внутри можно реализовать это и как хождение в одно и тоже хранилище. Важно то, как это будет протестировано с учетом разных требований для разных функций. Обратите внимание, функции `get_score` не важна доступность store'а, она использует его как кэш и, следовательно, должна работать, даже если store сгорел в верхних слоях атмосферы. `get_interests` использует store как персистентное хранилище и, если со store'ом что-то случилось, может отдавать только ошибки.
4. (задание со «звездочкой») Добавить интеграционные тесты нового функционала с реальным хранилищем.
5. Структура тестов: https://realpython.com/python-testing/#writing-integration-tests

*Цель задания*: применить знания по тестированию, полученные на занятии. В результате получится прокачать навык дизайна тест-кейсов, разработки модульных и функциональных тестов, создания mock'ов.


## Deadline
Задание нужно сдать через неделю. То есть ДЗ, выданное в понедельник, нужно сдать до следующего занятия в понедельник. Код, отправленный на ревью в это время, рассматривается в первом приоритете. Нарушение делайна (пока) не карается, пытаться сдать ДЗ можно до конца курса. Но код, отправленный с опозданием, когда по плану предполагается работа над более актуальным ДЗ, будет рассматриваться в более низком приоритете без гарантий по высокой скорости проверки.

## Обратная связь
Cтудент коммитит все необходимое в свой github/gitlab репозитарий. Далее необходимо зайти в ЛК, найти занятие, ДЗ по которому выполнялось, нажать «Чат с преподавателем» и отправить ссылку. После этого ревью и общение на тему ДЗ будет происходить в рамках этого чата.

#### Материалы для выполнения ДЗ:
[https://gitlab.com/otus.private/python-advanced-homeworks/-/tree/a67555a6bb0cbbc7a05d3b6d5f05f5c7d777446e/scoring_api_tests](https://gitlab.com/otus.private/python-advanced-homeworks/-/tree/a67555a6bb0cbbc7a05d3b6d5f05f5c7d777446e/scoring_api_tests)

Чистый склад. На занятии рассматривались части приложения по управлению товарами на некоем складе. В домашнем задании предлагается расширить реализацию, добавив новые доменные объекты, репозитории, доработать unit of work. Все это необходимо сделать соблюдая принципы и подходы чистой архитектуры. Естественно реализация должна быть протестирована.