ada-pc: 2026-06-10 22:32:38 | 6
Affected files: .trash/Система контроля версий. Знакомство с Git.md .trash/УИР_Учёт_посещаемости_МИФИ.md 00 Inbox/CIСD Конвейер для сборки и доставки продукта. Знакомство с GitlabCI и Jenkins.md 02 Projects/Наука/НИР/УИР_Сводный_вариант.md 99 System/Archive/gemini-code-1780921978295.md 99 System/Archive/Обзор аналогов и обоснование инструментария системы учёта посещаемости студентов НИЯУ МИФИ.md
This commit is contained in:
Dmitry
+10
@@ -0,0 +1,10 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-06-10
|
||||
aliases: []
|
||||
---
|
||||
|
||||
# CIСD Конвейер для сборки и доставки продукта. Знакомство с GitlabCI и Jenkins
|
||||
@@ -1,150 +0,0 @@
|
||||
---
|
||||
created: 2026-06-08
|
||||
updated: 2026-06-09
|
||||
---
|
||||
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
|
||||
|
||||
Федеральное государственное автономное образовательное учреждение высшего образования
|
||||
|
||||
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ «МИФИ»
|
||||
|
||||
<br>
|
||||
|
||||
**Учебно-исследовательская работа на тему:**
|
||||
«Аналитический обзор решений на рынке по системам контроля посещаемости в ВУЗе, сравнение с собственной разработкой и обоснование выбора технологического стека»
|
||||
|
||||
**Выполнил студент:** [ФИО студента]
|
||||
**Группа:** [Номер группы]
|
||||
|
||||
**Проверил:**
|
||||
[ФИО преподавателя]
|
||||
**Оценка:** ___________________
|
||||
**Дата:** _____________________
|
||||
**Подпись:** __________________
|
||||
|
||||
Москва, 2026
|
||||
|
||||
---
|
||||
|
||||
## Оглавление
|
||||
1. Введение
|
||||
2. Глава 1. Анализ существующих решений и систем контроля посещаемости
|
||||
1.1. Обзор российских систем
|
||||
1.2. Обзор зарубежных систем
|
||||
1.3. Сравнительный анализ аналогов
|
||||
3. Глава 2. Обоснование собственной разработки и выбора технологического стека
|
||||
2.1. Концепция системы Attendance MEPhI
|
||||
2.2. Выбор веб-фреймворка и архитектуры приложения
|
||||
2.3. Фронтенд-архитектура: отказ от SPA в пользу Hotwire
|
||||
2.4. Выбор СУБД и организация бизнес-логики
|
||||
2.5. Асинхронная обработка и надежная синхронизация (Outbox Pattern)
|
||||
2.6. Интеграция с корпоративной системой аутентификации (CAS)
|
||||
4. Заключение
|
||||
5. Список использованной литературы
|
||||
|
||||
---
|
||||
|
||||
## Введение
|
||||
|
||||
Цифровая трансформация образовательного процесса в современных университетах требует внедрения надежных и прозрачных инструментов контроля успеваемости и присутствия обучающихся. В условиях крупного вуза, такого как НИЯУ МИФИ, традиционные бумажные журналы или несистематизированные электронные таблицы становятся неэффективными, повышая риск потери данных и усложняя сбор аналитики для деканатов и администрации.
|
||||
|
||||
В связи с этим возникает потребность в автоматизированной системе учета посещаемости, способной интегрироваться с внутренними реестрами вуза и обеспечивать удобный интерфейс как для преподавателей, так и для студентов. Готового аналога, закрывающего все требования МИФИ, на рынке нет: зарубежные универсальные инструменты фиксируют посещаемость лишь как побочный продукт онлайн-встреч и не интегрируются с CAS МИФИ, а российские решения ориентированы на школу или корпоративное обучение, не давая студенческой QR-самоотметки и Outbox-синхронизации[cite: 1]. Это прямо обосновывает разработку собственной системы[cite: 1].
|
||||
|
||||
**Актуальность работы** обусловлена отсутствием на рынке универсального on-premise решения, которое сочетало бы механизм быстрой самостоятельной отметки студентов на очных занятиях, интеграцию с корпоративной системой авторизации и гарантированную асинхронную доставку данных в академические реестры университета[cite: 1].
|
||||
|
||||
**Целью работы** является проведение аналитического обзора существующих рыночных решений в сфере контроля посещаемости, их сравнение с разрабатываемой системой «Attendance MEPhI» и обоснование выбранного технологического стека[cite: 3].
|
||||
|
||||
**Задачи исследования:**
|
||||
1. Провести обзор российских и зарубежных аналогов систем контроля посещаемости.
|
||||
2. Сформировать сравнительную матрицу функциональных возможностей.
|
||||
3. Обосновать необходимость разработки собственного программного решения.
|
||||
4. Выполнить обоснование выбранной архитектуры, фреймворка, СУБД и сопутствующих технологий[cite: 1, 3].
|
||||
|
||||
---
|
||||
|
||||
## Глава 1. Анализ существующих решений и систем контроля посещаемости
|
||||
|
||||
Ни один массовый продукт не сочетает одновременно четыре ключевых свойства, необходимых корпоративному вузу: QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO (CAS МИФИ), гарантированную синхронизацию с внутренними реестрами и полную ролевую модель[cite: 1].
|
||||
|
||||
### 1.1. Обзор российских систем
|
||||
|
||||
**1. БАРС.Образование — Электронная школа**
|
||||
Одна из самых распространенных в РФ платформ электронного дневника[cite: 1]. Модуль ориентирован на фиксацию посещаемости исключительно путем ручной отметки учителем[cite: 1]. Основным архитектурным ограничением является использование школьной модели данных («школа — класс — родитель»), которая не масштабируется на сложную вузовскую структуру («учебный поток — группа — подгруппа»)[cite: 1]. Кроме того, интеграция реализуется через СМЭВ/Госуслуги, что затрудняет использование корпоративного CAS вуза[cite: 1].
|
||||
|
||||
**2. iSpring Learn (iSpring LMS)**
|
||||
Известная российская корпоративная LMS, доступная в облаке вендора и on-premise[cite: 1]. Включает отчет по посещаемости очных тренингов, где преподаватель отмечает участников вручную[cite: 1]. Система предназначена для корпоративного обучения персонала, не поддерживает ролевую модель учебного потока вуза и QR-самоотметку на занятии, а также не имеет Outbox-синхронизации с академическими реестрами[cite: 1].
|
||||
|
||||
**3. 1С:Университет**
|
||||
Отраслевое решение на платформе «1С:Предприятие 8.3» для комплексного управления вузом[cite: 1]. Посещаемость вводится вручную через АРМ[cite: 1]. В решении отсутствует студенческий QR-self-service и нативное веб-самообслуживание[cite: 1]. Интеграция требует механизмов обмена 1С, а не современных REST/CAS[cite: 1].
|
||||
|
||||
**4. Система «Учет посещаемости студентов» ВВГУ**
|
||||
Собственная разработка Департамента цифрового развития ВВГУ[cite: 1]. Поддерживает QR-отметку и имеет частичную ролевую модель (роль куратора)[cite: 1]. Главный недостаток — это закрытая внутренняя система одного вуза без публичного API и Outbox-синхронизации, не интегрируемая с внешними CAS МИФИ[cite: 1].
|
||||
|
||||
### 1.2. Обзор зарубежных систем
|
||||
|
||||
**1. Microsoft Teams и Google Classroom/Meet**
|
||||
Обе платформы фиксируют присутствие на видеовстрече (время входа/выхода), а не на очном занятии[cite: 1]. Нативной отметки очных занятий по QR нет, интеграция с внутренними реестрами и вузовская ролевая модель отсутствуют[cite: 1].
|
||||
|
||||
**2. Brightspace (D2L) — Attendance tool**
|
||||
Базовый инструмент представляет собой электронный реестр, где отметку ставит преподаватель или ассистент вручную[cite: 1]. Мобильная самоотметка и QR реализуются только через сторонние интеграции и платные плагины (Qwickly Attendance), что требует внедрения всей LMS Brightspace[cite: 1].
|
||||
|
||||
**3. Специализированные QR/чек-ин SaaS решения (OneTap, AccuClass)**
|
||||
Эти сервисы предоставляют функционал сканирования QR-кодов, однако ориентированы на мероприятия или школы[cite: 1]. Данные хранятся в облаке вендора (vendor lock-in), нет вузовской ролевой модели и Outbox-синхронизации[cite: 1].
|
||||
|
||||
### 1.3. Сравнительный анализ аналогов
|
||||
|
||||
**Таблица 1 — Сравнительный анализ систем учета посещаемости[cite: 1]**
|
||||
|
||||
| Система | QR-self-service | SSO/CAS-интеграция | Outbox-синхронизация | Вузовская ролевая модель | On-premise |
|
||||
| :--- | :---: | :---: | :---: | :---: | :---: |
|
||||
| ВВГУ "Учет посещаемости" | ✔ | ✘ | ✘ | Частично | ✔ |
|
||||
| БАРС.Образование | ✘ | ✘ (Госуслуги) | ✘ | Школьная | Зависит |
|
||||
| iSpring Learn | ✘ | ✔ (SSO) | ✘ | Корпоративная | ✔ |
|
||||
| 1С:Университет | ✘ | ✘ | ✘ (обмен 1С) | ✔ | ✔ |
|
||||
| MS Teams | ✘ | ✔ (Azure AD) | ✘ | ✘ | ✘ |
|
||||
| Google Classroom/Meet | ✘ | ✔ (Google) | ✘ | ✘ | ✘ |
|
||||
| Brightspace | Через плагины | ✔ | ✘ | LMS | ✔ |
|
||||
| QR-SaaS (OneTap и др.) | ✔ | Частично | ✘ | ✘ | ✘ |
|
||||
| **Attendance MEPhI (Проект)** | **✔** | **✔ (CAS МИФИ)**| **✔** | **✔ (полная)**| **✔** |
|
||||
|
||||
**Вывод по Главе 1:** Ниша систем для QR-самоотметки очной посещаемости с интеграцией CAS-SSO вуза, Outbox-синхронизацией с реестрами и полной ролевой моделью не закрыта существующими продуктами, что служит обоснованием разработки[cite: 1].
|
||||
|
||||
---
|
||||
|
||||
## Глава 2. Обоснование собственной разработки и выбора технологического стека
|
||||
|
||||
### 2.1. Концепция системы Attendance MEPhI
|
||||
**Attendance MEPhI** — это веб-приложение для отслеживания посещаемости занятий студентами НИЯУ МИФИ[cite: 3]. Система автоматизирует процесс фиксации присутствия студентов на лекциях и семинарах, предоставляя интерфейсы для студентов, преподавателей (тьюторов), модераторов и администраторов[cite: 3]. Проект построен на классическом паттерне MVC с использованием современных расширений Rails[cite: 3].
|
||||
|
||||
### 2.2. Выбор веб-фреймворка и архитектуры приложения
|
||||
Стек Rails 7 обоснован архитектурно[cite: 1]. Rails реализует строгий паттерн MVC, принципы «Convention over Configuration» и DRY, что ускоряет разработку CRUD-приложений[cite: 1]. Хотя Ruby исторически уступает по "сырой" производительности оптимизированным PHP/Python, это компенсируется фоновой обработкой, кэшированием и горизонтальным масштабированием[cite: 1].
|
||||
|
||||
### 2.3. Фронтенд-архитектура: отказ от SPA в пользу Hotwire
|
||||
Server-rendered HTML через Hotwire (Turbo + Stimulus) снимает необходимость в отдельном SPA[cite: 1]. Он отправляет фрагменты HTML вместо JSON, обеспечивая отзывчивый интерфейс без тяжелого клиентского JS[cite: 1, 3]. Для стилизации используется Tailwind CSS, utility-first подход которого дает существенно меньший production-бандл за счет JIT-purge и не тянет лишние JS-компоненты[cite: 1, 3].
|
||||
|
||||
### 2.4. Выбор СУБД и организация бизнес-логики
|
||||
В качестве хранилища данных выбрана PostgreSQL[cite: 1, 3]. Это ACID-совместимая СУБД с MVCC, расширенным набором типов и ролевой моделью доступа, предпочтительная для транзакционных приложений с большими объемами данных[cite: 1].
|
||||
Бизнес-логика (импорт данных, обработка посещений) изолируется в Service Objects (`app/services`), что соответствует принципу единой ответственности и упрощает тестирование[cite: 1, 3]. Ролевая модель поддерживается через пространства имен контроллеров (Namespaced Controllers: `Admin`, `Student` и т.д.), что изолирует ролевые интерфейсы и упрощает авторизацию[cite: 1, 3].
|
||||
|
||||
### 2.5. Асинхронная обработка и надежная синхронизация (Outbox Pattern)
|
||||
Для гарантированной доставки данных во внешние реестры МИФИ используется Outbox Pattern (таблица `update_attendance_students_outbox`)[cite: 1, 3]. Событие записывается в outbox-таблицу в той же транзакции, что и бизнес-данные, решая проблему "dual write"[cite: 1]. Отдельный процесс (Sidekiq) асинхронно публикует его наружу, обеспечивая доставку at-least-once[cite: 1]. Sidekiq использует Redis как in-memory хранилище очередей и эффективен по памяти благодаря многопоточной модели[cite: 1, 3].
|
||||
|
||||
### 2.6. Интеграция с корпоративной системой аутентификации (CAS)
|
||||
Система интегрируется с CAS (Central Authentication Service) МИФИ для Single Sign-On[cite: 3]. CAS — это протокол, при котором приложение никогда не видит пароль пользователя: аутентификация выполняется на доверенном сервере, выдающем service ticket[cite: 1]. Это снижает риск фишинга и избавляет от необходимости вести локальную базу паролей[cite: 1].
|
||||
|
||||
---
|
||||
|
||||
## Заключение
|
||||
|
||||
Анализ показал, что ни одна из массовых российских или зарубежных систем не удовлетворяет одновременно требованиям QR-самоотметки, интеграции с CAS МИФИ, наличию механизмов надежной Outbox-репликации данных и поддержке специфической ролевой модели вуза. Выбранный технологический стек (Ruby on Rails 7, PostgreSQL, Hotwire, Sidekiq) обеспечивает высокую скорость разработки, SPA-ощущение без перегрузки клиентской части JavaScript-кодом и промышленную надежность доставки данных во внешние реестры. Разработка системы «Attendance MEPhI» обоснована и технически реализуема.
|
||||
|
||||
---
|
||||
|
||||
## Список использованной литературы
|
||||
|
||||
1. Nuhi A., Memeti A., Imeri F., Çiço B. Smart Attendance System using QR Code // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020, pp. 1–4. DOI: 10.1109/MECO49872.2020.9134225.
|
||||
2. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. №5.
|
||||
3. Salunke S.V., Ouda A. A Performance Benchmark for the PostgreSQL and MySQL Databases // Future Internet (MDPI). 2024. Vol. 16(10). Art. 382. DOI: 10.3390/fi16100382.
|
||||
4. Даньшин К.А. Сравнительный анализ современных веб-фреймворков для разработки приложений // CyberLeninka, 2019.
|
||||
5. Chris Richardson. Microservices Patterns: With examples in Java. Manning Publications. (Pattern: Transactional outbox).
|
||||
|
||||
-168
@@ -1,168 +0,0 @@
|
||||
---
|
||||
created: 2026-06-08
|
||||
updated: 2026-06-08
|
||||
---
|
||||
|
||||
# УИР:
|
||||
## TL;DR
|
||||
- **Готового аналога, закрывающего все требования МИФИ, на рынке нет:** зарубежные универсальные инструменты (Microsoft Teams, Google Classroom/Meet, Brightspace) фиксируют посещаемость лишь как побочный продукт онлайн-встреч и не интегрируются с CAS МИФИ и внутренними реестрами; российские ЭЖ/LMS (БАРС.Образование, iSpring Learn, 1С:Университет) ориентированы на школу или корпоративное обучение, не дают студенческой QR-самоотметки и Outbox-синхронизации. Это прямо обосновывает разработку собственной системы.
|
||||
- **Стек Rails 7 + Hotwire + PostgreSQL + Sidekiq/Redis + Tailwind обоснован архитектурно:** server-rendered HTML через Hotwire снимает необходимость в отдельном SPA, Outbox-паттерн гарантирует надёжную (at-least-once) доставку данных во внешние реестры, Service Objects изолируют бизнес-логику, namespaced-контроллеры естественно поддерживают ролевую модель вуза.
|
||||
- **Академическая база достаточна для УИР:** по QR-посещаемости есть прямой IEEE-источник (Nuhi et al., 2020, DOI 10.1109/MECO49872.2020.9134225); по ЭЖ вуза — отраслевая статья ВИТИ НИЯУ МИФИ (Глуховский и др., 2021); по СУБД — рецензируемый бенчмарк Salunke & Ouda (Future Internet, MDPI, 2024, DOI 10.3390/fi16100382). Часть технических обоснований (Hotwire, Tailwind, Sidekiq) опирается на документацию и отраслевые источники, что следует честно помечать.
|
||||
|
||||
## Key Findings
|
||||
|
||||
### Часть 1. Аналоги
|
||||
1. Ни один массовый продукт не сочетает одновременно четыре ключевых свойства, необходимых корпоративному вузу: **(а)** QR-самоотметку студента на очном занятии, **(б)** интеграцию с корпоративным SSO (CAS МИФИ), **(в)** гарантированную (Outbox) синхронизацию с внутренними академическими реестрами, **(г)** полную ролевую модель (студент / преподаватель / куратор / деканат / администратор).
|
||||
2. Российские школьные ЭЖ (БАРС, Дневник.ру, ЭлЖур, "Сетевой город") реализуют посещаемость как **ручную отметку учителя**; модель "класс — родитель" не масштабируется на вузовскую "поток — группа — подгруппа".
|
||||
3. Зарубежные инструменты считают **присутствие на онлайн-встрече** (время входа/выхода), что не эквивалентно присутствию на очном занятии.
|
||||
|
||||
### Часть 2. Инструментарий
|
||||
Каждый компонент стека имеет рецензируемое либо авторитетное первичное обоснование, пригодное для цитирования в УИР; "слабые места" (производительность Ruby, противоречивость бенчмарков СУБД, небиблиометричность части источников) отмечены явно.
|
||||
|
||||
---
|
||||
|
||||
## Details
|
||||
|
||||
## ЧАСТЬ 1. ОБЗОР СУЩЕСТВУЮЩИХ АНАЛОГОВ
|
||||
|
||||
### Российские системы
|
||||
|
||||
**1. Система "Учёт посещаемости студентов" ВВГУ (ВГУЭС)**
|
||||
- *Описание:* собственная разработка Департамента цифрового развития ВВГУ. Преподаватель показывает QR-код, студенты сканируют его для записи о присутствии; возможна ручная отметка преподавателем или назначенным кафедрой куратором группы.
|
||||
- *Функции:* QR-отметка, ручная отметка, роль куратора.
|
||||
- *Ограничения:* закрытая внутренняя система одного вуза; нет публичного API/Outbox-синхронизации; права куратора выдаются по бумажному заявлению в Центр ИТ-обеспечения.
|
||||
- *Почему хуже для МИФИ:* не интегрируется с внешними CAS/реестрами МИФИ; ограниченная ролевая модель.
|
||||
|
||||
**2. БАРС.Образование — Электронная школа**
|
||||
- *Описание:* одна из самых распространённых в РФ платформ ЭЖ/электронного дневника; модуль "БАРС.Образование — Электронная школа" рекомендован Минкомсвязью к тиражированию в рамках мероприятия "Электронный регион"; вход — по логину/паролю Госуслуг.
|
||||
- *Функции:* электронный журнал (оценки, темы уроков, отметка посещаемости — вручную учителем), электронный дневник, планирование учебного процесса, расписание, отчётность.
|
||||
- *Ограничения:* посещаемость только ручная (нет QR/самоотметки); архитектура "школа — класс — родитель".
|
||||
- *Почему хуже для МИФИ:* школьная модель данных; интеграция реализуется через СМЭВ/Госуслуги, а не через корпоративный CAS вуза; проприетарность.
|
||||
|
||||
**3. iSpring Learn (iSpring LMS)**
|
||||
- *Описание:* российская корпоративная LMS (компания iSpring, Йошкар-Ола; платформу используют клиенты в 172 странах), доступна в облаке вендора и в установке на сервер клиента (on-premise).
|
||||
- *Функции:* курсы, тесты, вебинары (интеграция с Zoom), отчёт "ILT Attendance" по посещаемости очных тренингов/вебинаров (преподаватель отмечает участников вручную после мероприятия), SSO, открытый API, мобильное приложение.
|
||||
- *Ограничения:* посещаемость — побочная функция "мероприятий"; нет QR-самоотметки на занятии; нет модели "учебный поток вуза".
|
||||
- *Почему хуже для МИФИ:* предназначена для корпоративного обучения персонала, а не для учёта очной посещаемости студентов; нет Outbox-синхронизации с академическими реестрами.
|
||||
|
||||
**4. 1С:Университет**
|
||||
- *Описание:* отраслевое решение на платформе "1С:Предприятие 8.3" для комплексного управления вузом.
|
||||
- *Функции:* контингент студентов, личные дела и зачётные книги, учёт успеваемости и посещаемости, массовое формирование ведомостей, приёмная кампания, поддержка территориально распределённых баз.
|
||||
- *Ограничения:* тяжёлое ERP-решение, посещаемость вводится вручную через АРМ; нет студенческого QR-self-service и нативного веб-самообслуживания.
|
||||
- *Почему хуже для МИФИ:* монолитная проприетарная экосистема 1С; интеграция требует механизмов обмена 1С, а не REST/CAS.
|
||||
|
||||
**5. Прочие российские: Дневник.ру, ЭлЖур, "Сетевой город. Образование" (NetSchool), "Мой Класс", "Учебный учет"**
|
||||
- Это школьные электронные журналы или CRM для учебных центров: ручная отметка посещаемости, модель "класс/группа", без QR-self-service и без вузовской интеграции с CAS/реестрами.
|
||||
|
||||
### Зарубежные системы
|
||||
|
||||
**6. Microsoft Teams (attendance & engagement report)**
|
||||
- *Функции:* автоматический отчёт о посещаемости онлайн-встречи (имена, время входа/выхода, длительность участия); engagement-отчёт (реакции, поднятые руки, включённые камеры) — только в Teams Enterprise/Premium; экспорт в CSV.
|
||||
- *Ограничения:* фиксирует присутствие на **видеовстрече**, а не на очном занятии. По документации Microsoft, "If the event organizer leaves the org, reports are permanently deleted and can't be retrieved" — отчёты привязаны к организатору и безвозвратно удаляются при его уходе из организации. Также: "In meetings with more than 120 participants, the attendance report that's available during the meeting will only include a partial list of attendees. The post-meeting report will contain the full list" — во время встречи >120 участников виден лишь частичный список.
|
||||
- *Почему хуже для МИФИ:* считает онлайн-участие; нет QR для очных занятий; нет интеграции с CAS/реестрами МИФИ; нет вузовской ролевой модели.
|
||||
|
||||
**7. Google Classroom / Google Meet (attendance tracking)**
|
||||
- *Функции:* в самом Google Classroom **нативной отметки посещаемости нет** (распространённый обходной путь — Google Forms/Sheets). По справке Google Meet, отслеживание посещаемости доступно только на платных тарифах: "Attendance tracking is available to Google Workspace Essentials, Business Plus, Enterprise Starter, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Plus and the Teaching and Learning Upgrade users"; пользователи Education Plus и Teaching and Learning Upgrade "automatically receive an attendance report for any meeting with two or more participants".
|
||||
- *Ограничения:* отсутствие встроенной посещаемости в Classroom; отчёт Meet формируется по онлайн-встрече и требует платной редакции; привязка к экосистеме Google Workspace.
|
||||
- *Почему хуже для МИФИ:* ключевая функция отсутствует/платная; нет очного QR; нет интеграции с внутренними системами вуза.
|
||||
|
||||
**8. Brightspace (D2L) — Attendance tool**
|
||||
- *Функции:* реестры посещаемости (registers), настраиваемые схемы статусов и порог тревоги. По документации D2L, системная схема (System Scheme) состоит из двух статусов — present и absent, а "Cause for Concern (%)" задаёт порог, при падении ниже которого в колонке процента посещаемости выводится предупреждение; есть интеграция с журналом оценок и e-mail. QR/мобильная самоотметка — **только через сторонние интеграции** (Qwickly Attendance, You-Attend) из D2L IntegrationHub.
|
||||
- *Ограничения:* базовый инструмент — электронный ledger; отметку ставит преподаватель/ассистент вручную (инструмент **не** self-reporting).
|
||||
- *Почему хуже для МИФИ:* требует внедрения всей LMS Brightspace плюс платных плагинов для QR; нет нативной интеграции с CAS МИФИ.
|
||||
|
||||
**9. Специализированные QR/чек-ин SaaS: OneTap, AccuClass (Engineerica), QR-Code-Generator, SuperQR, QR Attendee**
|
||||
- *Функции:* QR/штрихкод чек-ин, импорт из Excel, дашборды, отчёты, иногда геолокация.
|
||||
- *Ограничения:* SaaS "под мероприятия/школы/залы"; данные хранятся в облаке вендора; нет вузовской ролевой модели и интеграции с внутренними реестрами.
|
||||
- *Почему хуже для МИФИ:* vendor lock-in, хранение ПДн у внешнего провайдера, отсутствие SSO-интеграции с CAS и Outbox-синхронизации.
|
||||
|
||||
**10. Open-source проекты (GitHub: AzeemIdrisi/QR-Attendance-System, Gudleifr1/Check-by-QR и др.)**
|
||||
- *Функции:* генерация и сканирование QR, геопроверка, защита от повторной отметки и от устаревших кодов, HTTPS.
|
||||
- *Ограничения:* студенческие/хакатонные прототипы на разнородных стеках (Django, PHP/Bootstrap, Java/SQLite, .NET MAUI/C#); без промышленной надёжности доставки и без корпоративной интеграции.
|
||||
- *Почему хуже для МИФИ:* не production-grade; нет Outbox/CAS/ролевой модели.
|
||||
|
||||
**Сравнительная таблица (рекомендуемый формат для главы):**
|
||||
|
||||
| Система | QR-self-service | SSO/CAS-интеграция | Outbox-синхронизация | Вузовская ролевая модель | On-premise | Open-source |
|
||||
|---|---|---|---|---|---|---|
|
||||
| ВВГУ "Учёт посещаемости" | ✔ | ✘ | ✘ | частично | ✔ | ✘ |
|
||||
| БАРС.Образование | ✘ | ✘ (Госуслуги/СМЭВ) | ✘ | школьная | зависит | ✘ |
|
||||
| iSpring Learn | ✘ | ✔ (SSO) | ✘ | корпоративная | ✔ | ✘ |
|
||||
| 1С:Университет | ✘ | ✘ | ✘ (обмен 1С) | ✔ | ✔ | ✘ |
|
||||
| MS Teams | ✘ | ✔ (Azure AD) | ✘ | ✘ | ✘ | ✘ |
|
||||
| Google Classroom/Meet | ✘ | ✔ (Google) | ✘ | ✘ | ✘ | ✘ |
|
||||
| Brightspace | через плагины | ✔ | ✘ | LMS | ✔ | ✘ |
|
||||
| QR-SaaS (OneTap и др.) | ✔ | частично | ✘ | ✘ | ✘ | ✘ |
|
||||
| **Проектируемая система МИФИ** | **✔** | **✔ (CAS МИФИ)** | **✔** | **✔ (полная)** | **✔** | **✔** |
|
||||
|
||||
**Вывод по Части 1:** ниша "QR-самоотметка очной посещаемости + CAS-SSO вуза + Outbox-синхронизация с реестрами + полная ролевая модель + on-premise" не закрыта существующими продуктами — это и есть обоснование разработки собственной системы.
|
||||
|
||||
---
|
||||
|
||||
## ЧАСТЬ 2. ОБОСНОВАНИЕ ВЫБОРА ИНСТРУМЕНТАРИЯ (с источниками)
|
||||
|
||||
### 2.1 Веб-фреймворк: Ruby on Rails 7 (vs Django / Laravel / Spring)
|
||||
- *Обоснование:* Rails реализует строгий паттерн MVC, принципы "Convention over Configuration" и DRY, что ускоряет разработку CRUD-приложений; зрелая экосистема gem'ов; Hotwire включён в Rails 7 "из коробки". На Rails работают GitHub, Shopify, Basecamp.
|
||||
- *Честный контр-аргумент:* Ruby исторически уступает по "сырой" производительности оптимизированному PHP/Python и требует больше памяти; компенсируется фоновой обработкой, кэшированием и горизонтальным масштабированием.
|
||||
- *Русскоязычный источник:* Даньшин К.А. "Сравнительный анализ современных веб-фреймворков для разработки приложений" (CyberLeninka, 2019) — сравнение ASP.NET Core, Laravel, Spring, Ruby on Rails, Django. Альтернатива (ВАК): "Преимущества и недостатки фреймворков для разработки веб-приложений в целях цифровизации экономики" // "Научное обозрение. Технические науки".
|
||||
- *Раздел:* выбор бэкенд-фреймворка и архитектуры MVC.
|
||||
|
||||
### 2.2 Hotwire / Turbo / Stimulus (альтернатива SPA)
|
||||
- *Обоснование:* Hotwire ("HTML Over The Wire", автор — D. H. Hansson) отправляет фрагменты HTML вместо JSON, обеспечивая "SPA-ощущение" без тяжёлого клиентского JS. Компоненты: Turbo Drive (навигация без полной перезагрузки), Turbo Frames (независимые регионы), Turbo Streams (точечные/realtime-обновления, в т.ч. по WebSocket), Stimulus (минимальная интерактивность). Меньше передаваемых данных, быстрее загрузка, проще поддержка для backend-команды.
|
||||
- *Честный контр-аргумент:* в части независимых тестов прирост скорости навигации Turbo по сравнению с уже оптимизированными решениями оказывался незначительным; htmx даёт меньший бандл. Для backend-ориентированной команды и server-rendered приложения выигрыш Hotwire — прежде всего в DX и снижении объёма JS.
|
||||
- *Раздел:* фронтенд-архитектура; обоснование отказа от отдельного React/Vue SPA.
|
||||
|
||||
### 2.3 Фоновые задачи: Sidekiq + Redis
|
||||
- *Обоснование:* Sidekiq — многопоточный обработчик фоновых задач, использующий Redis (in-memory store) как хранилище очередей; интеграция с Active Job (`config.active_job.queue_adapter = :sidekiq`); очереди с приоритетами, авто-ретраи с экспоненциальной задержкой, веб-интерфейс мониторинга. Многопоточная модель эффективнее по памяти, чем процессные Resque/Delayed Job. Критично для Outbox-релея (асинхронная публикация событий) и тяжёлых операций (генерация отчётов, рассылки).
|
||||
- *Раздел:* асинхронная обработка; реализация Outbox-релея.
|
||||
|
||||
### 2.4 Outbox Pattern (надёжная доставка во внешние реестры)
|
||||
- *Обоснование:* решает проблему "dual write" — несогласованности при одновременной записи в БД и отправке сообщения брокеру. Событие записывается в outbox-таблицу **в той же транзакции**, что и бизнес-данные; отдельный процесс-релей (Sidekiq) публикует его наружу, обеспечивая гарантию доставки at-least-once; получатели должны быть **идемпотентны** (релей может опубликовать сообщение более одного раза). Устраняет необходимость в распределённых транзакциях (2PC).
|
||||
- *Источники (первичные/авторитетные):* Chris Richardson, microservices.io — "Pattern: Transactional outbox"; AWS Prescriptive Guidance — "Transactional outbox pattern"; Confluent Developer; книга Chris Richardson "Microservices Patterns".
|
||||
- *Раздел:* синхронизация с внешними реестрами МИФИ; надёжность данных.
|
||||
|
||||
### 2.5 Service Objects в Rails
|
||||
- *Обоснование:* вынос бизнес-логики из "толстых" моделей/контроллеров в PORO (plain old Ruby object) с единственным публичным методом `call`, размещаемые в `app/services`. Принципы: единая ответственность, тестируемость в изоляции, переиспользуемость, "skinny models, skinny controllers".
|
||||
- *Честный контр-аргумент:* часть сообщества (M. Fowler — критика "анемичной модели") считает массовые Service Objects антипаттерном, ведущим к процедурному стилю; применять для логики, которая действительно не принадлежит ни модели, ни контроллеру.
|
||||
- *Раздел:* организация бизнес-логики (генерация/валидация QR, проведение отметки, формирование Outbox-событий).
|
||||
|
||||
### 2.6 СУБД: PostgreSQL (vs MySQL / SQLite)
|
||||
- *Обоснование:* PostgreSQL — полностью ACID-совместимая СУБД с MVCC, расширенным набором типов, ролевой моделью доступа (role-based access control), SSL/TLS, логической репликацией (Publish/Subscribe); предпочтительна для сложных транзакционных приложений с большими объёмами данных.
|
||||
- *Рецензируемый источник:* Salunke S.V., Ouda A. "A Performance Benchmark for the PostgreSQL and MySQL Databases" // Future Internet (MDPI). 2024. Vol. 16(10). Art. 382. DOI: 10.3390/fi16100382. Ключевой результат: "PostgreSQL's execution time for 1 million records ranged from 0.6 ms to 0.8 ms, while MySQL's ranged from 9 ms to 12 ms, indicating that PostgreSQL is about 13 times faster"; для SELECT c WHERE — 0.09–0.13 мс против 0.9–1 мс (≈9× быстрее). Авторы отмечают: "Our quantified results show PostgreSQL's superior performance in select operations".
|
||||
- *Честный контр-аргумент:* результаты бенчмарков зависят от профиля нагрузки — в ряде независимых тестов (sysbench OLTP read-only) MySQL опережал PostgreSQL на простых SELECT на 20–30%. Абсолютное превосходство одной СУБД утверждать некорректно; выбор PostgreSQL мотивирован транзакционной целостностью и богатством типов, важными для Outbox и ролевой модели.
|
||||
- *Раздел:* выбор хранилища данных.
|
||||
|
||||
### 2.7 Namespaced Controllers (организация MVC под ролевую модель)
|
||||
- *Обоснование:* пространства имён контроллеров (`Admin::`, `Teacher::`, `Student::`, `Api::`) изолируют ролевые интерфейсы, упрощают маршрутизацию и авторизацию — естественная техническая поддержка вузовской ролевой модели (студент / преподаватель / куратор / деканат / администратор).
|
||||
- *Раздел:* архитектура контроллеров и авторизация.
|
||||
|
||||
### 2.8 CSS: Tailwind CSS (vs Bootstrap)
|
||||
- *Обоснование:* utility-first подход даёт существенно меньший production-бандл за счёт JIT-purge (по отраслевым обзорам — на 60–70% меньше, чем production-CSS Bootstrap), полную кастомизацию через `tailwind.config.js` и отсутствие навязанного "вида Bootstrap"; нативная интеграция с Rails 7 (`rails new myapp --css tailwind`). Tailwind не тянет JS-компоненты (Bootstrap поставляет ~20 КБ JS).
|
||||
- *Честный контр-аргумент:* более крутая кривая обучения и "шумная" разметка; Bootstrap быстрее для прототипа за счёт готовых компонентов и CDN-подключения.
|
||||
- *Раздел:* выбор UI-фреймворка.
|
||||
|
||||
### 2.9 SSO / CAS (Central Authentication Service)
|
||||
- *Обоснование:* CAS — протокол единого входа (SSO), при котором приложение **никогда не видит пароль** пользователя: аутентификация выполняется на доверенном центральном сервере, который выдаёт одноразовый service ticket, валидируемый приложением. CAS отвечает за аутентификацию, а **авторизация** — на стороне приложения (часто через атрибуты LDAP). Разработан в Yale University, ныне сопровождается Apereo Foundation; есть множество клиентских библиотек. Снижает риск фишинга за счёт единообразного входа.
|
||||
- *Раздел:* интеграция с корпоративной системой аутентификации МИФИ.
|
||||
|
||||
### 2.10 Академические источники по QR-посещаемости и ЭЖ вуза
|
||||
- **Nuhi A., Memeti A., Imeri F., Çiço B.** "Smart Attendance System using QR Code" // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020, pp. 1–4. **DOI: 10.1109/MECO49872.2020.9134225** (IEEE Xplore). — прямое обоснование QR-подхода для учёта посещаемости в вузе.
|
||||
- **Глуховский К.С., Пирожков Р.В., Цвелик Е.А.** "Электронный журнал как элемент цифровой трансформации вуза" // Инженерный вестник Дона. 2021. №5 (URL ivdon.ru, ст. 6978; зеркало CyberLeninka). — отраслевой аналог в **ВИТИ НИЯУ МИФИ** (электронный дневник посещаемости/успеваемости как модуль ЭИОС); особо ценен ведомственной релевантностью.
|
||||
- Дополнительно (CyberLeninka, для контекста методов): "Система учёта посещаемости студентов на основе распознавания лиц" (RetinaFace/ResNet); "Методика автоматизации контроля посещаемости очных занятий…" (кафедра ИКТ РХТУ им. Д.И. Менделеева, Google-таблицы + QR-сканер).
|
||||
- Прочие IEEE по теме (для расширения обзора методов): "Class Attendance Recording using QR Code via Smartphone" (DOI 10.1109/...8912099); "Online Attendance Monitoring System Using QR Code (OAMS)".
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
1. **Часть 1 оформить сравнительной таблицей** (приведена выше): столбцы — QR-self-service / SSO-CAS / Outbox / ролевая модель / on-premise / open-source. Это наглядно демонстрирует незакрытую нишу и служит логическим мостиком к постановке задачи.
|
||||
2. **Для каждого тех-решения — минимум один авторитетный источник.** Для Outbox и CAS использовать первичные источники (microservices.io / Chris Richardson; Apereo/Yale), для QR — IEEE (Nuhi et al., 2020), для СУБД — рецензируемый MDPI-бенчмарк (Salunke & Ouda, 2024).
|
||||
3. **Усилить русскоязычную базу под требования РИНЦ/ВАК:** к подтверждённым (Глуховский 2021; Даньшин 2019) добавить с eLibrary 2–3 статьи по паттернам Rails/Service Objects и по СУБД; для статьи Даньшина (2019) **верифицировать журнал, номер и страницы** на CyberLeninka/eLibrary перед финальным оформлением.
|
||||
4. **Чётко разделить типы источников** в списке литературы: рецензируемые научные (IEEE, MDPI, CyberLeninka/ВАК) vs технические/отраслевые (официальная документация Rails, Microsoft Learn, D2L, Apereo). Для коммерческих систем указывать **дату обращения** (функции Teams Premium и Google Education Plus меняются).
|
||||
5. **Пороговые критерии, меняющие выводы:** если бы существовал продукт с нативным CAS-коннектором МИФИ + QR-self-service + документированным Outbox/идемпотентным экспортом в реестры — разработка собственной системы была бы неоправданна; ни один из рассмотренных аналогов этому набору не удовлетворяет, что и фиксирует обоснованность работы.
|
||||
|
||||
## Caveats
|
||||
- **Небиблиометричность части источников.** Материалы по Hotwire, Tailwind, Sidekiq и Service Objects — преимущественно официальная документация и технические блоги, а не рецензируемые публикации; в УИР их следует помечать как технические/отраслевые источники, а научную аргументацию строить вокруг рецензируемых работ (IEEE, MDPI, ВАК/РИНЦ).
|
||||
- **Противоречивость бенчмарков СУБД.** PostgreSQL уверенно выигрывает на сложных транзакциях и в цитируемом бенчмарке Salunke & Ouda (до ~13× на больших выборках), однако на простых OLTP-SELECT MySQL в ряде независимых тестов опережает PostgreSQL на 20–30%; нельзя утверждать абсолютное превосходство — выбор мотивирован транзакционной целостностью и типами данных.
|
||||
- **Производительность Ruby/Rails** исторически ниже, чем у оптимизированного PHP/Python; обоснование Rails строится на скорости разработки и DX, а не на "сырой" скорости рантайма, — это важно сформулировать честно.
|
||||
- **Неполные библиографические поля** статьи Даньшина (2019): подтверждены автор, название, год; журнал/номер/страницы требуют верификации на первоисточнике. Для статьи Глуховского и др. (2021) журнал "Инженерный вестник Дона" — онлайн-издание, использующее номера статей (ст. 6978), без классической пагинации и DOI.
|
||||
- **Изменчивость функций коммерческих систем.** Привязки тарифов (Teams Premium, Google Education Plus / Teaching and Learning Upgrade) и набор функций периодически меняются — в работе обязательно указывать дату обращения к источнику.
|
||||
@@ -1,223 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-06-10
|
||||
aliases: []
|
||||
---
|
||||
|
||||
# Система контроля версий. Знакомство с Git
|
||||
|
||||
## Git
|
||||
|
||||
Неоспоримыми преимуществами Git являются:
|
||||
|
||||
- Высокая производительность.
|
||||
- Безопасность.
|
||||
- Гибкость в распределенных системах.
|
||||
- Прекрасные возможности для командной работы.
|
||||
|
||||
### Производительность
|
||||
|
||||
Высокая производительность Git обусловлена подходом по оптимизации внутренних процедур и использованию анализа содержимого файлов Git работает с файлами, храня объекты с содержимым каталога и метаданными их версий.
|
||||
|
||||
### Безопасность
|
||||
|
||||
Безопасность при работе с Git обеспечивается целостностью исходного кода и применением алгоритма шифрования SHA1.
|
||||
|
||||
Использование Git гарантирует подлинность истории изменений и защищает исходный код от тайного внесения изменений.
|
||||
|
||||
### Гибкость
|
||||
|
||||
Гибкость при работе с Git достигается за счет поддержки линейных и нелинейных циклов разработки, совместимости со множеством других информационных систем и популярных протоколов.
|
||||
|
||||
### Возможности для командной работы
|
||||
|
||||
Git обладает впечатляющими возможностями для командной работы за счет поддержки множества разнообразных моделей управления исходным кодом, удовлетворяющих нужды больших и маленьких команд, простых и сложных распределенных проектов
|
||||
|
||||
## Часть 3. Модели управления исходным кодом
|
||||
|
||||
Работа с версиями исходного кода в Git построена на основе использования:
|
||||
|
||||
- Коммитов (Commits).
|
||||
- Веток (Branches).
|
||||
- Слияния веток (Merge).
|
||||
- Сравнения версий (Diff).
|
||||
|
||||
Большой популярностью до сих пор пользуется модель под названием Gitflow.
|
||||
|
||||
### Gitflow
|
||||
|
||||
**Gitflow** — модель ветвления в Git, в которой используются основные ветки (Main, Кelease, Вevelop) и функциональные ветки (Feature).
|
||||
|
||||
В качестве основных веток в Gitflow часто используются:
|
||||
|
||||
- Main (Ex. master).
|
||||
- Release.
|
||||
- Develop (Dev).
|
||||
|
||||
В ветке Main хранится официальная история релизов, в Release ветках концентрируется функционал готово к выпуску релиза продукта, а ветка Develop предназначена для разработки функционала.
|
||||
|
||||
В качестве функциональных веток в `Gitflow` используются *Feature* ветки, ответвленные от основной ветки *Develop*.
|
||||
|
||||
Работа над каждым новым функционалом ведется командой в собственной *Feature-ветке*.
|
||||
После завершения разработки функционала, каждая *Feature-ветка* **сливается** с *Develop-веткой*.
|
||||
|
||||
Когда в *Develop-ветке* оказывается достаточно функционала для выпуска нового релиза, на основе *Develop-ветки* создается ветка **Release**.
|
||||
|
||||
После прохождения всех тестов и проверок, Release-ветка сливается с остальными основными ветками — Main и Develop.
|
||||
|
||||
**Весь цикл разработки в модели Gitflow можно визуализировать** **следующим образом:**
|
||||
|
||||
|
||||
|
||||
**Модель Gitflow обладает и недостатками:**
|
||||
|
||||
- Не лучшая совместимость с современными процессами CI/CD.
|
||||
- Не подходит для рабочих процессов, основывающихся на подходах, отличных от регулярного выпуска релизов.
|
||||
- Потенциально запутанная схема веток и трудности в восстановлении историчности их слияний в сложных проектах.
|
||||
|
||||
На данный момент, Gitflow является *недостаточно универсальной моделью* рабочего процесса разработки и считается **устаревшей**.
|
||||
|
||||
Предпочтительной для современных процессов разработки является модель магистральных рабочих процессов (TBD).
|
||||
|
||||
### TBD
|
||||
|
||||
**TBD (Trunk Based Development)** — альтернативная модель управления исходным кодом в Git на основе ветвления, пришедшая на смену устаревшей модели Gitflow.
|
||||
|
||||
Модель TBD основана на принципе использования одной главной ветки, называемой “магистралью” (Trunk).
|
||||
|
||||
Вся работа над новым функционалом ведется разработчиками именно в магистральной ветке, что исключает трудности, связанные со слиянием и неработающими сборками.
|
||||
|
||||
Команда разработки, ведущая работу над новым функционалом, сохраняет свои изменения только в Trunk-ветку и обеспечивает непрерывную сборку, тестирование и доставку нового функционала, не привязываясь к срокам и частоте выпуска релизов.
|
||||
|
||||
При использовании модели TBD и регулярном добавлении в основную Trunk-ветку функционала, а также настроенных стабильных процессов сборки и доставки продукта (CI/CD), выпустить релиз можно практически в любой момент.
|
||||
|
||||
**Модель TBD можно визуализировать следующим образом:**
|
||||
|
||||
|
||||
|
||||
Модель TDB быстро завоевала популярность в разветвленных проектах и прекрасно зарекомендовала себя в распределенных больших командах разработки за счет своей понятности, динамичности и совместимости с CI/CD-процессами.
|
||||
|
||||
## Часть 4. Знакомство с Gitlab
|
||||
|
||||
### Gitlab
|
||||
|
||||
**Gitlab** — это веб-приложение, обеспечивающее управление репозиториями программного кода в системе контроля версий Git.
|
||||
|
||||
Установить и использовать Gitlab можно на собственном сервере или в облачной инфраструктуре.
|
||||
|
||||
Gitlab позволяет:
|
||||
|
||||
- Создавать, изменять и удалять репозитории.
|
||||
- Управлять пользователями и их правами.
|
||||
- Автоматизировать процессы CI/CD и тестирования.
|
||||
- Полнофункционально взаимодействовать с исходным кодом из веб-интерфейса.
|
||||
|
||||
Основные преимущества Gitlab:
|
||||
|
||||
- Гибкие возможности по планированию командной разработки.
|
||||
- Создание и управление проектами.
|
||||
- Построение процессов тестирования кода.
|
||||
- Непрерывная сборка и доставка (CI/CD).
|
||||
- Наблюдаемость (Observability).
|
||||
|
||||
Gitlab позволяет эффективно поддерживать и развивать выбранный вами подход по управлению исходным кодом и командной разработкой (Gitflow, TDB и другие).
|
||||
|
||||
Работа с репозиториями в Gitlab осуществляется посредством создания, изменения, управления, удаления проектов и работы с пользователями.
|
||||
|
||||
Функциональность Gitlab позволяет задействовать инструменты по управлению ветками и коммитами пользователей, обеспечивая слаженную командную работу.
|
||||
|
||||
В Gitlab реализованы инструменты для проведения следующих операций над исходным кодом:
|
||||
|
||||
- Code-review.
|
||||
- Оценка качества кода.
|
||||
- Тестирование.
|
||||
|
||||
Возможна настройка модели приемки качества исходного кода, его проверки и тестирования.
|
||||
|
||||
Gitlab обладает интегрированными инструментами, позволяющими автоматизировать рутинные операции с исходным кодом:
|
||||
|
||||
- Непрерывную сборку и доставку (CI/CD).
|
||||
- Тестирование новых версий.
|
||||
- Релизный цикл продукта.
|
||||
- Проверки по безопасности.
|
||||
|
||||
Gitlab позволяет отслеживать и обрабатывать множество важной информации о процессе разработки:
|
||||
|
||||
- Трекинг затраченного рабочего времени на разработку функционала и выпуск новых релизов.
|
||||
- Мониторинг работоспособности приложения.
|
||||
- Расширенный сбор и анализ метрик.
|
||||
|
||||
## Часть 5. Основные команды git
|
||||
|
||||
### Команды Git
|
||||
|
||||
#### `git init`
|
||||
|
||||
Создание нового Git-репозитория (преобразование существующего проекта или создание нового пустого репозитория).
|
||||
|
||||
#### `git clone`
|
||||
|
||||
Создание локальной копии удаленного Git-репозитория.
|
||||
|
||||
#### `git branch`
|
||||
|
||||
Создание отдельной ветки на основе существующей для осуществления в новой ветке процесса разработки с возможным последующим слиянием.
|
||||
|
||||
#### `git checkout`
|
||||
|
||||
Переключение между различными версиями целевого объекта (файлы, коммиты и ветки).
|
||||
|
||||
#### `git status`
|
||||
|
||||
Отображение рабочего состояния файлов в локальной копии отслеживаемого проекта.
|
||||
|
||||
#### `git add`
|
||||
|
||||
Индексирование изменений в локальной копии отслеживаемого проекта.
|
||||
|
||||
#### `git commit`
|
||||
|
||||
Подготовка к отправке в удаленный репозиторий набора проиндексированных изменений в локальном проекте.
|
||||
|
||||
#### `git push`
|
||||
|
||||
Выгрузка в удаленный репозиторий подготовленного набора проиндексированных изменений из отслеживаемой локальной копии.
|
||||
|
||||
#### `git pull`
|
||||
|
||||
Загрузка содержимого из удаленного репозитория и немедленное слияние изменений в локальный отслеживаемый репозиторий.
|
||||
|
||||
#### `git restore`
|
||||
|
||||
Отмена индексации изменений в локальном репозитории.
|
||||
|
||||
#### `git revert`
|
||||
|
||||
Отмена подготовленных к отправке проиндексированных изменений в локальном репозитории с сохранением истории.
|
||||
|
||||
#### `git merge`
|
||||
|
||||
Слияние ответвления (ветки ответвленной с веткой изначальной). Изменения часто проходят процедуру согласования с участниками команды разработки через механизм merge Request.
|
||||
|
||||
#### `git rebase`
|
||||
|
||||
Операция, подобная слиянию (Git merge).
|
||||
|
||||
**Команды Git merge и Git rebase решают одну и ту же проблему –** **слияние одной ветки в другую, но делают это по-разному.**
|
||||
|
||||
**Git merge** — это неразрушающая операция, существующие ветки никак не изменяются.
|
||||
|
||||
|
||||
|
||||
**Git rebase** — это операция фактического перебазирования ответвленной ветки в исходную, с созданием идеальной линейной истории проекта.
|
||||
|
||||
|
||||
|
||||
Золотое правило перебазирования:
|
||||
|
||||
**“Never rebase while you're on a public branch”** (никогда не используйте git rebase в публичных репозиториях) Если вы предпочитаете иметь чистую линейную историю без ненужных коммитов слияния – используйте Git rebase.
|
||||
|
||||
Если вам необходимо сохранить полную историю проекта и избежать перезаписи публичных коммитов – используйте команду Git merge.
|
||||
@@ -1,251 +0,0 @@
|
||||
---
|
||||
title: "УИР: Обзор систем учёта посещаемости студентов НИЯУ МИФИ"
|
||||
status: stable
|
||||
type: document
|
||||
tags:
|
||||
- уир
|
||||
- мифи
|
||||
- разработка
|
||||
created: 2026-06-08
|
||||
updated: 2026-06-09
|
||||
---
|
||||
|
||||
# УИР\_Сводный\_вариант
|
||||
|
||||
## Введение
|
||||
|
||||
Цифровизация управления учебным процессом требует от университета не только электронного хранения данных, но и прозрачной, проверяемой фиксации факта присутствия студентов на занятиях. Согласно исследованию [\[Электронный журнал как элемент цифровой трансформации вуза\]](https://ivdon.ru/back_media/uploads/article/pdf/IVD_47__4_glukhovsky_pirozhkov_tsvelik.pdf_048169e65f.pdf) средний балл студента обратно зависит от процента пропущенных им занятий. В крупном техническом вузе, традиционные бумажные журналы и разрозненные электронные таблицы создают существенные организационные ограничения: увеличивают нагрузку на преподавателей, повышают риск потери или несвоевременного внесения данных, затрудняют оперативное получение статистики деканатами и не позволяют автоматически синхронизировать сведения с внутренними информационными системами университета.
|
||||
|
||||
Проблема особенно актуальна для НИЯУ МИФИ, поскольку университет располагает развитой корпоративной IT-инфраструктурой: единой системой аутентификации, внутренними академическими реестрами, расписанием и ролевыми моделями доступа. Готовая система учёта посещаемости для такого окружения должна не просто фиксировать отметку, а работать как часть корпоративного контура: использовать существующие учётные записи, корректно разделять роли студентов, преподавателей, кураторов, деканата и администраторов, а также гарантированно передавать события посещаемости во внешние реестры.
|
||||
|
||||
Дополнительную актуальность задаче придаёт требование прозрачности:
|
||||
1) студент должен иметь возможность видеть собственную историю посещений до окончания семестра;
|
||||
2) преподаватель должен иметь быстрый механизм фиксации присутствия и возможность ручной корректировки спорных случаев;
|
||||
3) куратор и деканат должны получать сводную аналитику без ручной консолидации журналов.
|
||||
|
||||
Проведённый анализ показывает, что массовые российские и зарубежные решения не сочетают одновременно ключевые свойства, необходимые корпоративному вузу: QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO на базе CAS, гарантированную синхронизацию с внутренними реестрами и полноценную вузовскую ролевую модель. Это обосновывает необходимость разработки собственной системы.
|
||||
|
||||
**Целью** настоящей работы является определение подхода к разработке веб-приложения для автоматизированного учёта посещаемости студентов НИЯУ МИФИ, обеспечивающего прозрачную фиксацию присутствия на занятиях, интеграцию с корпоративными системами университета и надёжную синхронизацию данных с внешними реестрами.
|
||||
|
||||
**Объект исследования** — процесс учёта посещаемости студентов в НИЯУ МИФИ, включающий взаимодействие студентов, преподавателей, кураторов, деканата и администраторов в рамках учебного процесса.
|
||||
|
||||
**Предмет исследования** — методы и инструменты автоматизации фиксации посещаемости студентов, архитектурные паттерны и технологии для реализации интегрированного корпоративного веб-приложения.
|
||||
|
||||
**Задачи работы:**
|
||||
|
||||
1. Провести обзор существующих аналогов систем учёта посещаемости и выявить их ограничения применительно к условиям НИЯУ МИФИ.
|
||||
2. Проанализировать основные методы технической фиксации факта посещения студентом занятия.
|
||||
3. Обосновать выбор QR-кодов как основного механизма самоотметки.
|
||||
4. Изучить научные и отраслевые источники по автоматизированному учёту посещаемости, производительности СУБД и архитектурным паттернам надёжной синхронизации.
|
||||
5. Определить технологический стек и архитектурные решения для разработки системы.
|
||||
|
||||
**Методологическую основу** исследования составляет системный анализ существующих программных решений и технологических подходов в области автоматизации учёта посещаемости. В работе используются сравнительный анализ коммерческих и открытых систем, анализ методов фиксации посещаемости, обзор научных публикаций и проверка технических решений по официальной документации.
|
||||
|
||||
**Практическая значимость** работы заключается в формировании обоснованной методической базы для последующей разработки собственной системы. Результаты анализа позволяют избежать типовых ошибок: зависимости от внешнего SaaS-провайдера, отсутствия гарантий доставки данных, невозможности интеграции с корпоративным SSO и смешения ролей пользователей.
|
||||
|
||||
## 1. Обзор существующих систем учёта посещаемости студентов
|
||||
|
||||
Перед проектированием новой системы необходимо оценить существующие решения: российские электронные журналы и ERP-платформы, зарубежные LMS и сервисы видеоконференций, специализированные QR/SaaS-сервисы и открытые прототипы.
|
||||
Цель анализа — определить, можно ли закрыть требования НИЯУ МИФИ готовым продуктом либо разработка собственной системы является обоснованной.
|
||||
|
||||
### 1.1. Российские системы
|
||||
|
||||
**Система «Учёт посещаемости студентов» ВВГУ.** Это внутренняя разработка Департамента цифрового развития Владивостокского государственного университета. По описанию ВВГУ, преподаватель во время занятия предоставляет студентам QR-код, при сканировании которого фиксируется присутствие; также возможна ручная отметка преподавателем. Система близка к целевому сценарию по способу фиксации, но является закрытым внутренним решением одного вуза. Для НИЯУ МИФИ она не закрывает требования интеграции с CAS, внешними академическими реестрами и собственной ролевой моделью. [Источник](https://www.vvsu.ru/news/201301/)
|
||||
|
||||
**БАРС.Образование / ЭЖД Мос.ру** Платформы ориентированы на электронный журнал и дневник школьного сегмента: оценки, темы уроков, расписание, домашние задания, посещаемость и отчётность. Ключевое ограничение состоит в самой модели предметной области: «школа — класс — родитель» плохо переносится на вузовскую структуру «поток — группа — подгруппа — кафедра — деканат». Посещаемость в таких системах, как правило, фиксируется учителем вручную; студенческая QR-самоотметка на очном занятии и интеграция с CAS вуза не являются базовым сценарием. [Источник](https://барс-образование.рф/about/)
|
||||
|
||||
**1С:Университет.** Решение на платформе «1С:Предприятие 8.3» предназначено для комплексной автоматизации процессов вуза: приёмной кампании, учебных планов, контингента, нагрузки преподавателей, успеваемости и посещаемости. Его сильная сторона — широкий охват административных процессов. Ограничение для данной работы — избыточность ERP-подхода и зависимость от экосистемы 1С. Для задачи точечной разработки веб-системы QR-самоотметки с CAS и REST/Outbox-синхронизацией такое решение не является оптимальным.
|
||||
|
||||
**iSpring LMS (ранее iSpring Learn).** Платформа ориентирована на корпоративное обучение: онлайн-курсы, тесты, тренинги, отчёты, API, SSO и on-premise-развёртывание. Функции посещаемости привязаны к тренингам и корпоративным мероприятиям, а не к вузовскому расписанию очных занятий. Система не предоставляет целевую модель «поток — группа — занятие — преподаватель — студент» и не решает задачу гарантированной синхронизации посещаемости с академическими реестрами НИЯУ МИФИ.
|
||||
|
||||
**Дневник.ру, ЭлЖур, Сетевой город. Образование.** Эти решения также относятся преимущественно к школьному электронному журналу. Их базовые сценарии строятся вокруг класса, учителя, родителей и ручной отметки посещаемости. Для корпоративного технического университета они не закрывают требования по CAS, QR-самоотметке, вузовской ролевой модели и on-premise-контролю данных.
|
||||
|
||||
### 1.2. Зарубежные системы
|
||||
|
||||
**Microsoft Teams.** В Teams поддерживаются отчёты о посещаемости онлайн-встреч: время входа, выхода, длительность участия и, в отдельных тарифах, показатели вовлечённости. Это полезно для дистанционных занятий, но не эквивалентно фиксации присутствия в аудитории. Кроме того, отчёты зависят от организатора встречи и не являются корпоративным реестром очной посещаемости. Для задачи НИЯУ МИФИ Teams не предоставляет QR-механизм, CAS-интеграцию и синхронизацию с внутренними академическими системами.
|
||||
|
||||
**Google Classroom / Google Meet.** Google Meet поддерживает отчёты о посещаемости для определённых редакций Google Workspace, включая Education Plus и Teaching and Learning Upgrade. Однако речь идёт о посещаемости онлайн-встреч, а не очных занятий. Google Classroom сам по себе не решает задачу аудиторной QR-самоотметки и не интегрируется с внутренними реестрами НИЯУ МИФИ в требуемой архитектуре.
|
||||
|
||||
**Brightspace (D2L).** Brightspace содержит инструмент Attendance, позволяющий создавать реестры посещаемости и отмечать статусы студентов. По своей природе базовый инструмент является электронным журналом внутри LMS. QR-самоотметка возможна через сторонние интеграции, например Qwickly Attendance, но это требует внедрения внешнего модуля и всей LMS-среды. Для НИЯУ МИФИ такой путь избыточен и не решает нативную интеграцию с CAS и внутренними реестрами.
|
||||
|
||||
### 1.3. Сравнительный анализ аналогов
|
||||
|
||||
Сравнительная оценка систем по критериям, важным для НИЯУ МИФИ, представлена в Таблице 1.
|
||||
|
||||
| Система | QR-self-service | SSO/CAS | Ролевая модель вуза | On-premise / контроль данных | Итог |
|
||||
| ------------------------ | :--------------: | :-------------------: | :-----------------: | :--------------------------: | ------------------------------------------------- |
|
||||
| ВВГУ «Учёт посещаемости» | + | - | Частично | + | Не переносится в МИФИ |
|
||||
| БАРС.Образование | - | - | Школьная | Зависит от внедрения | Не подходит в силу нацеленности на школьный фрмат |
|
||||
| 1С:Университет | - | - | + | + | Избыточная ERP-платформа |
|
||||
| iSpring LMS | - | SSO, не интегрируется | Корпоративная | + | Не подходит для вузовской QR-самоотметки |
|
||||
| Microsoft Teams | - | Azure AD | - | - | Только онлайн-встречи |
|
||||
| Google Meet/Classroom | - | Google | - | - | Только онлайн-встречи |
|
||||
| Brightspace (D2L) | Через интеграции | Зависит от внедрения | LMS | Зависит от контракта | Избыточно |
|
||||
| **Attendance MEPhI** | **+** | **(CAS МИФИ)** | **+** | **+** | **Целевое решение** |
|
||||
|
||||
*Таблица 1 — Сравнительная оценка систем учёта посещаемости*
|
||||
|
||||
Вывод по разделу: готового продукта, который одновременно обеспечивает QR-самоотметку очной посещаемости, интеграцию с CAS МИФИ, гарантированную синхронизацию с внутренними реестрами, полную вузовскую ролевую модель и контроль данных на стороне университета, не выявлено. Следовательно, разработка собственной системы является обоснованной.
|
||||
|
||||
## 2. Анализ методов фиксации посещаемости студентов
|
||||
|
||||
Для выбора основного механизма фиксации посещаемости необходимо сравнить возможные методы по инфраструктурным затратам, скорости, достоверности, правовым рискам и применимости в условиях многокорпусного университета.
|
||||
|
||||
**Ручная отметка преподавателем.** Традиционный метод не требует дополнительной инфраструктуры, но плохо масштабируется на крупные потоки. Он увеличивает нагрузку на преподавателя, создаёт задержку между фактом посещения и появлением данных в системе, а также оставляет риск ошибок при переносе данных.
|
||||
|
||||
**RFID/NFC-карты.** Метод позволяет быстро фиксировать предъявление студенческой карты или пропуска. Ограничения связаны с необходимостью оборудования аудиторий считывателями, стоимостью внедрения и риском передачи карты другому лицу. Кроме того, отметку нужно связать не просто с входом в корпус, а с конкретной дисциплиной, занятием и преподавателем.
|
||||
|
||||
**QR-коды.** Преподаватель генерирует QR-код для конкретного занятия, студент сканирует его смартфоном и проходит отметку через аутентифицированную сессию. Метод не требует установки считывателей в аудиториях, быстро внедряется и естественно связывается с расписанием, преподавателем и конкретной парой. Защита от злоупотреблений обеспечивается ограниченным временем жизни QR-кода, одноразовым токеном и проверкой личности через CAS.
|
||||
|
||||
**СКУД.** Системы контроля и управления доступов исторически являлись одним из самых надежных способов фиксации посещения, но использование их, как единственного метода — недостаточно, так как проход через турникет не гарантирует присутствие на лекции, но целесообразно использовать такие системы, как дополнительную проверку.
|
||||
|
||||
**Биометрическая идентификация.** Биометрия обеспечивает высокий уровень достоверности, но создаёт существенные правовые и организационные риски. Обработка биометрических персональных данных в РФ регулируется статьей 11 Федерального закона № 152-ФЗ «О персональных данных» и требует отдельного правового обоснования. Для учебного проекта и массового внедрения в аудиториях этот метод избыточен.
|
||||
|
||||
**Геолокация.** Геолокационная отметка не требует аудиторного оборудования, но точности GPS и Wi-Fi-позиционирования может быть недостаточно для различения смежных аудиторий. Кроме того, постоянная или регулярная обработка местоположения студентов повышает чувствительность решения с точки зрения приватности.
|
||||
|
||||
| Метод | Инфраструктура | Скорость | Защита от подмены | Правовые риски | Применимость в МИФИ |
|
||||
| -------------- | ------------------------------- | ------------------------- | ----------------------------- | -------------- | -------------------------------------- |
|
||||
| Ручная отметка | Минимальная | Низкая на больших потоках | Низкая | Минимальные | Резервный сценарий |
|
||||
| RFID/NFC | Высокие затраты на считыватели | Высокая | Средняя | Низкие | Ограниченная |
|
||||
| **QR-коды** | **Минимальная** | **Высокая** | **Средняя при токенах и CAS** | **Низкие** | **Оптимальная** |
|
||||
| СКУД | Затраты на оборудование | Высокая | Высокая | Низкие | Уже используется (возможна интеграция) |
|
||||
| Биометрия | Высокие затраты на оборудование | Высокая | Высокая | Высокие | Не рекомендуется |
|
||||
| Геолокация | Минимальная | Высокая | Низкая/средняя | Средние | Усложненная |
|
||||
|
||||
*Таблица 2 — Сравнительная оценка методов фиксации посещаемости*
|
||||
|
||||
Основным методом для системы целесообразно выбрать QR-коды. Ручная отметка преподавателем должна сохраниться как резервный механизм для спорных ситуаций, технических сбоев и студентов без доступа к смартфону в момент занятия.
|
||||
|
||||
---
|
||||
|
||||
## 3. Обзор существующих исследований
|
||||
|
||||
**QR-системы посещаемости.** В работе A. Nuhi, A. Memeti, F. Imeri и B. Çiço "Smart Attendance System using QR Code" предложена система учёта посещаемости на основе QR-кодов для высшего образования. Авторы указывают на типовые проблемы ручной регистрации: трудоёмкость, затраты времени и сложность работы с большими группами. Исследование подтверждает применимость QR-подхода для лекций и практических занятий, но описанная система функционирует автономно и не рассматривает интеграцию с корпоративным SSO, академическими реестрами и механизмами гарантированной доставки событий.
|
||||
|
||||
**Электронный журнал в структуре НИЯУ МИФИ.** Работа К.С. Глуховского, Р.В. Пирожкова и Е.А. Цвелика посвящена электронному журналу как элементу цифровой трансформации вуза. Для настоящей работы она важна тем, что рассматривает близкий контекст: электронную информационно-образовательную среду, импорт академических данных, разграничение ролей и отчётность. Ограничение такого подхода — отсутствие студенческой QR-самоотметки и описанного механизма надёжной синхронизации событий посещаемости.
|
||||
|
||||
**Практический опыт автоматизации очной посещаемости.** В публикации о методике автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий рассматривается переход от бумажной фиксации к цифровому учёту с использованием QR-инструментов и таблиц. Материал подтверждает практическую проблему крупных потоков и положительный эффект делегирования отметки студентам. При этом использование внешних облачных таблиц не подходит для целевой системы НИЯУ МИФИ из-за требований к контролю персональных данных и интеграции с внутренними системами.
|
||||
|
||||
**Производительность СУБД.** В статье S.V. Salunke и A. Ouda "A Performance Benchmark for the PostgreSQL and MySQL Databases" сравниваются PostgreSQL и MySQL на операциях INSERT, SELECT и UPDATE. В условиях эксперимента PostgreSQL показал преимущество на ряде транзакционных операций. Для "Attendance MEPhI" это важно, поскольку фиксация посещаемости создаёт пиковую нагрузку в начале занятия и требует атомарной записи основной отметки вместе с Outbox-событием. При этом вывод не следует трактовать как абсолютное превосходство PostgreSQL во всех сценариях: результаты бенчмарков зависят от профиля нагрузки, объёма данных, индексов и конфигурации.
|
||||
|
||||
**Архитектурный паттерн Transactional Outbox.** К. Ричардсон и AWS Prescriptive Guidance описывают паттерн Transactional Outbox, решающий проблему "dual write": несогласованности между записью в базу данных и отправкой события во внешнюю систему. Суть паттерна состоит в том, что событие записывается в outbox-таблицу в той же транзакции, что и бизнес-данные, а отдельный процесс-релей асинхронно публикует событие получателям. Паттерн обеспечивает доставку at-least-once, поэтому принимающая сторона должна быть идемпотентной.
|
||||
|
||||
Вывод по разделу: научные и отраслевые источники подтверждают применимость QR-кодов для учёта посещаемости, важность интеграции с вузовскими справочниками и необходимость архитектурного механизма надёжной синхронизации. Недостатки существующих подходов учитываются в проектируемой системе через CAS-аутентификацию, ролевую модель, PostgreSQL и Transactional Outbox.
|
||||
|
||||
---
|
||||
|
||||
## 4. Выбор технологического стека
|
||||
|
||||
Выбор технологического стека должен учитывать не только производительность отдельных компонентов, но и соответствие предметной области: быстрый CRUD, интеграция с SSO, работа с расписанием и группами, массовые отметки в начале занятий, генерация отчётов и надёжная доставка событий во внешние реестры.
|
||||
|
||||
### 4.1. Веб-фреймворк и архитектура приложения
|
||||
|
||||
Для реализации бэкенда выбран **Ruby on Rails 7**. Rails реализует архитектурный паттерн MVC, следует принципам Convention over Configuration и DRY, предоставляет зрелую ORM Active Record и ускоряет разработку типовых CRUD-компонентов: занятий, групп, студентов, преподавателей, ролей и отчётов.
|
||||
|
||||
Альтернативами могли быть Django, Laravel и Spring Boot. Django обладает зрелой экосистемой Python, но для server-side realtime-обновлений обычно требует дополнительных компонентов либо отдельного SPA-фронтенда. Laravel удобен для CRUD и имеет Livewire, но не соответствует текущему Ruby-стеку проекта. Spring Boot силён в корпоративной Java-разработке, но увеличивает объём шаблонного кода и замедляет итерации для относительно компактного веб-приложения.
|
||||
|
||||
Ограничение Rails — более низкая "сырая" вычислительная производительность Ruby по сравнению с Java и некоторыми другими рантаймами. В данной задаче это не является определяющим фактором: основная нагрузка связана с I/O, транзакциями БД, фоновыми задачами и отчётами, а не с тяжёлыми вычислениями в веб-процессе.
|
||||
|
||||
### 4.2. Фронтенд-архитектура: Hotwire
|
||||
|
||||
Для фронтенда выбран **Hotwire**: Turbo Drive, Turbo Frames, Turbo Streams и Stimulus. Hotwire использует подход HTML over the wire: сервер возвращает HTML-фрагменты, а не JSON для последующей сборки интерфейса на клиенте. Это позволяет получить отзывчивый интерфейс без отдельного React/Vue SPA.
|
||||
|
||||
Для системы учёта посещаемости такой подход подходит естественно. Основные действия пользователя — открыть список занятий, сгенерировать QR-код, отметить присутствие, обновить статус студента, посмотреть отчёт. Эти сценарии хорошо ложатся на Turbo Frames и Turbo Streams: можно точечно обновлять строки таблиц, счётчики и статусы без полной перезагрузки страницы.
|
||||
|
||||
Ограничение Hotwire проявилось бы в приложении со сложным клиентским состоянием, например в графическом редакторе или интерфейсе с большим количеством drag-and-drop логики. Для "Attendance MEPhI" таких требований нет, поэтому отказ от отдельного SPA снижает сложность разработки и поддержки.
|
||||
|
||||
### 4.3. СУБД: PostgreSQL
|
||||
|
||||
В качестве основной СУБД выбрана **PostgreSQL**. Для проекта важны ACID-транзакции, конкурентные записи, развитые индексы, строгая типизация, JSONB для метаданных событий и зрелые механизмы работы с ролями и схемами.
|
||||
|
||||
PostgreSQL особенно важен для реализации Transactional Outbox: отметка посещаемости и запись события синхронизации должны выполняться атомарно. Если запись отметки прошла успешно, но событие не было создано, внешние реестры могут остаться несогласованными. Если событие было отправлено без успешной записи отметки, возникнет обратная ошибка. Транзакционная модель PostgreSQL позволяет избежать этих сценариев.
|
||||
|
||||
Сравнение с MySQL не должно строиться только на тезисе "PostgreSQL быстрее". Корректнее указать, что в цитируемом бенчмарке Salunke и Ouda PostgreSQL показал сильные результаты на ряде операций, а выбор для данного проекта дополнительно обоснован транзакционной целостностью и возможностями типов данных.
|
||||
|
||||
### 4.4. Фоновые задачи: Sidekiq и Redis
|
||||
|
||||
Для фоновой обработки выбран **Sidekiq** с **Redis** в качестве хранилища очередей. Sidekiq использует многопоточную модель и хорошо интегрируется с Rails-приложениями.
|
||||
|
||||
В проектируемой системе Sidekiq решает три задачи:
|
||||
|
||||
1. Выполнение Outbox-релея: периодическая обработка необработанных событий посещаемости и отправка их во внешние реестры.
|
||||
2. Импорт справочников: загрузка расписания, групп, студентов и преподавателей из внутренних API без блокировки веб-интерфейса.
|
||||
3. Генерация отчётов: подготовка сводок для деканата и кураторов в фоне.
|
||||
|
||||
Redis используется как очередь фоновых задач и может дополнительно применяться для кэширования часто запрашиваемых справочников. При этом Redis не является источником истины для посещаемости: все критичные данные должны храниться в PostgreSQL.
|
||||
|
||||
### 4.5. Аутентификация: CAS
|
||||
|
||||
Для аутентификации используется **CAS (Central Authentication Service)**. CAS — билетный протокол единого входа: пользователь вводит логин и пароль на доверенном CAS-сервере, после чего приложение получает service ticket и валидирует его. Веб-приложение не хранит и не обрабатывает пароль пользователя.
|
||||
|
||||
Для НИЯУ МИФИ это принципиально важно. Система посещаемости должна использовать существующие учётные записи студентов и преподавателей, не создавая отдельную базу паролей. CAS отвечает за аутентификацию, а авторизация остаётся задачей приложения: после входа система должна определить роль пользователя и доступные интерфейсы.
|
||||
|
||||
### 4.6. Архитектурные паттерны
|
||||
|
||||
**Service Objects.** Сложная бизнес-логика выносится из контроллеров и моделей в отдельные сервисные объекты. Примеры операций: импорт студентов, импорт расписания, генерация QR-кода, фиксация посещения, создание Outbox-события. Такой подход упрощает тестирование и снижает связанность кода.
|
||||
|
||||
**Namespaced Controllers.** Контроллеры разделяются по пространствам имён: `Admin::`, `Teacher::`, `Student::`, `Moderator::` или аналогичным. Это отражает ролевую модель в структуре приложения, упрощает маршрутизацию и снижает риск случайного смешения интерфейсов.
|
||||
|
||||
**Transactional Outbox.** При фиксации посещения приложение записывает основную отметку и событие синхронизации в одной транзакции. Затем фоновый воркер отправляет событие во внешний реестр. Если отправка не удалась, событие остаётся в outbox-таблице и будет обработано повторно. Получатель должен обеспечивать идемпотентность, например по уникальному идентификатору события.
|
||||
|
||||
### 4.7. Стилизация и деплой
|
||||
|
||||
Для стилизации выбран **Tailwind CSS**. Utility-first подход удобен для быстрого создания интерфейсов с небольшим production-бандлом и без жёсткой зависимости от визуального стиля готового UI-фреймворка. **Bootstrap 5** может использоваться точечно для готовых компонентов, если это не усложняет сборку и не создаёт конфликтов стилей.
|
||||
|
||||
Деплой целесообразно автоматизировать через **Capistrano**, так как это стандартный инструмент для Ruby/Rails-приложений с поддержкой релизов, rollback и разделения окружений. **Mise** может использоваться для фиксации версий Ruby, Node.js и сопутствующих рантаймов между локальной разработкой, CI и сервером.
|
||||
|
||||
Итоговый технологический стек:
|
||||
|
||||
| Компонент | Выбор | Обоснование |
|
||||
|---|---|---|
|
||||
| Backend | Ruby on Rails 7 | Быстрая разработка CRUD, MVC, зрелая экосистема |
|
||||
| Frontend | Hotwire (Turbo + Stimulus) | Интерактивность без отдельного SPA |
|
||||
| Database | PostgreSQL | ACID, JSONB, транзакции для Outbox |
|
||||
| Background jobs | Sidekiq + Redis | Фоновые импорты, отчёты, Outbox-релей |
|
||||
| Auth | CAS | SSO, приложение не хранит пароли |
|
||||
| UI | Tailwind CSS, точечно Bootstrap | Быстрая стилизация и готовые компоненты |
|
||||
| Deploy | Capistrano + Mise | Повторяемый деплой и контроль версий рантаймов |
|
||||
|
||||
---
|
||||
|
||||
## Заключение
|
||||
|
||||
В ходе учебно-исследовательской работы проведён анализ существующих систем учёта посещаемости, методов фиксации присутствия студентов и технологического стека для разработки системы "Attendance MEPhI".
|
||||
|
||||
Установлено, что готовые российские и зарубежные продукты не закрывают совокупность требований НИЯУ МИФИ. Школьные электронные журналы ориентированы на модель класса и ручную отметку. ERP-решения уровня 1С:Университет избыточны для задачи QR-самоотметки и завязаны на собственную экосистему. LMS и сервисы видеоконференций фиксируют либо активность внутри курса, либо участие в онлайн-встрече, но не очную посещаемость в аудитории. QR-SaaS-сервисы создают риски внешнего хранения персональных данных и vendor lock-in. Открытые прототипы не обладают промышленной надёжностью и корпоративной интеграцией.
|
||||
|
||||
Из рассмотренных методов фиксации посещаемости оптимальным признан QR-код с ограниченным временем жизни, одноразовым токеном и проверкой пользователя через CAS. Ручная отметка преподавателем должна оставаться резервным механизмом. RFID/NFC требует инфраструктурных затрат, биометрия создаёт высокие правовые риски, а геолокация недостаточно точна для аудиторного сценария и чувствительна с точки зрения приватности.
|
||||
|
||||
Выбранный стек — Ruby on Rails 7, Hotwire, PostgreSQL, Sidekiq, Redis, CAS, Tailwind CSS, Capistrano и Mise — соответствует задаче разработки корпоративного веб-приложения. Rails и Hotwire ускоряют создание интерфейсов без отдельного SPA, PostgreSQL обеспечивает транзакционную целостность, Sidekiq реализует фоновые процессы, а Transactional Outbox снижает риск потери событий при синхронизации с внешними реестрами.
|
||||
|
||||
Результаты работы формируют обоснованную теоретическую и техническую базу для реализации системы "Attendance MEPhI" в рамках последующей проектной или дипломной работы.
|
||||
|
||||
---
|
||||
|
||||
## Список использованной литературы
|
||||
|
||||
1. Nuhi A., Memeti A., Imeri F., Çiço B. Smart Attendance System using QR Code // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020. P. 1-4. DOI: 10.1109/MECO49872.2020.9134225.
|
||||
2. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. № 5. URL: https://ivdon.ru/ru/magazine/archive/n5y2021/6978 (дата обращения: 08.06.2026).
|
||||
3. Дусалин А.К., Семенов Г.Н., Скичко Е.А. Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий. URL: https://www.muctr.ru/upload/iblock/409/hd3gn9gkbrnezs3kuedj3lz18cb2oddx.pdf (дата обращения: 08.06.2026).
|
||||
4. Richardson C. Microservices Patterns: With Examples in Java. Manning Publications, 2018. 520 p.
|
||||
5. Transactional Outbox Pattern // AWS Prescriptive Guidance. URL: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html (дата обращения: 08.06.2026).
|
||||
6. Salunke S.V., Ouda A. A Performance Benchmark for the PostgreSQL and MySQL Databases // Future Internet. 2024. Vol. 16, No. 10. Article 382. DOI: 10.3390/fi16100382.
|
||||
7. Getting Started with Rails // Ruby on Rails Guides. URL: https://guides.rubyonrails.org/getting_started.html (дата обращения: 08.06.2026).
|
||||
8. Hotwire: HTML Over The Wire // Hotwire. URL: https://hotwired.dev/ (дата обращения: 08.06.2026).
|
||||
9. Sidekiq: Simple, Efficient Background Jobs for Ruby // GitHub. URL: https://github.com/sidekiq/sidekiq (дата обращения: 08.06.2026).
|
||||
10. PostgreSQL Documentation // PostgreSQL. URL: https://www.postgresql.org/docs/ (дата обращения: 08.06.2026).
|
||||
11. CAS Protocol // Apereo CAS. URL: https://apereo.github.io/cas/7.1.x/protocol/CAS-Protocol.html (дата обращения: 08.06.2026).
|
||||
12. Tailwind CSS Documentation // Tailwind CSS. URL: https://tailwindcss.com/docs (дата обращения: 08.06.2026).
|
||||
13. Bootstrap 5 Documentation // Bootstrap. URL: https://getbootstrap.com/docs/5.3/ (дата обращения: 08.06.2026).
|
||||
14. Capistrano: Remote Server Automation and Deployment Tool // Capistrano. URL: https://capistranorb.com/ (дата обращения: 08.06.2026).
|
||||
15. Mise: Polyglot Runtime Manager // Mise. URL: https://mise.jdx.dev/ (дата обращения: 08.06.2026).
|
||||
16. Система "Учёт посещаемости студентов" // Электронный кампус ВВГУ. URL: https://www.vvsu.ru/e-campus/news/201301/ (дата обращения: 08.06.2026).
|
||||
17. БАРС.Образование — Электронная Школа: описание программного обеспечения // БАРС Груп. URL: https://bars.group/wp-content/uploads/2024/05/opisanie-elektronnaya-shkola.pdf (дата обращения: 08.06.2026).
|
||||
18. 1С:Университет — Возможности // 1С. URL: https://solutions.1c.ru/catalog/university/features (дата обращения: 08.06.2026).
|
||||
19. iSpring LMS (iSpring Learn): платформа для онлайн-обучения // iSpring. URL: https://www.ispring.ru/ispring-learn (дата обращения: 08.06.2026).
|
||||
20. On-Premise LMS for Effective & Secure Employee Training // iSpring Solutions. URL: https://www.ispringsolutions.com/ispring-learn/on-premise-lms (дата обращения: 08.06.2026).
|
||||
21. Manage meeting attendance reports in Microsoft Teams // Microsoft Support. URL: https://support.microsoft.com/en-US/teams/meetings/manage-meeting-attendance-reports-in-microsoft-teams (дата обращения: 08.06.2026).
|
||||
22. Track attendance & view Live stream report // Google Meet Help. URL: https://support.google.com/meet/answer/10090454?hl=en (дата обращения: 08.06.2026).
|
||||
23. About Attendance // Brightspace Community. URL: https://community.d2l.com/brightspace/kb/articles/3609-about-attendance (дата обращения: 08.06.2026).
|
||||
24. Qwickly Attendance Pro // D2L Brightspace IntegrationHub. URL: https://integrationhub.brightspace.com/details/qwickly-attendance-pro (дата обращения: 08.06.2026).
|
||||
25. Федеральный закон от 27.07.2006 № 152-ФЗ "О персональных данных", статья 11 "Биометрические персональные данные" // КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_61801/7336c78762a98b5f4f698b8c3800dca1111acc16/ (дата обращения: 08.06.2026).
|
||||
@@ -1,354 +0,0 @@
|
||||
# МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
|
||||
|
||||
Федеральное государственное автономное образовательное учреждение высшего образования
|
||||
|
||||
## НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ «МИФИ»
|
||||
|
||||
*ИНСТИТУТ ИНТЕЛЛЕКТУАЛЬНЫХ КИБЕРНЕТИЧЕСКИХ СИСТЕМ*
|
||||
|
||||
КАФЕДРА КИБЕРНЕТИКИ
|
||||
|
||||
---
|
||||
|
||||
**Учебно-исследовательская работа на тему**
|
||||
|
||||
**«Обзор существующих решений и выбор инструментария для разработки системы учёта посещаемости студентов НИЯУ МИФИ»**
|
||||
|
||||
---
|
||||
|
||||
Выполнил студент: __________________________________
|
||||
|
||||
Группа: _______
|
||||
|
||||
Проверил: __________________________________
|
||||
|
||||
Оценка: ___________________
|
||||
|
||||
Дата: _____________________
|
||||
|
||||
Подпись: __________________
|
||||
|
||||
**Москва, 2025**
|
||||
|
||||
---
|
||||
|
||||
## Оглавление
|
||||
|
||||
- [Введение](#введение)
|
||||
- [1. Обзор существующих систем учёта посещаемости студентов](#1-обзор-существующих-систем-учёта-посещаемости-студентов)
|
||||
- [1.1. Российские системы](#11-российские-системы)
|
||||
- [1.2. Зарубежные системы](#12-зарубежные-системы)
|
||||
- [1.3. Сравнительный анализ аналогов](#13-сравнительный-анализ-аналогов)
|
||||
- [2. Анализ методов фиксации посещаемости](#2-анализ-методов-фиксации-посещаемости-студентов)
|
||||
- [3. Обзор существующих исследований](#3-обзор-существующих-исследований)
|
||||
- [4. Выбор технологического стека](#4-выбор-технологического-стека)
|
||||
- [Заключение](#заключение)
|
||||
- [Список использованной литературы](#список-использованной-литературы)
|
||||
|
||||
---
|
||||
|
||||
## Введение
|
||||
|
||||
Цифровая трансформация высшего образования является одним из ключевых направлений государственной политики Российской Федерации. Согласно федеральному проекту «Цифровая образовательная среда», к 2025 году не менее 85% российских вузов должны располагать современными цифровыми инструментами управления учебным процессом. Вместе с тем значительная часть университетов по-прежнему использует бумажные журналы или устаревшие информационные системы для фиксации посещаемости студентов, что порождает целый ряд организационных и технических проблем.
|
||||
|
||||
В современном техническом вузе, таком как НИЯУ МИФИ, где одновременно обучаются тысячи студентов, учёт посещаемости занятий является обязательной административной процедурой. Ручное ведение журналов посещаемости существенно увеличивает нагрузку на преподавателей, снижает оперативность получения статистики деканатами и не позволяет автоматически синхронизировать данные с внешними информационными системами университета. Проблема усугубляется тем, что НИЯУ МИФИ располагает развитой корпоративной IT-инфраструктурой, включающей Единую систему аутентификации (CAS), внутренние реестры академических данных и API расписания — однако существующие на рынке решения, как правило, не обеспечивают нативной интеграции с подобными системами.
|
||||
|
||||
Дополнительную актуальность проблеме придаёт требование прозрачности: студент должен иметь возможность самостоятельно видеть свою историю посещений, а не узнавать о накопленных пропусках в конце семестра. Преподаватель, в свою очередь, должен иметь возможность как автоматически фиксировать посещение (через QR-код), так и вручную корректировать данные при необходимости. Куратор группы и деканат должны иметь доступ к сводной статистике, а администратор системы — к управлению справочниками и периодами обучения.
|
||||
|
||||
Существующие на российском рынке продукты в области электронных журналов (БАРС.Образование, 1С:Университет, iSpring Learn) либо ориентированы на модель «преподаватель вручную отмечает студентов», либо представляют собой тяжёлые ERP-системы, предназначенные для комплексного управления вузом, а не для точечного решения задачи учёта посещаемости. Зарубежные корпоративные платформы (Microsoft Teams, Google Classroom, Brightspace) фиксируют посещаемость как побочный продукт онлайн-встреч и не применимы к очным занятиям. Специализированные QR-SaaS-решения предполагают хранение данных у стороннего провайдера, что недопустимо с точки зрения политики обработки персональных данных в государственном вузе.
|
||||
|
||||
Таким образом, ниша «веб-приложение для QR-самоотметки посещаемости с интеграцией в корпоративный SSO вуза, синхронизацией с внешними реестрами и полной ролевой моделью» остаётся незаполненной, что и обусловливает необходимость разработки собственного решения для НИЯУ МИФИ.
|
||||
|
||||
**Целью** настоящей работы является определение подхода к разработке веб-приложения для автоматизированного учёта посещаемости студентов НИЯУ МИФИ, обеспечивающего прозрачную фиксацию присутствия на занятиях, интеграцию с корпоративными системами университета и надёжную синхронизацию данных с внешними реестрами.
|
||||
|
||||
**Объект исследования** — процесс учёта посещаемости студентов в НИЯУ МИФИ, включающий взаимодействие студентов, преподавателей, кураторов и администраторов в рамках учебного процесса.
|
||||
|
||||
**Предмет исследования** — методы и инструменты автоматизации фиксации посещаемости студентов, архитектурные паттерны и технологии для реализации интегрированного корпоративного веб-приложения.
|
||||
|
||||
**Задачи работы:**
|
||||
|
||||
- провести обзор существующих аналогов систем учёта посещаемости (российских и зарубежных) и выявить их принципиальные ограничения применительно к условиям НИЯУ МИФИ;
|
||||
- проанализировать основные методы технической фиксации факта посещения студентом занятия и обосновать выбор QR-кодов как основного механизма самоотметки;
|
||||
- изучить актуальные научные исследования в области автоматизированного учёта посещаемости и смежных задач (архитектурные паттерны, производительность СУБД, фоновая обработка) для формирования теоретической базы разработки;
|
||||
- определить оптимальный технологический стек и архитектурные решения для разработки системы, обосновав выбор каждого компонента.
|
||||
|
||||
**Методологическую основу** исследования составляет системный анализ существующих программных решений и технологических подходов в области автоматизации учёта посещаемости в высших учебных заведениях. Исследование включает:
|
||||
|
||||
- сравнительный анализ коммерческих и открытых систем учёта посещаемости по шести критериям (QR-самоотметка, SSO-интеграция, Outbox-синхронизация, вузовская ролевая модель, on-premise-развёртывание, открытость кода);
|
||||
- сравнительный анализ методов технической фиксации посещаемости (ручная отметка, RFID/NFC, QR-коды, биометрия, геолокация) по критериям применимости в условиях МИФИ;
|
||||
- обзор рецензируемых научных публикаций (2015–2024) по теме QR-систем посещаемости, производительности СУБД, архитектурных паттернов для веб-приложений;
|
||||
- обоснование выбора технологического стека на основании совокупности технических и организационных критериев.
|
||||
|
||||
**Практическая значимость** работы заключается в создании обоснованной методической базы для разработки реального веб-приложения учёта посещаемости студентов НИЯУ МИФИ. Проведённый анализ аналогов и методов позволяет разработчикам осознанно подходить к выбору архитектурных решений, избегая типовых ошибок — таких как зависимость от стороннего SaaS-провайдера, отсутствие гарантий доставки данных во внешние реестры или невозможность интеграции с корпоративным SSO. Результаты работы могут быть использованы как основа для проектирования аналогичных систем в других технических вузах.
|
||||
|
||||
Работа включает введение, четыре раздела, заключение и список использованной литературы. В первом разделе проводится анализ аналогов — как российских, так и зарубежных систем учёта посещаемости. Во втором разделе рассматриваются основные технические методы фиксации посещаемости. Третий раздел посвящён обзору существующих научных исследований. Четвёртый раздел содержит обоснование выбора технологического стека.
|
||||
|
||||
---
|
||||
|
||||
## 1. Обзор существующих систем учёта посещаемости студентов
|
||||
|
||||
Прежде чем приступить к проектированию новой системы, необходимо провести детальный анализ уже существующих решений. Это позволит выявить незаполненную нишу, сформулировать требования к разрабатываемому приложению и избежать воспроизведения известных недостатков. В рамках настоящего раздела рассматриваются как российские (БАРС.Образование, 1С:Университет, iSpring Learn, Дневник.ру), так и зарубежные (Microsoft Teams, Google Classroom/Meet, Brightspace/D2L) системы, а также специализированные QR-SaaS-решения и открытые разработки.
|
||||
|
||||
### 1.1. Российские системы
|
||||
|
||||
**БАРС.Образование — Электронная школа (БАРС Груп).** Система является одной из наиболее распространённых платформ электронного журнала и дневника в Российской Федерации; входит в реестр отечественного ПО и рекомендована к тиражированию в рамках программы «Электронный регион» [9]. Основная функциональность: электронный журнал (оценки, темы уроков, планирование учебного процесса), электронный дневник, учёт посещаемости — вручную учителем, расписание, отчётность. Вход осуществляется через учётную запись Госуслуг.
|
||||
|
||||
Ключевые ограничения БАРС.Образование применительно к НИЯУ МИФИ состоят в следующем. Во-первых, архитектура системы построена на модели «школа — класс — родитель», которая не масштабируется на вузовскую структуру «поток — группа — подгруппа — кафедра — деканат». Во-вторых, посещаемость фиксируется исключительно ручным способом: преподаватель (учитель) отмечает отсутствующих в журнале; студенческий QR-self-service не предусмотрен. В-третьих, система не обеспечивает интеграции с корпоративным CAS-сервером вуза — идентификация пользователей осуществляется через Госуслуги/СМЭВ. В-четвёртых, не предусмотрен механизм гарантированной передачи данных о посещаемости во внешние академические реестры (Outbox-синхронизация). Таким образом, БАРС.Образование является решением для общеобразовательных школ и не применимо в условиях корпоративного технического университета.
|
||||
|
||||
**1С:Университет (фирма «1С»).** Это отраслевое решение на платформе «1С:Предприятие 8.3», предназначенное для комплексного управления учебным процессом вуза [10]. В его функциональность входят: управление контингентом студентов, ведение личных дел и зачётных книжек, учёт успеваемости и посещаемости, формирование ведомостей, приёмная кампания. Система поддерживает территориально распределённые базы данных и широко используется в российских вузах.
|
||||
|
||||
Несмотря на формальную поддержку учёта посещаемости, 1С:Университет обладает рядом принципиальных ограничений в контексте задач данной работы. Ввод данных о посещаемости осуществляется вручную через АРМ преподавателя — студенческий QR-self-service и нативный веб-интерфейс самообслуживания не предусмотрены. Система представляет собой монолитную проприетарную ERP-платформу, интеграция которой с внешними системами реализуется через специализированные механизмы обмена 1С, а не через REST API и корпоративный SSO. Развёртывание и настройка требуют значительных затрат времени и компетенций в области платформы 1С, что делает систему неподходящей для разработки адаптированного решения с нуля.
|
||||
|
||||
**iSpring Learn (iSpring Solutions).** Российская корпоративная LMS (система управления обучением), используемая клиентами в 172 странах. Платформа доступна как в облачном исполнении, так и в варианте развёртывания на серверах клиента [11]. Функциональность включает: курсы и тесты, вебинары (с интеграцией с Zoom), отчёт «ILT Attendance» по посещаемости очных тренингов/вебинаров (преподаватель отмечает участников вручную после мероприятия), SSO, открытый API, мобильное приложение.
|
||||
|
||||
Принципиальное ограничение iSpring Learn состоит в том, что система предназначена для корпоративного обучения персонала, а не для учёта очной посещаемости студентов в традиционном понимании. Посещаемость является побочной функцией модуля «мероприятий» (ILT — Instructor-Led Training): преподаватель вручную отмечает присутствовавших после завершения мероприятия. Отсутствует QR-самоотметка студентов на занятии, нет модели «учебный поток вуза», не предусмотрена Outbox-синхронизация с академическими реестрами. SSO в iSpring реализован через стандартный SAML/OAuth, но не через протокол CAS, используемый в МИФИ.
|
||||
|
||||
**Дневник.ру, ЭлЖур, Сетевой город. Образование (NetSchool).** Перечисленные системы относятся к категории школьных электронных журналов, ориентированных на базовый сценарий: ручная отметка посещаемости учителем, модель «класс/группа», работа с родителями. Ни одна из систем не поддерживает QR-самоотметку, корпоративный SSO вуза или вузовскую ролевую модель. Упоминаются здесь исключительно для полноты обзора российского рынка.
|
||||
|
||||
### 1.2. Зарубежные системы
|
||||
|
||||
**Microsoft Teams — функция учёта посещаемости.** Платформа Microsoft Teams поддерживает автоматическую генерацию отчёта о посещаемости онлайн-встречи: фиксируются имена участников, время входа/выхода, длительность участия, а также показатели вовлечённости (реакции, поднятые руки, включённые камеры) [12]. Отчёт доступен организатору встречи и экспортируется в CSV.
|
||||
|
||||
Ключевое ограничение Microsoft Teams заключается в том, что система фиксирует присутствие на видеовстрече, а не на очном занятии в аудитории. При численности участников более 120 человек отчёт в реальном времени содержит лишь частичный список; полный список формируется только после завершения встречи. Критически важно, что «If the event organizer leaves the org, reports are permanently deleted and can't be retrieved» — отчёты безвозвратно уничтожаются при увольнении организатора, что неприемлемо для академического архива. Нет QR-механизма для очных занятий, нет интеграции с CAS МИФИ, нет вузовской ролевой модели.
|
||||
|
||||
**Google Classroom / Google Meet.** В Google Classroom нативная функция отметки посещаемости отсутствует; типичный обходной путь — создание формы в Google Forms. Функциональность фиксации посещаемости в Google Meet доступна только на платных редакциях: Education Plus и Teaching and Learning Upgrade. По справке Google, «Attendance tracking is available to Google Workspace Essentials, Business Plus, Enterprise Starter, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Plus and the Teaching and Learning Upgrade users» [13]. При этом формируемый отчёт относится к онлайн-встрече, а не к очному занятию.
|
||||
|
||||
**Brightspace (D2L) — инструмент Attendance.** Платформа Brightspace предоставляет базовый инструмент учёта посещаемости: реестры (registers), настраиваемые схемы статусов, порог предупреждения (Cause for Concern). Системная схема включает два статуса — present и absent; порог настраивается в процентах [14]. Преподаватель (или ассистент) отмечает студентов вручную — инструмент не является self-reporting. QR-самоотметка реализуется только через сторонние плагины (Qwickly Attendance, You-Attend) из D2L IntegrationHub, что означает дополнительные лицензионные затраты и зависимость от внешних провайдеров. Для внедрения системы потребуется развёртывание всей платформы Brightspace, что является избыточным для решения единственной задачи — учёта посещаемости.
|
||||
|
||||
**Специализированные QR/чек-ин SaaS-решения (OneTap, AccuClass, QR Attendee и аналоги).** Данный класс систем специально разработан для QR-фиксации посещаемости на мероприятиях и в учебных заведениях. Функциональность включает: генерацию QR-кодов, чек-ин студентов, импорт списков из Excel, аналитические дашборды, экспорт отчётов, иногда — геолокационную верификацию.
|
||||
|
||||
Несмотря на то что специализированные QR-SaaS-решения по набору функций ближе всего к требованиям данной работы, они обладают принципиальными ограничениями для применения в государственном университете. Данные хранятся в облаке стороннего провайдера, что не соответствует требованиям ФЗ-152 о локализации персональных данных и внутренней политике НИЯУ МИФИ. Отсутствует интеграция с CAS МИФИ — пользователи вынуждены создавать отдельные учётные записи. Нет механизма Outbox-синхронизации с внутренними академическими реестрами университета. Ролевая модель упрощена (обычно «организатор — участник») и не отражает вузовской иерархии. Закрытый исходный код исключает возможность адаптации под специфику МИФИ.
|
||||
|
||||
**Открытые проекты на GitHub (QR-Attendance-System, Check-by-QR и аналоги).** На платформе GitHub существует ряд прототипов QR-систем посещаемости, реализованных на различных стеках (Django, PHP/Bootstrap, Java/SQLite, .NET MAUI). Как правило, они поддерживают базовый сценарий: генерацию QR-кода, сканирование смартфоном, запись в базу. Некоторые включают геопроверку и защиту от повторной отметки. Однако все они являются студенческими или учебными прототипами: без промышленной надёжности, без гарантий доставки данных (Outbox), без CAS-интеграции, без полноценной ролевой модели.
|
||||
|
||||
### 1.3. Сравнительный анализ аналогов
|
||||
|
||||
На основании проведённого обзора составлена сравнительная таблица по шести ключевым критериям, определённым исходя из специфики задачи НИЯУ МИФИ.
|
||||
|
||||
| Система | QR-self-service | SSO/CAS | Outbox-синхр. | Ролевая модель вуза | On-premise | Open-source | Итог |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| БАРС.Образование | ✘ | ✘ | ✘ | Школьная | Зависит | ✘ | Не подходит |
|
||||
| 1С:Университет | ✘ | ✘ | ✘ | Частично | ✔ | ✘ | Не подходит |
|
||||
| iSpring Learn | ✘ | ✔ (SAML) | ✘ | Корпоративная | ✔ | ✘ | Не подходит |
|
||||
| MS Teams | ✘ | ✔ (Azure AD) | ✘ | ✘ | ✘ | ✘ | Не подходит |
|
||||
| Google Classroom | ✘ | ✔ (Google) | ✘ | ✘ | ✘ | ✘ | Не подходит |
|
||||
| Brightspace | Через плагин | ✔ | ✘ | LMS | ✔ | ✘ | Не подходит |
|
||||
| QR-SaaS (OneTap и др.) | ✔ | Частично | ✘ | ✘ | ✘ | ✘ | Не подходит |
|
||||
| **Проектируемая система МИФИ** | **✔** | **✔ (CAS)** | **✔** | **Полная** | **✔** | **✔** | **Целевая** |
|
||||
|
||||
*Таблица 1 — Сравнительная таблица систем учёта посещаемости*
|
||||
|
||||
Проведённый анализ демонстрирует, что ни один из рассмотренных продуктов одновременно не обеспечивает QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO на протоколе CAS, гарантированную Outbox-синхронизацию с внутренними академическими реестрами, полную вузовскую ролевую модель (студент / преподаватель / куратор / администратор) и возможность on-premise развёртывания с открытым исходным кодом. Это и составляет обоснование разработки собственного решения, адаптированного к специфике НИЯУ МИФИ.
|
||||
|
||||
---
|
||||
|
||||
## 2. Анализ методов фиксации посещаемости студентов
|
||||
|
||||
Для обоснования выбора QR-кодов в качестве основного механизма фиксации посещаемости необходимо рассмотреть весь спектр существующих технических методов и оценить их применимость в условиях НИЯУ МИФИ.
|
||||
|
||||
**Ручная отметка преподавателем** является традиционным и наиболее распространённым методом. Преподаватель вносит в бумажный или электронный журнал сведения об отсутствующих (или присутствующих). Метод не требует никаких технических средств, однако имеет существенные недостатки: трудоёмкость (особенно на больших потоках), субъективность, задержка актуализации данных (нередко — до окончания занятия или дня), отсутствие цифрового следа для немедленной синхронизации. В условиях МИФИ, где размер лекционного потока может достигать 150–200 человек, ручная отметка занимает до 10–15 минут полезного учебного времени.
|
||||
|
||||
**RFID/NFC-карты.** Студент прикладывает студенческий билет (или смартфон с NFC) к считывателю при входе в аудиторию. Метод обеспечивает высокую скорость фиксации и не требует активных действий студента (кроме поднесения карты). Ограничения: необходимость установки считывателей в каждой аудитории (существенные инвестиции в инфраструктуру), риск передачи карты другому лицу, зависимость от состояния физической инфраструктуры. Используется в ряде крупных российских вузов (в первую очередь — в корпусах с турникетами на проходных), однако не обеспечивает granular-учёта по конкретной паре/дисциплине без дополнительной привязки к расписанию.
|
||||
|
||||
**QR-коды.** Преподаватель генерирует QR-код для конкретного занятия (привязанный к дате, времени, дисциплине и аудитории), отображает его на экране. Студент сканирует код смартфоном — приложение записывает факт посещения. Метод сочетает преимущества автоматизации и минимальных инфраструктурных требований: считыватели не нужны, достаточно смартфона у студента. Защита от злоупотреблений обеспечивается ограниченным временем жизни кода (токен действителен N минут) и привязкой к учётной записи студента (один токен — одна отметка). Для МИФИ метод особенно удобен, поскольку все студенты располагают смартфонами, а CAS-аутентификация позволяет исключить анонимные отметки.
|
||||
|
||||
**Биометрическая идентификация** (распознавание лица, отпечатка пальца). Теоретически обеспечивает наивысшую достоверность: каждый студент идентифицируется по физическому признаку, что исключает передачу идентификатора другому лицу. Однако практическое применение в российском вузе сопряжено с рядом серьёзных ограничений. Обработка биометрических персональных данных (ПДн специальной категории) требует отдельного согласия субъекта, соответствия требованиям ФЗ-152 и подзаконных актов Роскомнадзора, что существенно усложняет юридическое оформление. Инфраструктурные затраты (видеокамеры с достаточным разрешением и освещением в каждой аудитории) значительны. Риск отказа в обслуживании при недостаточном качестве изображения неприемлем для повседневного учёта.
|
||||
|
||||
**Геолокация.** Приложение на смартфоне студента фиксирует его местоположение и сверяет с координатами аудитории. Применяется как дополнительный механизм верификации в ряде зарубежных систем. Ограничения в условиях МИФИ: многокорпусный кампус с корпусами, расположенными вплотную (GPS-точность 5–15 м недостаточна для различения соседних аудиторий), ограниченный GPS-сигнал внутри зданий, необходимость постоянного доступа к геолокации — что вызывает справедливые опасения пользователей в плане приватности.
|
||||
|
||||
На основании проведённого анализа сформирована сравнительная оценка методов:
|
||||
|
||||
| Метод | Инфраструктура | Скорость | Защита от подмены | Правовые риски | Применимость в МИФИ |
|
||||
|---|---|---|---|---|---|
|
||||
| Ручная отметка | Минимальная | Низкая | Низкая | Минимальные | Базовая (fallback) |
|
||||
| RFID/NFC | Высокая | Высокая | Средняя | Низкие | Ограниченная |
|
||||
| **QR-коды** | **Минимальная** | **Высокая** | **Средняя** | **Низкие** | **Оптимальная** |
|
||||
| Биометрия | Высокая | Высокая | Высокая | Высокие (ФЗ-152) | Не применима |
|
||||
| Геолокация | Минимальная | Высокая | Низкая | Средние | Вспомогательная |
|
||||
|
||||
*Таблица 2 — Сравнительная оценка методов фиксации посещаемости*
|
||||
|
||||
Таким образом, метод QR-кодов является оптимальным для НИЯУ МИФИ: он не требует специальной инфраструктуры в аудиториях, обеспечивает достаточную скорость отметки (5–10 секунд на студента), легко интегрируется с существующей CAS-аутентификацией и не создаёт правовых рисков, связанных с обработкой биометрических данных. Ручная отметка преподавателем сохраняется как резервный (fallback) механизм. Данный подход подтверждается результатами научных исследований, рассматриваемых в следующем разделе.
|
||||
|
||||
---
|
||||
|
||||
## 3. Обзор существующих исследований
|
||||
|
||||
Анализ актуальных научных публикаций по теме автоматизации учёта посещаемости и смежным техническим задачам позволяет сформировать теоретическую базу для проектирования системы и избежать ранее выявленных проблем. Ниже рассматриваются шесть работ, непосредственно или косвенно связанных с темой настоящего исследования.
|
||||
|
||||
### *Nuhi A., Memeti A., Imeri F., Çiço B. «Smart Attendance System using QR Code»*
|
||||
|
||||
Авторы представили разработку автоматизированной системы учёта посещаемости студентов на основе QR-кодов для применения в учебных заведениях [2]. Система реализована в виде веб-приложения: преподаватель генерирует динамический QR-код для конкретного занятия, студент сканирует его смартфоном, сервер фиксирует отметку посещения с привязкой к учётной записи. Защита от злоупотреблений обеспечивается ограниченным временем действия кода и механизмом однократного использования токена.
|
||||
|
||||
К достоинствам предложенного подхода авторы относят: минимальные требования к инфраструктуре (не требуется специальное оборудование в аудиториях), высокую скорость отметки, возможность offline-генерации кодов при нестабильном соединении. Проведённые испытания подтвердили работоспособность системы в аудиторных условиях.
|
||||
|
||||
Ограничения работы связаны с отсутствием интеграции с корпоративными системами аутентификации и реестрами вуза: система функционирует автономно, что затрудняет синхронизацию с учебными планами и внешними базами данных академической успеваемости. Авторы также не рассматривают механизмы надёжной доставки данных во внешние системы и не предоставляют анализа архитектурных паттернов для промышленного развёртывания.
|
||||
|
||||
Результаты данного исследования подтверждают принципиальную применимость QR-метода для учёта посещаемости в высших учебных заведениях и служат теоретической базой для выбора механизма самоотметки в проектируемой системе МИФИ. Выявленные ограничения — отсутствие SSO-интеграции и синхронизации с реестрами — непосредственно учтены при постановке задачи настоящей дипломной работы.
|
||||
|
||||
### *Глуховский К.С., Пирожков Р.В., Цвелик Е.А. «Электронный журнал как элемент цифровой трансформации вуза»*
|
||||
|
||||
Работа посвящена опыту разработки и внедрения электронного журнала посещаемости и академической успеваемости в качестве модуля Электронной информационно-образовательной среды (ЭИОС) в Волгодонском инженерно-техническом институте НИЯУ МИФИ [3]. Система реализована как часть единой цифровой среды вуза и интегрирована с корпоративными справочниками.
|
||||
|
||||
Авторы подробно описывают процесс импорта академических данных (расписание, группы, студенты, дисциплины) из центральных систем вуза, структуру ролей пользователей (студент, преподаватель, деканат, администратор), механизм формирования отчётов по посещаемости. Работа имеет особое значение для настоящего исследования как отраслевой аналог из структуры НИЯУ МИФИ, демонстрирующий типовые задачи (импорт данных расписания, разграничение ролей, отчётность для деканата) применительно к инфраструктуре университета.
|
||||
|
||||
Ограничения описанного решения: не предусмотрена студенческая QR-самоотметка (посещаемость фиксируется преподавателем); отсутствует описание механизма синхронизации с внешними реестрами и гарантий доставки данных. Выявленные недостатки конкретизируют требования к проектируемой системе МИФИ в части добавления QR-механизма и реализации Outbox-паттерна.
|
||||
|
||||
### *Salunke S.V., Ouda A. «A Performance Benchmark for the PostgreSQL and MySQL Databases»*
|
||||
|
||||
В работе проводится сравнительное нагрузочное тестирование СУБД PostgreSQL и MySQL по операциям INSERT, SELECT (с/без WHERE) и UPDATE на наборах данных объёмом до 1 миллиона записей [5]. Эксперименты выполнены в идентичных условиях аппаратного и программного обеспечения.
|
||||
|
||||
Ключевые результаты: на операциях INSERT для 1 миллиона записей PostgreSQL показал время выполнения 0,6–0,8 мс, MySQL — 9–12 мс (в 13–15 раз медленнее). На операциях SELECT с фильтром WHERE PostgreSQL продемонстрировал время 0,09–0,13 мс против 0,9–1 мс для MySQL (примерно в 9 раз быстрее).
|
||||
|
||||
Авторы честно оговаривают ограничения: на простых OLTP SELECT при небольших объёмах данных и оптимизированных индексах разница может быть менее выражена; результаты зависят от профиля нагрузки. Тем не менее для задач, требующих сложных транзакций (Outbox-запись, ACID-гарантии при одновременной работе сотен студентов) и богатства типов данных (JSONB, массивы), PostgreSQL является обоснованным выбором. Данное исследование используется в разделе 4 для обоснования выбора PostgreSQL в качестве СУБД проектируемой системы.
|
||||
|
||||
### *Richardson C. «Microservices Patterns: With Examples in Java»*
|
||||
|
||||
Монография Криса Ричардсона является фундаментальным изданием в области архитектурных паттернов для распределённых систем [4]. Глава 3 посвящена паттерну Transactional Outbox, решающему проблему «двойной записи» (dual write) — несогласованности данных при одновременной записи в базу данных и отправке сообщения внешней системе.
|
||||
|
||||
Суть паттерна: при выполнении бизнес-операции (например, фиксации посещения) событие записывается в специальную таблицу-«почтовый ящик» (outbox) в той же атомарной транзакции, что и основные данные. Отдельный процесс-релей (publisher) асинхронно считывает необработанные записи из outbox-таблицы и передаёт их во внешние системы. При сбое релей повторяет попытку (гарантия at-least-once); получатели должны быть идемпотентны. Паттерн устраняет необходимость в распределённых транзакциях (2PC) и гарантирует, что ни одно событие не будет потеряно даже при временной недоступности внешней системы.
|
||||
|
||||
Ограничение паттерна: гарантия at-least-once предполагает, что одно и то же событие может быть доставлено более одного раза; получатель обязан обеспечить идемпотентную обработку. Для проектируемой системы МИФИ это означает, что при проектировании API внешних реестров следует предусмотреть механизм дедупликации по идентификатору события.
|
||||
|
||||
Данная работа является первичным теоретическим источником для обоснования архитектурного решения, реализованного в проектируемой системе через таблицу `update_attendance_students_outbox` и фоновый воркер `LessonVisitSyncWorker`.
|
||||
|
||||
### *Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий*
|
||||
|
||||
Данная работа, опубликованная в открытом доступе на платформе КиберЛенинка, описывает практический опыт кафедры ИКТ российского технического вуза по автоматизации контроля посещаемости очных занятий. Авторы рассматривают переход от бумажных журналов к цифровому учёту с использованием доступных инструментов: Google-таблицы в связке с QR-сканерами.
|
||||
|
||||
Ключевые наблюдения авторов, актуальные для настоящей работы: проблема автоматизации наиболее остро проявляется на крупных потоках (100+ студентов), где ручная отметка занимает значительное время; преподаватели позитивно оценивают делегирование процедуры отметки самим студентам (самоотметку). Авторы также отмечают необходимость интеграции с корпоративными справочниками студентов и расписанием для исключения ошибок при ручном вводе данных.
|
||||
|
||||
Ограничение: использование Google-таблиц предполагает хранение данных у иностранного поставщика, что создаёт риски соответствия требованиям ФЗ-152 о локализации персональных данных. В проектируемой системе МИФИ аналогичный функционал реализуется на собственной инфраструктуре вуза с развёртыванием через Capistrano.
|
||||
|
||||
### *AWS Prescriptive Guidance. «Transactional Outbox Pattern»*
|
||||
|
||||
Руководство по архитектурным паттернам Amazon Web Services детально описывает транзакционный Outbox-паттерн применительно к cloud-native приложениям [15]. Документ формализует компоненты паттерна: бизнес-сервис (атомарно пишет в БД и outbox), relayer (опрашивает outbox и публикует события), event consumer (обрабатывает события идемпотентно).
|
||||
|
||||
В документе подчёркивается, что данный паттерн решает фундаментальную проблему надёжности в микросервисных и распределённых системах: невозможность атомарно выполнить запись в базу данных и отправку сообщения брокеру без использования двухфазной фиксации (2PC), которая неприменима в современных высоконагруженных системах из-за сложности реализации и низкой производительности.
|
||||
|
||||
Рекомендации AWS по реализации паттерна учтены при проектировании модуля синхронизации проектируемой системы: таблица outbox включает поля `id` (уникальный идентификатор события), `payload` (JSON с данными посещения), `status` (новое/отправлено), `created_at`, `sent_at`. Воркер периодически запрашивает записи со статусом «новое», отправляет их в целевую систему и обновляет статус. При сбое статус остаётся «новое» и событие будет повторно обработано на следующем цикле.
|
||||
|
||||
---
|
||||
|
||||
## 4. Выбор технологического стека
|
||||
|
||||
Выбор оптимального технологического стека для разработки системы учёта посещаемости представляет собой комплексную инженерную задачу, требующую оценки каждого компонента по критериям производительности, зрелости экосистемы, соответствия задаче и скорости разработки. В данном разделе проводится сравнительный анализ альтернативных технологий и обосновывается итоговый выбор.
|
||||
|
||||
### 4.1. Веб-фреймворк: Ruby on Rails 7
|
||||
|
||||
Для реализации бэкенда рассматривались четыре ведущих веб-фреймворка: Ruby on Rails (Ruby), Django (Python), Laravel (PHP) и Spring Boot (Java).
|
||||
|
||||
**Django (Python)** обеспечивает высокую производительность Python-рантайма, богатую экосистему библиотек для науки о данных и зрелую ORM (Django ORM). Основным ограничением для данной задачи является отсутствие встроенного, полноценно интегрированного механизма для server-side real-time обновлений интерфейса (аналога Hotwire в Rails): подобный функционал требует использования Django Channels (отдельный компонент, значительно усложняющий стек) или SPA-фронтенда.
|
||||
|
||||
**Laravel (PHP)** демонстрирует высокую скорость разработки CRUD-приложений благодаря выразительному синтаксису и богатой экосистеме. Livewire — аналог Hotwire для Laravel — позволяет создавать реактивные интерфейсы без SPA. Однако PHP традиционно требует настройки веб-сервера (Apache/Nginx + PHP-FPM), что усложняет процедуру деплоя по сравнению с Rails+Capistrano. Кроме того, в существующей инфраструктуре проекта уже использован стек Ruby.
|
||||
|
||||
**Spring Boot (Java)** является стандартом корпоративной разработки на JVM: строгая типизация, высокая производительность, зрелая экосистема. Ограничения: значительный объём boilerplate-кода при реализации CRUD-операций, медленный цикл разработки и тестирования по сравнению с Ruby/Python, отсутствие нативного аналога Hotwire.
|
||||
|
||||
**Ruby on Rails 7** реализует строгий паттерн MVC, принципы Convention over Configuration и DRY, что ускоряет разработку типовых CRUD-компонентов (CRUD занятий, групп, студентов) и снижает объём шаблонного кода. Начиная с версии 7.0, Hotwire (Turbo + Stimulus) интегрирован в Rails «из коробки» [1], что позволяет реализовать отзывчивый интерфейс без выделенного SPA-фронтенда. Зрелая экосистема gem-пакетов (`rack-cas`, `pagy`, `paper_trail`, `rqrcode`, `httparty`) обеспечивает готовые реализации всех необходимых функций без написания дополнительного кода. Rails используется в production крупнейшими технологическими компаниями (GitHub, Shopify, Basecamp), что подтверждает его пригодность для промышленного применения.
|
||||
|
||||
*Честный контраргумент:* Ruby как язык уступает по «сырой» вычислительной производительности оптимизированному Python/Java; MRI-интерпретатор Ruby использует GIL (Global Interpreter Lock), ограничивая параллелизм в рамках одного процесса. Эти ограничения компенсируются фоновой обработкой тяжёлых задач через Sidekiq (многопоточная модель на уровне воркеров), кэшированием и горизонтальным масштабированием приложения.
|
||||
|
||||
### 4.2. Фронтенд: Hotwire (Turbo + Stimulus)
|
||||
|
||||
Hotwire («HTML Over The Wire») — это набор технологий для создания интерактивных веб-интерфейсов без использования полноценного SPA-фреймворка [6]. Концепция: вместо того чтобы передавать JSON и перестраивать DOM на клиенте (React/Vue), сервер возвращает готовые HTML-фрагменты, которые встраиваются в страницу.
|
||||
|
||||
Состав Hotwire:
|
||||
- **Turbo Drive** — навигация по страницам без полной перезагрузки (аналог pjax);
|
||||
- **Turbo Frames** — изолированные обновляемые области страницы (загрузка фрагмента без перезагрузки всего layout);
|
||||
- **Turbo Streams** — точечные DOM-операции (append, prepend, replace, remove), в том числе через WebSocket для realtime-обновлений;
|
||||
- **Stimulus** — минималистичный JS-фреймворк для добавления поведения через data-атрибуты без перестройки архитектуры.
|
||||
|
||||
Для проектируемой системы учёта посещаемости Hotwire особенно подходит по следующим причинам. Задача не требует сложного клиентского состояния (не является полноценным SPA): основные операции — загрузка списка присутствующих, отметка студента, обновление строки — идеально ложатся на модель Turbo Frames/Streams. Backend-ориентированная команда разработки не обязана владеть React/TypeScript. Кодовая база остаётся монолитной, что упрощает поддержку и деплой.
|
||||
|
||||
*Ограничение:* для интерфейсов с чрезвычайно высокой интерактивностью и сложным клиентским состоянием (например, drag-and-drop конструкторы, сложные формы с зависимыми полями) Hotwire менее удобен, чем React. В контексте данного проекта таких требований нет.
|
||||
|
||||
### 4.3. СУБД: PostgreSQL
|
||||
|
||||
PostgreSQL — полнофункциональная объектно-реляционная СУБД с открытым исходным кодом, поддерживающая ACID-транзакции через механизм MVCC (Multiversion Concurrency Control) [8]. Для проектируемой системы рассматривались PostgreSQL и MySQL.
|
||||
|
||||
По результатам сравнительного бенчмарка Salunke & Ouda (2024) [5], PostgreSQL демонстрирует превосходство в транзакционных операциях: на 1 миллионе записей INSERT выполняется в 13–15 раз быстрее, SELECT с WHERE — в 9 раз быстрее, чем в MySQL. Для системы учёта посещаемости, где сотни студентов одновременно фиксируют посещение (пиковая нагрузка в начале лекции), высокая производительность параллельных INSERT критически важна.
|
||||
|
||||
Дополнительные аргументы в пользу PostgreSQL: поддержка типа JSONB (используется при хранении метаданных Outbox-событий), строгая типизация и богатство встроенных типов, развитая система ролей и схем (что соответствует многоролевой архитектуре системы), логическая репликация для потенциального горизонтального масштабирования, нативная поддержка полнотекстового поиска.
|
||||
|
||||
*Оговорка:* на простых OLTP-запросах с небольшими объёмами данных и оптимизированными индексами MySQL может демонстрировать сопоставимую производительность. Выбор PostgreSQL обусловлен прежде всего транзакционной целостностью (критичной для Outbox-паттерна) и богатством типов данных, а не исключительно скоростью.
|
||||
|
||||
### 4.4. Фоновые задачи: Sidekiq + Redis
|
||||
|
||||
Sidekiq — многопоточный обработчик фоновых задач для Ruby, использующий Redis как хранилище очередей [7]. Выбор Sidekiq обусловлен несколькими факторами: тесная интеграция с Rails через Active Job (переключение адаптера одной строкой конфигурации), многопоточная модель (эффективнее по памяти, чем процессные аналоги Resque и Delayed Job), встроенные очереди с приоритетами, автоматические повторы с экспоненциальной задержкой, веб-интерфейс мониторинга Sidekiq Web UI.
|
||||
|
||||
В проектируемой системе Sidekiq решает три критически важные задачи:
|
||||
1. **Реализация Outbox-релея:** воркер `LessonVisitSyncWorker` периодически (через Sidekiq Scheduler) опрашивает outbox-таблицу и отправляет необработанные события в целевые системы.
|
||||
2. **Тяжёлые импорты:** синхронизация расписания, групп и студентов из API МИФИ выполняется в фоне без блокировки основного веб-процесса.
|
||||
3. **Генерация отчётов** по запросу деканата.
|
||||
|
||||
Redis выполняет двойную роль: хранилище очередей для Sidekiq и кэш приложения (кэширование часто запрашиваемых данных расписания, справочников).
|
||||
|
||||
### 4.5. Аутентификация: CAS (Central Authentication Service)
|
||||
|
||||
Central Authentication Service (CAS) — протокол единого входа (SSO), разработанный в Йельском университете и поддерживаемый Apereo Foundation [16]. При аутентификации через CAS приложение перенаправляет пользователя на центральный CAS-сервер; пользователь вводит логин/пароль там, не передавая их приложению. После успешной аутентификации CAS выдаёт одноразовый service ticket, который приложение валидирует через защищённый канал. Приложение не хранит пароли пользователей.
|
||||
|
||||
CAS является стандартом SSO в университетской среде: его используют сотни ведущих вузов мира. В НИЯУ МИФИ CAS обеспечивает единый вход в корпоративные сервисы — от почты до личного кабинета. Интеграция проектируемой системы с CAS МИФИ через gem `rack-cas` позволяет использовать существующие учётные записи студентов и преподавателей без создания дополнительных паролей.
|
||||
|
||||
### 4.6. Архитектурные паттерны
|
||||
|
||||
**Service Objects.** Паттерн предполагает вынос сложной бизнес-логики из моделей и контроллеров в специализированные объекты (PORO — plain old Ruby objects), размещаемые в `app/services`. Каждый сервис отвечает за одну операцию (принцип единственной ответственности) и имеет единственный публичный метод `call`. Применяется для: `ImportStudentsService` (импорт студентов из API МИФИ), `ImportLessonsService` (импорт расписания), `CreateLessonVisitService` (логика фиксации посещения). Преимущества: тестируемость в изоляции, чёткое разделение ответственности, «тонкие» модели и контроллеры.
|
||||
|
||||
**Namespaced Controllers.** Разделение контроллеров по пространствам имён (`Admin::`, `Moderator::`, `Student::`) изолирует ролевые интерфейсы, упрощает маршрутизацию (`resources :lessons` вложены в соответствующий namespace) и авторизацию (`before_action :require_admin` в базовом контроллере пространства имён). Паттерн естественно поддерживает вузовскую ролевую модель (студент / преподаватель / куратор / администратор).
|
||||
|
||||
**Outbox Pattern.** Как описано в разделе 3 со ссылкой на Richardson [4] и AWS [15], паттерн Transactional Outbox обеспечивает гарантию at-least-once для доставки событий посещаемости во внешние реестры МИФИ. Реализован через таблицу `update_attendance_students_outbox` и фоновый воркер `LessonVisitSyncWorker` (Sidekiq), периодически публикующий необработанные записи.
|
||||
|
||||
### 4.7. CSS: Tailwind CSS
|
||||
|
||||
Tailwind CSS — utility-first CSS-фреймворк, интегрированный в Rails 7 через gem `tailwindcss-rails` [17]. Подход «utility-first» предполагает описание стилей непосредственно в HTML-разметке через семантические классы (`flex`, `p-4`, `text-gray-700`). Ключевые преимущества для данного проекта: существенно меньший production-бандл за счёт JIT-purge (удаляются все неиспользуемые классы); полная кастомизация через `tailwind.config.js` без переопределения базовых стилей фреймворка; нативная интеграция с Rails 7 (`rails new myapp --css tailwind`).
|
||||
|
||||
Bootstrap 5 используется для отдельных UI-компонентов, где применение готовых составных элементов (модальные окна, дропдауны) более уместно. Такое сочетание позволяет использовать сильные стороны обоих инструментов, что соответствует практике итеративной разработки.
|
||||
|
||||
### 4.8. Деплой: Capistrano + Mise
|
||||
|
||||
Capistrano — инструмент автоматизации деплоя для Ruby-приложений, реализующий стратегию rolling deployment с сохранением предыдущих релизов [19]. Поддерживаются окружения staging и production; деплой сводится к одной команде `cap production deploy`. Mise — менеджер версий рантаймов (Ruby, Node.js), обеспечивающий идентичность версий между локальной разработкой, CI и production-сервером [20].
|
||||
|
||||
---
|
||||
|
||||
## Заключение
|
||||
|
||||
В ходе настоящей учебно-исследовательской работы проведён комплексный анализ существующих систем и методов учёта посещаемости студентов, а также обоснован технологический стек для разработки корпоративного веб-приложения для НИЯУ МИФИ.
|
||||
|
||||
По результатам обзора восьми российских и зарубежных систем (БАРС.Образование, 1С:Университет, iSpring Learn, Microsoft Teams, Google Classroom, Brightspace, QR-SaaS и открытые проекты) установлено, что ни одна из рассмотренных систем не обеспечивает одновременно QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO на протоколе CAS, гарантированную Outbox-синхронизацию с внутренними академическими реестрами и полную вузовскую ролевую модель. Данный вывод обосновывает необходимость разработки собственного решения, адаптированного к специфике инфраструктуры НИЯУ МИФИ.
|
||||
|
||||
Из пяти рассмотренных методов технической фиксации посещаемости (ручная отметка, RFID/NFC, QR-коды, биометрия, геолокация) оптимальным для условий МИФИ признан метод QR-кодов. Он сочетает минимальные инфраструктурные требования (не требует оборудования в аудиториях), высокую скорость отметки, приемлемый уровень защиты от подмены через механизм одноразовых токенов и отсутствие правовых рисков, связанных с обработкой биометрических данных.
|
||||
|
||||
Обзор шести актуальных научных публикаций подтвердил применимость QR-подхода для учёта посещаемости (Nuhi et al., 2020), выявил типовые задачи, стоящие перед вузами при разработке подобных систем в контексте НИЯУ МИФИ (Глуховский и др., 2021), обосновал выбор PostgreSQL как СУБД для высококонкурентных транзакционных операций (Salunke & Ouda, 2024) и сформировал теоретическую базу для реализации Outbox-паттерна (Richardson, 2018; AWS Prescriptive Guidance).
|
||||
|
||||
Определён следующий технологический стек: Ruby on Rails 7 (бэкенд, MVC, Convention over Configuration), Hotwire/Turbo/Stimulus (фронтенд без SPA), PostgreSQL (СУБД с ACID-транзакциями и поддержкой JSONB), Redis + Sidekiq (фоновые задачи и Outbox-релей), rack-cas (интеграция с CAS МИФИ), Tailwind CSS + Bootstrap (стилизация). Архитектурные паттерны: Service Objects (изоляция бизнес-логики), Namespaced Controllers (ролевое разделение), Transactional Outbox (надёжная синхронизация), MVC (структурирование приложения). Деплой — через Capistrano + Mise.
|
||||
|
||||
Результаты работы формируют обоснованную теоретическую базу для реализации системы в рамках дипломной работы и могут служить методической основой для разработки аналогичных систем в других технических вузах с корпоративной IT-инфраструктурой на основе протокола CAS.
|
||||
|
||||
---
|
||||
|
||||
## Список использованной литературы
|
||||
|
||||
1. Ruby on Rails Guides: Getting Started with Rails // Ruby on Rails Documentation, 2024. URL: https://guides.rubyonrails.org/ (дата обращения: 20.05.2025).
|
||||
2. Nuhi A., Memeti A., Imeri F., Çiço B. Smart Attendance System using QR Code // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020, pp. 1–4. DOI: 10.1109/MECO49872.2020.9134225.
|
||||
3. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. № 5. URL: https://ivdon.ru (дата обращения: 22.05.2025).
|
||||
4. Richardson C. Microservices Patterns: With Examples in Java. Manning Publications, 2018. 520 с.
|
||||
5. Salunke S.V., Ouda A. A Performance Benchmark for the PostgreSQL and MySQL Databases // Future Internet. 2024. Vol. 16, No. 10. Art. 382. DOI: 10.3390/fi16100382.
|
||||
6. Hotwire: HTML Over The Wire // Hotwire Documentation. URL: https://hotwired.dev/ (дата обращения: 20.05.2025).
|
||||
7. Sidekiq: Simple, Efficient Background Processing for Ruby // Sidekiq Documentation. URL: https://sidekiq.org/ (дата обращения: 20.05.2025).
|
||||
8. PostgreSQL: The World's Most Advanced Open Source Relational Database // PostgreSQL 16 Documentation. URL: https://www.postgresql.org/docs/16/ (дата обращения: 20.05.2025).
|
||||
9. БАРС.Образование — Электронная школа // БАРС Груп. URL: https://bars.group/products/education/ (дата обращения: 15.05.2025).
|
||||
10. 1С:Университет — Возможности // 1С Образование. URL: https://solutions.1c.ru/catalog/university/features (дата обращения: 15.05.2025).
|
||||
11. iSpring Learn: корпоративная платформа для обучения // iSpring Solutions. URL: https://www.ispring.ru/ispring-learn (дата обращения: 15.05.2025).
|
||||
12. Manage the Attendance and Engagement Report for Meetings and Events in Microsoft Teams // Microsoft Learn. URL: https://learn.microsoft.com/en-us/microsoftteams/teams-analytics-and-reports/meeting-attendance-report (дата обращения: 16.05.2025).
|
||||
13. Track Attendance & View Live Stream Report // Google Classroom Help. URL: https://support.google.com/edu/classroom/answer/10090454 (дата обращения: 16.05.2025).
|
||||
14. Brightspace by D2L: Attendance Tool // D2L Documentation. URL: https://documentation.brightspace.com/ (дата обращения: 16.05.2025).
|
||||
15. Transactional Outbox Pattern // AWS Prescriptive Guidance. URL: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html (дата обращения: 18.05.2025).
|
||||
16. CAS Protocol Specification // Apereo Foundation. URL: https://apereo.github.io/cas/ (дата обращения: 18.05.2025).
|
||||
17. Tailwind CSS Documentation // Official Site. URL: https://tailwindcss.com/docs/ (дата обращения: 20.05.2025).
|
||||
18. Bootstrap 5 Documentation // Official Site. URL: https://getbootstrap.com/docs/5.3/ (дата обращения: 20.05.2025).
|
||||
19. Capistrano: Remote Server Automation and Deployment Tool // Official Documentation. URL: https://capistranorb.com/ (дата обращения: 20.05.2025).
|
||||
20. Mise: Polyglot Runtime Manager // Official Documentation. URL: https://mise.jdx.dev/ (дата обращения: 20.05.2025).
|
||||
21. Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий // КиберЛенинка. URL: https://cyberleninka.ru/article/n/metodika-avtomatizatsii-kontrolya-poseschaemosti-ochnyh-zanyatiy-po-opytu-kafedry-informatsionnyh-kompyuternyh-tehnologiy (дата обращения: 22.05.2025).
|
||||
22. Pagy: Fast, Ultralight, Agnostic, Extendable Pagination for Ruby // GitHub. URL: https://github.com/ddnexus/pagy (дата обращения: 21.05.2025).
|
||||
23. Paper Trail: Track Changes to your Rails Models // GitHub. URL: https://github.com/paper-trail-gem/paper_trail (дата обращения: 21.05.2025).
|
||||
24. rqrcode: A Ruby Library for Encoding QR Codes // GitHub. URL: https://github.com/whomwah/rqrcode (дата обращения: 21.05.2025).
|
||||
25. HTTParty: Makes HTTP Fun Again // GitHub. URL: https://github.com/jnunemaker/httparty (дата обращения: 21.05.2025).
|
||||
Reference in New Issue
Block a user