From e418f23948e4ae83845350d6d2ca71e58903dd7e Mon Sep 17 00:00:00 2001 From: Dmitry Date: Mon, 8 Jun 2026 14:53:28 +0300 Subject: [PATCH] arch-x1: 2026-06-08 14:53:28 | 2 --- ...12-4b5f-831e-fff85054d115_text_markdown.md | 164 ++++++++++++++++++ 90 Library/Other/Принцип via negativa.md | 2 + 2 files changed, 166 insertions(+) create mode 100644 00 Inbox/compass_artifact_wf-61b9de62-4312-4b5f-831e-fff85054d115_text_markdown.md diff --git a/00 Inbox/compass_artifact_wf-61b9de62-4312-4b5f-831e-fff85054d115_text_markdown.md b/00 Inbox/compass_artifact_wf-61b9de62-4312-4b5f-831e-fff85054d115_text_markdown.md new file mode 100644 index 0000000..523baf4 --- /dev/null +++ b/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) и набор функций периодически меняются — в работе обязательно указывать дату обращения к источнику. \ No newline at end of file diff --git a/90 Library/Other/Принцип via negativa.md b/90 Library/Other/Принцип via negativa.md index a58c593..ca2232b 100644 --- a/90 Library/Other/Принцип via negativa.md +++ b/90 Library/Other/Принцип via negativa.md @@ -20,6 +20,8 @@ aliases: ["via negativa", "негативный путь"] Вместо вопроса «что добавить?» задаётся вопрос: «что убрать, чтобы стало лучше?» +Будет ли здесь работать автодопо + ## Как применять - Убрать очевидный вред: лишние обязательства, шум, плохие привычки, ненужные зависимости.