8. Заключение¶
8.1. Рекомендуемый стек для публикации результатов моей работы¶
Для публикации результатов экспериментов по записи взгляда в VR я рекомендую связку: MkDocs с темой Material как генератор, Python-скрипт обработки данных, вызываемый из Makefile перед сборкой, GitHub Actions (или совместимый GitVerse) для автоматизации, GitHub Pages как основную публикацию и доставку по SSH/rsync (мой action rsync-ssh-deploy) на сервер университета или другого российского хостинга.
Причины выбора:
- Сайт состоит в основном из текста, таблиц и нескольких графиков. Markdown-исходники и готовая тема Material закрывают это без настройки.
- Расчёт отделён от вёрстки: скрипт строит таблицы и графики, MkDocs подключает их как готовые артефакты. Так сборка остаётся быстрой, а результат привязывается к версии кода и данных через метку версии.
- Режим
--strictи проверка опубликованной страницы после выкладки не дают выложить сломанный сайт. - Доставка на shell-командах (
wrangler,rsync,curl) переносится между платформами почти без изменений, в отличие от действий, специфичных для GitHub. - По измерениям (раздел 6) выкладка на GitHub Pages занимает около 10 с, по SSH — 16 с, на Cloudflare Pages — около 32 с (из них 10 с — создание проекта, которое нужно только в первый раз). Сборка (в среднем 35 с) и установка зависимостей (около 20 с) дороже любой из выкладок, поэтому ускорять стоит кэш и сборку, а не способ доставки.
8.2. Когда рекомендация меняется¶
| Условие | Что менять |
|---|---|
| Нужны нумерованные формулы, перекрёстные ссылки на рисунки и BibTeX-библиография, как в статье | перейти на Sphinx с MyST-Parser или Quarto, у них эти возможности встроены |
| Результаты считаются прямо в ноутбуках и должны исполняться при сборке | Quarto или MyST-NB вместо отдельного скрипта |
| Вычисления тяжёлые (обучение модели-стабилизатора, видеозаписи сессий) | считать вне CI, а сайт собирать из готовых артефактов; в метке версии хранить хеши данных и модели |
| Данные содержат записи участников с ОВЗ | не публиковать сырые записи; на сайт выкладывать только агрегированные метрики и получать отдельное согласие участников |
| Репозиторий и сайт нужно держать в российском контуре | GitVerse, как наиболее близкая по синтаксису к GitHub Actions; публикацию на Pages заменить доставкой по SSH (rsync-ssh-deploy) или S3 |
| Нужно версионирование опубликованных результатов | добавить mike и привязать выкладку версии к git-тегу |
8.3. Отклонения от задания и ограничения¶
- Отечественный хостинг не задействован. В задании в качестве второго хоста предполагался отечественный хостинг. Я выбрала Cloudflare Pages, потому что он бесплатен и не требует банковской карты, а российские хостинги (Yandex Object Storage, Timeweb Cloud, Selectel) платные и требуют привязки платёжных данных. Это отклонение от задания, и оно ограничивает выводы: задержки и доступность для пользователей из России на Cloudflare я не измеряла. Вместо отечественного хоста действие
rsync-ssh-deployпроверено на SSH-сервере, поднятом на раннере. Постоянного сервера у меня нет. - Action не опубликован в Marketplace (см. раздел 5.6): публикация требует принять соглашение разработчика на GitHub и выполняется владельцем аккаунта вручную.
- Измерения сняты на нескольких запусках на бесплатных раннерах GitHub. Они показывают порядок величин, а не статистически надёжные значения.
8.4. Что не проверено¶
Результаты на странице P3 получены на небольшой пилотной записи и описывают один набор данных одного автора. Сравнение групп с ОВЗ и без ОВЗ в этой работе не выполнялось. Время загрузки страниц с точки зрения пользователя из разных регионов не измерялось: измерен только вес страниц и время работы пайплайна.