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

99 System/Archive/gemini-code-1780921978295.md

@@ -0,0 +1,150 @@
+---
+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).
+

99 System/Archive/Обзор аналогов и обоснование инструментария системы учёта посещаемости студентов НИЯУ МИФИ.md

@@ -0,0 +1,168 @@
+---
+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) и набор функций периодически меняются — в работе обязательно указывать дату обращения к источнику.