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

HTTP сервер. Реализовать сервер, частично реализующий протокол HTTP, в частности методы GET и HEAD, добиться того, что код проходит предоставленные функциональные тесты. Архитектуру выбрать на свое усмотрение, исходя из вариантов, рассмотренных на занятии. Провести нагрузочное тестирование с помощью ab или wrk.

Django tutorial. В рамках данного домашнего задания нужно пройти tutorial по Django, представленный на официальном сайте. Там нужно реализовать веб-сервис для боггинга и покрыть его тестами. В качестве дополнения требуется сделать проект production-ready, оформив по всем лучшим практикам и с соблюдением рекомендаций, обсуждаемых на занятии (12 factor apps).

ML model serving. ## Цель задания

Закрепить навыки работы с:

- библиотекой FastAPI для создания JSON API,
- защитой эндпоинтов с помощью базовой аутентификации,
- выполнением инференса с использованием onnxruntime,
- передачей данных в модель и возвратом предсказаний клиенту.

## Условие

У вас есть модель машинного обучения в формате ONNX (`diabetes_model.onnx`).

Она принимает на вход признаки пациента:

- `Pregnancies` (количество беременностей),
- `Glucose` (уровень глюкозы),
- `BMI` (индекс массы тела),
- `Age` (возраст).

На выходе модель возвращает вероятность наличия диабета:

- если вероятность > 0.5 → предсказание 1 (есть диабет)
- иначе 0 (нет диабета).

Используя FastAPI, необходимо разработать веб-сервис, который будет:

1. Принимать входные признаки через JSON API.
2. Передавать их в модель с помощью onnxruntime.
3. Возвращать предсказание в формате JSON.

Добавьте защиту: часть эндпоинтов (например, `/predict`) должна быть доступна только авторизованным пользователям через Basic Auth.

## Минимальные требования

Реализовать эндпоинт `/predict`, принимающий JSON вида:

```json
{
"Pregnancies": 2,
"Glucose": 140,
"BMI": 35.5,
"Age": 32
}
```

И возвращающий результат:

```json
{
"prediction": 1
}
```

Встроить базовую аутентификацию (по аналогии с примером на лекции).

Реализовать корневой эндпоинт `/`, который возвращает приветственное сообщение.

## Дополнительные задачи (по желанию)

Добавить валидацию входных данных через pydantic-модели.

Сделать логирование запросов и ответов.

Поднять сервис в Docker-контейнере.

Аутентификация. ### Цель

- Научиться выпускать и проверять JWT access-токены
- Ограничивать доступ к эндпоинтам по ролям (RBAC)
- Корректно обрабатывать статусы ошибок авторизации (401/403) и конфигурировать параметры безопасности через переменные окружения

### Исходные условия

У вас уже есть сервис FastAPI с эндпоинтом инференса модели diabetes_model.onnx (вход: Pregnancies, Glucose, BMI, Age; выход: вероятность/класс)

Базовая структура проекта и контейнеризация настроены

#### Аутентификация (JWT)

Регистрация пользователя: ввод логина/e-mail и пароля, хранение пароля только в виде хэша

Логин: при валидных учётных данных выдать JWT access-token

Токен должен включать как минимум:

- `sub` (идентификатор пользователя),
- `role` (роль пользователя),
- `exp` (время истечения),
- при необходимости `iat`/`nbf`.

Параметры безопасности задаются через переменные окружения:

- секрет
- алгоритм
- время жизни токена

Доступ к защищённым эндпоинтам только с заголовком `Authorization: Bearer <token>`

#### Авторизация (RBAC)

Ввести роли: минимум `user` и `admin`.

Правила доступа:

- Эндпоинт инференса (например, /predict) — доступен для user и admin.
- Админский эндпоинт (например, /admin/metrics или /admin/health) — только для admin.
- Реализовать проверку роли на уровне зависимостей/гейткиперов (концептуально: «пользователь должен иметь не ниже заданной роли»).

#### Поведение эндпоинтов

- /auth/register: создать пользователя; при конфликте — понятная ошибка.
- /auth/login: вернуть access-token и метаданные (например, время жизни).
- /me: вернуть профиль текущего пользователя по токену (id/username/role).
- /predict: принимать валидированный JSON с признаками; возвращать результат инференса (класс и, по возможности, вероятность/скор).
- /admin/...: один простой админ-эндпоинт (метрики, счётчик запросов, аптайм, версия сборки и т.п.).

#### Обработка ошибок и статусы

- Отсутствует/невалидный/просроченный токен → 401 Unauthorized.
- Роль недостаточна → 403 Forbidden.
- Сообщения должны быть информативными, но без утечки чувствительных деталей (не раскрывать внутренние структуры, секреты и т.д.).

#### Валидация и надёжность

- Валидация входных данных для инференса (тип, диапазоны, обязательность полей).
- Отдельные сообщения об ошибках валидации (400 Bad Request).
- Логирование ключевых событий: аутентификация, отказ в доступе, ошибки инференса.

#### Конфигурирование

- Все секреты/параметры безопасности — через окружение (секрет ключа, алгоритм, TTL).
- Возможность задать дефолтную роль при регистрации (например, user).
- (Опционально) предусмотреть «сидирование» админ-пользователя для локального запуска.

### Минимальные требования (на зачёт):

- Выпуск и верификация JWT access-токена.
- Защита эндпоинта инференса токеном.
- Встроенная RBAC с отдельным эндпоинтом, доступным только роли admin.
- Пароли хранятся в виде хэшей.
- Документация OpenAPI (/docs) открывается, защищённые эндпоинты помечены как требующие Bearer-токена.

### Дополнительно (по желанию, +)

- Refresh-токены и обновление access-токена.
- Чёрный список/ротация токенов (logout).
- Учёт попыток логина и «заморозка» аккаунта при брутфорсе.
- Ролевые матрицы доступа, расширяемые роли.
- Трассировка запросов и метрики (например, счётчик инференсов, среднее время ответа).
- Разграничение конфигов для prod/dev (разные секреты/TTL).

### Проверка/приёмка

- Без токена доступ к защищённым эндпоинтам невозможен (401).
- С токеном user доступен /predict, но недоступны админ-роуты (403).
- С токеном admin доступны и /predict, и админ-роуты.
- Ввод некорректных признаков даёт осмысленную 400-ошибку.
- Переменные окружения реально влияют на срок действия и подпись токена.
- Проект собирается и запускается в контейнере
- /docs отображает требования к авторизации

Логистическая регрессия. ## 1. Загрузка исходных данных

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

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

## 2. Потренируйтесь с базовыми операциями над массивами данных

- Найдите среднюю, медианную и стандартную температуру.
- Найдите минимальное и максимальное значение и соответствующие индексы.
- Найдите дни, когда температура была выше средней.
- Сколько дней было холоднее 18 градусов?
- Разделите данные на недели (по 7 дней) и найдите среднюю температуру каждой недели.
- Вычислите скользящее среднее (по 7 дней) и сравните со средними для каждой недели.

## 3. Освойте векторные операции над массивами

Загрузите новую порцию исходных данных.

### Задание 1: Общая выручка по каждому продукту

Условие:
Считается, что каждый день продаётся по фиксированному количеству 10 единиц каждого продукта. Найдите общую выручку за год по каждому продукту с помощью скалярного произведения.

### Задание 2: День наибольшей выручки

Условие:
Определите, в какой день года суммарная выручка по всем продуктам была максимальной. То есть:
∑ (цена[i][d] × количество[i][d]) по всем i продуктов, где количество — случайные продажи в диапазоне [5, 20].

### Задание 3: Сравнение “средневзвешенной цены”

Условие:
Вычислите средневзвешенную цену каждого продукта за год, используя веса — количество проданных единиц (рандомно от 5 до 15 штук в день).

OTUS-GPT. В данном домашнем задании предлагается выбрать на свое усмотрение одну из открытых генеративных моделей на HuggingFace, донастроить его под интересующий кейс и реализовать своего бота/агента или даже сеть/цепь агентов.

Задача:

- Зарегистрироваться на Huggingface.
- Получить API ключ.
- Получить доступ к каой-либо LLM модели.
- Развернуть модель локально.

Memcache loader. В этом домашнем задании необходимо переделать готовый однопоточный скрипт, загружающий логи трекера мобильных приложений в кластер memcache'ей. Скрипт нужно сделать конкурентным, воспользовавшись возможностями многопоточной/многопроцессной обработки, для того чтобы оптимизировать время загрузки данных.

Crawler. В этом домашнем задании предлагается реализовать асинхронный краулер для новостного сайта news.ycombinator.com. Предполагается, что краулер запускается каждые N секунд, парсит топ новостей, сохраняя каждую, а также сохраняет все ссылки из обсуждения конкретной новости.

Go memcache loader. В этом домашнем задании предлагается переписать конкурентный memcache loader, реализованный на Python в одном из прошлых заданий, на Golang, соблюдая при этом идиоматику языка и используя его возможности, рассмотренные на занятии.

Проектная работа . Тема Итоговой Проектной Работы (далее - ИПР) может являться свободной для выбора, но необходимой для согласования в чате ДЗ.

После выбора темы необходимо приступить к разработке ИПР, ориентируясь на следующие этапы жизненного цикла разработки Программного Обеспечения:

## 1. Сбор и анализ требований

Сформировать собственные требования к итоговому продукту, опционально - провести опрос среди коллег/студентов для определения потенциальной ценности для пользователей. Определить бизнес-задачу, которую будет решать проект. Итоговые требования целесообразно включить в презентацию ИПР.

## 2. Планирование

На данном этапе уточняются и формализуются ключевые цели ИПР, его границы и приоритеты. Уточняется список автоматизируемых процессов (развёртывание, миграции БД и т.д.). Выполняется первичная оценка сроков, необходимых ресурсов и интеграций. Также на данном этапе полезно проанализировать сторонние проекты, которые могут использоваться для решения подобных задач, выявить существующие практики в данном направлении и рассмотреть целесообразность их внедрения в ИПР. Результат — понятный рабочий план ИПР, с оформленными целями, приоритетами, объёмом работ и ориентировочными сроками. Итоговый рабочий план и цели целесообразно включить в презентацию ИПР.

## 3. Проектирование

На данном этапе определяется архитектура ИПР, происходит выбор используемых технологий, прорабатываются пользовательские сценарии/ программные интерфейсы и определяется, как будут работать ключевые модули. Важно учесть не только текущие требования, но и перспективу масштабирования, поддержки и безопасности (Контейнеризацию, возможности по авторизации/аутентификации, способы хранения чувствительной информации). Итоговые требования и технологии целесообразно включить в презентацию ИПР.

## 4. Разработка

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

## 5. Тестирование

На данном этапе важно проверять корректность написанного функционала, реализованной логики а также корректность передаваемых данных и способы обработки ошибок. Также необходимо предусмотреть соответствующие режимы вывода служебной информации для различных режимов логирования, что в будущем позволит обеспечить простоту и прозрачность поиска ошибок. Измеренное покрытие тестами а также отчёт о тестировании целесообразно включить в презентацию ИПР.

## 6. Развёртывание

На данном этапе необходимо развернуть проект в тестовой среде (в будущем пригодной к демонстрации на защите ИПР). Необходимо предусмотреть прозрачность и документальное обеспечение процесса развёртывания (как в автоматизированном так и в ручном режиме), с использованием технологий автоматизации процесса развёртывания, непрерывной интеграции и доставки (CI/CD), контейнеризации также с механизмами периодической проверки работоспособности ИПР. Краткую и обобщённую документацию по развёртыванию целесообразно включить в презентацию ИПР.

## 7. Эксплуатация и мониторинг

На данном этапе необходимо предусмотреть реализацию инструментов, имитирующих эксплуатацию ИПР - написать примеры запросов к сервису или примеры использования функций с отображением результатов работы. Данные инструменты необходимо реализовать с учётом возможности их демонстрации в процессе защиты ИПР. Также необходимо реализовать возможность демонстрации журналов логирования, отражающих эксплуатацию ИПР в режиме отладки (Debug). Инструменты, имитирующие эксплуатацию ИПР а также получаемые сообщения подсистемы логирования целесообразно использовать на этапе защиты ИПР.

## 8. Защита Итоговой Проектной Работы

На данном этапе необходимо предоставить ссылку на репозиторий с исходным кодом проекта а также подготовить презентацию к защите ИПР в 2-х вариантах, соответствующих следующим критериям:

### 8.1. Общая презентация ИПР

Презентация, рассчитанная на выступление приблизительной длительностью 5 минут (10-20 страниц) из расчёта 2-4 страницы на каждую минуту презентационного выступления.

### 8.2. Расширенная презентация ИПР

Презентация, рассчитанная на выступление приблизительной длительностью 10 минут (20-40 страниц) из расчёта 2-4 страницы на каждую минуту презентационного выступления.

На основе выполненной презентации необходимо подготовить выступление к защите ИПР, раскрывающее тему выполненного проекта а также выполнение перечисленных выше этапов разработки итогового проекта.

## Формат сдачи

Выбрана тема и закреплена.
Разработан проект и ссылка на репозиторий отправлена в "чат с преподавателем".
Разработана презентация в 2-х вариантах, в соответствии с критериями оценки.
Проект представлен на защиту.