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

Семестровый проект — это публичный git-репозиторий с кодом на Python3,

1. который я могу установить (любым предложенным вами кроссплатформенным способом) и запустить

   • предпочтительно wheel

   • лучше не docker ☺

2. в котором есть более одного участника, и я могу посмотреть статистику участия (оба предложенных ниже измерения неидеальны, я это знаю)
   • по количество коммитов
   • по объёму кода

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

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

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

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

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

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

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

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

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

Оценка:

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

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

TODO на следующий год:

0. +оценивается
   • automation
   • минимальная пользовательская документация (в составе sphinx или просто на wiki)
1. Методика проверки:
   1. показать сборку, выгонку документации, запуск тестов
   2. показать документацию
   3. задеплоить в чистое окружение, показать работу и перевод
2. Разработать критерии оценки качества репозитория
   • Не хранить генераты
   • Что-то про дисциплину коммитов (например, формальный парсер написать)