Семестровый проект

О регистрации проекта

Семестровый проект — это публичный git-репозиторий с кодом на Python3, содержащий всё необходимое для сборки и деплоймента некоторого приложения (кроме секретных ключей, конечно ☺).

0. Все нижеперечисленные стадии сборки проекта должны воспроизводиться любым желающим (например, мной!)
1. В котором есть более одного участника
   • Я могу посмотреть статистику участия (оба предложенных ниже измерения неидеальны, я это знаю)
     • по количество коммитов
     • по объёму кода
   • В проекте принята и соблюдается некоторая единая дисциплина оформления коммитов

2. в котором flake8 (или pylint), а также pydocstyle не находят ошибок

   • Некоторые требования анализаторов можно запрещать в config-файле

   • Вспомогательные функции и классы, подразумевающие повторное использование, должны быть аннотированы (в частности, если ваш проект — это модуль python, т. е. его пользователь — программист, все доступные ему функции/классы должны быть по возможности аннотированы)

   • Наличие docstrings обязательно. Если ваша дисциплина программирования использует их для технических целей (например, там хранятся обрабатываемые данные), и это не соответствует pep-0257, ошибки pydocstyle игнорируются

3. В котором есть немножко тестов (с использованием любого тест-фреймворка, годится встроенный питоний)
   • Должны быть покрыты модульными тестами в первую очередь функции и классы, не использующие интерактивные возможности (т. е не GUI, не сетевое взаимодействие и т. п.)

   • Таких функций/классов должно быть не менее 5

4. В котором есть немножко документации

   • Описание проекта в README (в случае GitHub — README.md) и постановка задачи на GH

     • В случае GUI — проект интерфейса
       • не обязательно полностью совпадающий с тем, что получилось
       • достаточно детальный, чтобы было понятно, какой блок виджетов из чего состоит и за что отвечает
       • можно в виде картинки с исходниками из какого-то диаграммера, а можно и просто фоточки нарисованного от руки

   • Программной (с использованием sphinx)

   • Пользовательской (либо sphinx, либо прямо на GH)

5. В котором есть немножко локализации с использованием babel

   • обратите внимание на то, что, например, -.mo файлы нельзя хранить, но их надо сгенерировать и положить в дистрибутив вашего проекта (например, в wheel, как в лекциях)

6. В котором есть немножко автоматизации сборки / деплоймента.
   • В частности, в репозитории не хранятся никакие генераты (в том числе дистрибутивные)

   • Каждый дистрибутивный генерат (переводы, документация, иное) должны побираться одной командой средства автоматизации (предлагается doit)

     • Тесты и тесты стиля тоже надо оформить в виде автоматизируемых заданияй

   • Проект должен быть оформлен в виде wheel, который можно установить в произвольном окружении (например, на моём компьютере).

     • Если в процедуру деплоймента входит что-то сверх установки пакета (например, подкладывание API-ключа телеграм-боту), эту часть можно делать вручную: хранить ключи в репозитории, конечно, нельзя.
     • Если вы делаете подпроект в систему, которая не предполагает wheel, демонстрация чистого деплоймента полностью должна быть проделана на защите.

Замечания

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

• Не могу не заметить, что в этом самом реал лайфе по-хорошему должно быть 100% покрытие текстами

Разрешается использовать любые инструменты локализации, документирования, тестирования и т. п.; необязательно придерживаться рекомендаций.

• Однако условие №0 сохраняется: я должен иметь возможность самостоятельно проверить все свойства проекта (с оговоркой относительно деплоймента выше)

Методика проверки

0. показать статистику участия в проекте
1. показать проверку стиля и запуск тестов
2. показать выгонку техдокументации и саму документацию
3. сформировать дистрибутив
4. задеплоить в чистое окружение
5. показать работу и перевод

Оценка:

• По сумме баллов каждого из пунктов требований. То есть набрать 5 баллов из 6, что, с учётом претензий по каждому из пунктов, не так уж просто)

• В случае значимо неравномерного участия в проекте водится КТУ — есть шанс получить оценку меньше, чем товарищи

Регистрация проекта

Зарегистрировать публичный репозиторий проекта в качестве вашего персонального issue на странице репозитория PythonDevelopment2024. В issue указать:

• Короткую формулировку сути проекта (см. минимальное содержимое проекта при регистрации)

• Ссылку на публичный репозиторий проекта

• Список участников проекта в виде:
  1. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
  2. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
  3. …