Система проверки Д/З
TODO Задание это решено (Репозиторий проекта), требуется редизайн:
- Система доставки должна уметь несколько basckend-ов — как минимум, git и в приложениях к email
- Система доставки должна уметь обрабатывать доставленные объекты (например, распаковывать архивы, менять формат их содержимого)
- Система кеширования должна быть внешней
- Система тестирования (запуск программ) должна быть внешней
- …
См. также https://github.com/Veniamin-Arefev/NetJudge
Предварительные знания
Знания Python в объёме, достаточном для чтения и понимания скрипта-проверяльщика (нет, мы его не будем дорабатывать, это именно что тест на уровень знаний)
Кому недостаточно знаний в Python (и кто думает, что ему достаточно), стоит прочитать «со словарём» питоновский тьюториал. «Cо словарём» здесь означает: всё, что при чтении кажется не вполне понятным и особенно «примерно понятным» следует тут же отщёлкать в интерпретаторе руками.
Знания Git (в идеале — в объёме учебника по ссылке, но вот тут главное как раз понимание самого процесса, использовать мы будем от силы пять операций)
Текущий формат домашних заданий и тестов к ним (можно будет поменять)
Проектное задание
Проект делится на 7 направлений работ (детализация будет):
Система доставки. Позволяет скачивать / кешировать / обновлять все решения всех заданных Д/З всех зарегистрированных пользователей и формировать «паспорт» решения с метаданными (время первого/последнего коммита, закешированное расположение удалённых тестов и т. п.).
Система массовой проверки. Позволяет запускать обе подсистемы тестирования на всех решениях всех задач всех пользователей, или выборочно по «срезу» (конкретный пользователь, пользователь & задача и т. п.). Здесь необходимо кеширование результатов. Подготавливает данные для подсистем оценки и публикации.
Формальное тестирование без запуска решений. Для каждого Д/З можно задать набор проверочных условий (время сдачи, наличие тестов, наличие соответствующей регулярному выражению строки в программе-решении и т. п.). Запускает всю группу проверок на конкретном решении конкретного пользователя. Генерирует отчёт о проверке.
Собственно проверялка. Позволяет запустить один комплект собственных и удалённых тестов на одном решении и генерировать отчёт о прохождении этих тестов. Проверялка должна работать в двух вариантах: дома у любого пользователя (в этом случае придётся пользоваться доставкой как минимум удалённых тестов) и в составе системы массовой проверки под управлением подсистемы изолированного запуска.
Система изоляции запуска. В идеале — кроссплатформенная на питоне (исследовать принципиальную возможность такого подхода). Должна ограничивать: объём потреблямой памяти, количество запускаемых процессов, запись в файловую систему.
Система оценки. Получает полную статистику от системы массового тестирования, применяет формулу оценивания (в идеале нужен интерфейс, чтобы преподаватель мог при необходимости вводить эту формулу), формирует отчёт для системы публикации. Должна уметь показывать отчёты в человекочитаемом виде, в том числе отчёты по «срезу» (как минимум, по конкретному пользователю).
Система публикации результатов. Получает отчёт от системы оценки и формирует из него удобный HTML для публикации. Должна уметь запускаться как на произвольном компьютере, в составе всей системы, так и на изолированном хостинге (в идеале — предусмотреть интерфейс доставки отчётов и регулярное обновление).
Вводная (из переписки)
Есть два наших питоньих курса: LecturesCMC/PythonIntro2021 и LecturesCMC/PythonDevelopment2022; по каждому достаточно хорошо проработаны задания по лекциям, а вот задания по практикуму всё время «гуляют» из-за невозможности разумного (т. е. не тотального, но содержательного) отчёта по ним. С первым курсом легче, со вторым — сложнее, т. к. он наполовину ещё и на изучение Git ориентирован, и по Git тоже должны быть Д/З и отчёт по ним.
Для обработки заданий по практикуму написан некоторый скрипт-проверялка. Он что-то умеет, что-то — нет; хотя и рабочий, но писан на коленке «за один раз».
В идеале надо: - Сорганизоваться и написать ТЗ (оно довольно простое должно быть) - Начать делать эту проверялку не на колене, а с учётом ТЗ / roadmap - Довести её до состояния «кто угодно может ею индивидуально пользоваться для прогонки собственных тестов» к началу семестра - Довести её до состояния «преподаватель может ею пользоваться для формирования отчёта об успехах группы» к середине семестра.
В плане исследования — надо хорошенько покопать, как бы запуск произвольного чужого теста сделать побезопаснее.