arch-x1: 2026-06-08 14:53:28 | 2

00 Inbox/compass_artifact_wf-61b9de62-4312-4b5f-831e-fff85054d115_text_markdown.md

@@ -0,0 +1,164 @@
+# УИР (Глава 1): Обзор аналогов и обоснование инструментария системы учёта посещаемости студентов НИЯУ МИФИ
+
+## 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) и набор функций периодически меняются — в работе обязательно указывать дату обращения к источнику.

90 Library/Other/Принцип via negativa.md

@@ -20,6 +20,8 @@ aliases: ["via negativa", "негативный путь"]
 
 Вместо вопроса «что добавить?» задаётся вопрос: «что убрать, чтобы стало лучше?»
 
+Будет ли здесь работать автодопо
+
 ## Как применять
 
 - Убрать очевидный вред: лишние обязательства, шум, плохие привычки, ненужные зависимости.