Merge branch 'master' of u20kovalev_den/ISRPO into master

Лекции/Docker/Попков.md

@@ -0,0 +1,22 @@
+# Лекция 4: Контейнеризация в Docker: архитектура изоляции и оптимизация слоев
+
+**Docker** представляет собой платформу для контейнеризации приложений, реализующую виртуализацию на уровне операционной системы. В отличие от гипервизоров, эмулирующих аппаратное обеспечение, Docker использует механизмы ядра Linux (**namespaces** и **cgroups**) для создания изолированных пользовательских пространств, разделяющих ядро с хост-системой, что обеспечивает минимальные накладные расходы и мгновенный запуск.
+
+Архитектурно Docker построен по клиент-серверной модели. **Docker daemon (dockerd)** отвечает за управление объектами: образами (images), контейнерами (containers), томами (volumes) и сетями. **Docker client** взаимодействует с демоном через REST API, что позволяет управлять контейнерами как локально, так и удаленно. Ключевое преимущество такой архитектуры — возможность интеграции с оркестраторами (Kubernetes, Swarm) через стандартизированный интерфейс.
+
+![Alt](docker.png)
+### Таблица 1. Компоненты архитектуры Docker
+| Компонент | Назначение | Взаимодействие | Особенности |
+| -------- | -------- | -------- | -------- |
+| **Docker daemon** | Управление объектами | REST API, containerd | Фоновый процесс, orchestration |
+| **Docker client** | Интерфейс пользователя | CLI → daemon | Кроссплатформенность |
+| **Docker registry** | Хранение образов | push/pull | Публичные/приватные реестры |
+| **containerd** | Жизненный цикл контейнера | Промышленный стандарт | Выделен из dockerd |
+
+Фундаментальная концепция Docker — **слоистая файловая система (UnionFS)**. Каждая инструкция в **Dockerfile** создает новый read-only слой. При сборке образа слои кешируются; при запуске контейнера поверх них монтируется read-write слой. Это обеспечивает эффективное использование дискового пространства и ускоряет развертывание — скачиваются только измененные слои. Однако разработчику важно понимать, что каждая инструкция `RUN`, `COPY` или `ADD` создает отдельный слой, и их оптимизация напрямую влияет на размер итогового образа.
+
+Критическим аспектом production-эксплуатации является управление **persistent data**. Контейнеры по умолчанию stateless — все данные, записанные в read-write слое, уничтожаются при удалении контейнера. Для постоянного хранения Docker предоставляет **тома (volumes)**, управляемые демоном, и **bind mounts**, монтирующие директории хоста. Тома предпочтительнее, так как они полностью изолированы от хостовой файловой системы и могут управляться через Docker API.
+
+Сетевая модель Docker абстрагирует коммуникации через драйверы: **bridge** (изоляция контейнеров на хосте), **host** (прямой доступ к сетевому стеку хоста), **overlay** (связь между хостами в кластере). По умолчанию каждый контейнер получает виртуальный сетевой интерфейс и IP-адрес из приватного пула, а проброс портов осуществляется через правила iptables.
+
+Для промышленной разработки критически важно следовать **best practices**: использовать минимальные базовые образы (alpine), объединять команды `RUN` для уменьшения числа слоев, запускать процессы от непривилегированного пользователя и всегда явно указывать теги версий для воспроизводимости сборок . Это превращает Docker из инструмента упаковки в фундаментальный компонент DevOps-пайплайна, обеспечивающий идентичность окружений на всех этапах: от рабочей станции разработчика до production-кластера.

Лекции/Go/Попков.md

@@ -0,0 +1,20 @@
+# Лекция 1: Управление памятью в Go: архитектура, эвакуация и влияние на latency
+
+Управление памятью в компилируемых языках программирования традиционно требовало либо ручного контроля (malloc/free), либо значительных накладных расходов на сборку мусора (GC). Язык **Go** (Golang) предлагает компромиссное решение: автоматическое управление памятью с **неблокирующим конкурентным сборщиком мусора**, спроектированным для минимизации задержек (latency) в высоконагруженных системах.
+
+Ключевая архитектурная особенность — это разделение кучи (heap) на области, управляемые потокобезопасными кэшами (mcache). Каждый поток выполнения (P в терминах планировщика Go) имеет свой локальный кэш мелких объектов. Это реализует принцип **безлоковой аллокации**: выделение памяти под микрообъекты происходит простым увеличением указателя в пределах локальной страницы, без захвата глобальных блокировок мьютексов.
+
+
+![Alt](GoMemory.png)
+### Таблица 1. Уровни аллокации памяти в Go
+| Компонент | Уровень | Область видимости | Механизм синхронизации |
+| -------- | -------- | -------- | -------- |
+| **mcache** | Поток (P) | Локальный кэш | Без блокировок (lock-free) |
+| **mcentral** | Глобальный | Список для размера класса | Мьютексы (при балансировке) |
+| **mheap** | Глобальный | Вся куча (arena) | Мьютексы (при запросе у ОС) |
+
+Сборщик мусора реализует **трехцветный алгоритм пометки и заметания (mark-and-sweep)** и работает конкурентно с основным кодом. Однако ключевая фаза — **фаза остановки мира (Stop The World)** — сведена к минимуму и происходит только для начала цикла и для завершающей пометки. Инженеру важно понимать концепцию **эвакуации (evacuation)** — хотя в стандартном GC Go нет явной эвакуции объектов как в поколенческих сборщиках, есть процесс **фрагментации кучи**. Чтобы избежать деградации производительности, Go периодически выполняет дефрагментацию, перемещая или подчищая страницы, что может вызвать микро-паузы.
+
+Для снижения нагрузки на GC разработчики применяют **пулы объектов (sync.Pool)**. Использование sync.Pool позволяет переиспользовать уже выделенные структуры, снимая нагрузку со сборщика мусора и уменьшая количество аллокаций в куче. Это критически важно для приложений реального времени (например, прокси-серверов или API Gateway), где каждая миллисекунда задержки на счету.
+
+Таким образом, эффективная работа с памятью в Go требует не только понимания синтаксиса, но и осознанного управления аллокациями: предпочтение стека перед кучей (благодаря анализу побега — escape analysis), переиспользование временных буферов и учет поведения конкурентного GC.

Лекции/Notepad/Попков.md

@@ -0,0 +1,22 @@
+# Лекция 5: Архитектура Notepad++: от Scintilla до плагинной экосистемы
+
+**Notepad++** представляет собой свободный редактор исходного кода и текста для операционной системы Windows, архитектура которого построена на компромиссе между минимальным потреблением ресурсов и максимальной расширяемостью. С инженерной точки зрения, это пример успешной реализации легковесного приложения, написанного на **C++** с использованием только **Win32 API** и стандартной библиотеки шаблонов (**STL**), что обеспечивает минимальный размер дистрибутива и высокую скорость исполнения без зависимостей от тяжеловесных фреймворков .
+
+Центральным компонентом системы является библиотека **Scintilla**, выполняющая функции редактирования текста. Scintilla предоставляет механизмы подсветки синтаксиса, сворачивания кода (code folding) и автодополнения. Notepad++ выступает в роли обертки, которая интегрирует этот компонент в нативную оболочку Windows, добавляя управление документами, вкладками и пользовательскими настройками . Ядро приложения построено вокруг класса `Notepad_plus`, который управляет буферами документов через `FileManager`, а каждый буфер (`Buffer`) инкапсулирует состояние конкретного файла, кодировку и историю изменений, независимо от представления .
+
+
+![Alt](NT.png)
+### Таблица 1. Ключевые компоненты архитектуры Notepad++
+| Компонент | Назначение | Техническая реализация |
+| -------- | -------- | -------- |
+| **Scintilla** | Движок редактирования | Библиотека на C++, управление синтаксисом и событиями |
+| **Буфер (Buffer)** | Представление документа в памяти | Класс `Buffer`, управление кодировкой и состоянием |
+| **Менеджер плагинов** | Динамическая загрузка расширений | Загрузка DLL, управление через `PluginsManager` |
+
+Ключевая особенность для разработчика — архитектура обработки сообщений. Notepad++ работает в классическом для Windows событийно-ориентированном цикле. Все действия пользователя транслируются в сообщения, которые обрабатываются главной оконной процедурой `Notepad_plus_Window::runProc`, после чего маршрутизируются в `Notepad_plus::process` — центральный диспетчер команд, расположенный в модуле `NppBigSwitch.cpp` . Такая схема обеспечивает четкое разделение между пользовательским интерфейсом и бизнес-логикой.
+
+Расширяемость редактора реализована через **систему плагинов**. Плагины представляют собой динамически подключаемые библиотеки (DLL), загружаемые менеджером `PluginsManager` при старте приложения . Архитектура плагина требует экспорта стандартных функций (например, `isUnicode`, `getName`, `beNotified`), что позволяет основному приложению вызывать код расширения в ответ на события редактора . Плагины имеют прямой доступ к компоненту Scintilla через отправку сообщений (`SendMessage`), что дает им возможность модифицировать содержимое документа на низком уровне .
+
+С инженерной точки зрения, эффективность Notepad++ достигается за счет оптимизации использования процессора. Разработчик Дон Хо декларировал цель снижения энергопотребления: минимизация вычислительных циклов позволяет процессору переходить в режимы пониженного энергопотребления, что снижает углеродный след . Это реализуется через отказ от фоновых процессов-демонов и синхронную обработку пользовательского ввода.
+
+В контексте безопасности архитектура претерпела изменения после инцидента 2025 года, когда была скомпрометирована инфраструктура обновлений. В ответ была усилена подсистема обновления **WinGup**: теперь верифицируется не только цифровая подпись устанавливаемого файла, но и подпись XML-манифеста с сервера обновлений (XMLDSig) . Это пример того, как архитектура desktop-приложения адаптируется к современным требованиям безопасной поставки кода (supply chain security).

Лекции/Unreal_Engine/Попков.md

@@ -0,0 +1,21 @@
+# Лекция 2: Архитектура памяти и производительность в Unreal Engine: от UObject до инкрементального GC
+
+**Unreal Engine** представляет собой не просто игровой движок, а комплексную среду выполнения реального времени, архитектура которой построена вокруг объектной модели на базе **UObject**. Для разработчика критически важно понимать, как эта модель управляет памятью и какие ценой достигается высокая производительность в проектах AAA-класса.
+
+В основе системы лежит иерархия: **UObject** является базовым классом для всех управляемых объектов, **AActor** — для объектов, которые могут быть размещены в мире, а **ActorComponent** — для модульных блоков функциональности, прикрепляемых к акторам . Все UObject'ы находятся под управлением сборщика мусора (Garbage Collector), реализующего алгоритм **"пометить-и-подмести" (mark-sweep)**. В отличие от нативных C++ объектов, где разработчик несет полную ответственность за ручное управление памятью, UObject'ы автоматически отслеживаются через систему ссылок и метаданных (FName, Outer), что неизбежно увеличивает потребление памяти .
+
+
+![Alt](unr.png)
+### Таблица 1. Сравнение подходов к управлению памятью в Unreal Engine
+| Тип объектов | Управление | Преимущества | Недостатки |
+| -------- | -------- | -------- | -------- |
+| **UObject (управляемые)** | Автоматическое (GC) | Безопасность ссылок, подсчет ссылок, интеграция с редактором | Накладные расходы памяти, возможные фризы |
+| **Нативные C++ объекты** | Ручное (new/delete) | Максимальная производительность, контроль над аллокацией | Риск утечек и висячих ссылок (dangling pointers) |
+
+Ключевая проблема классического GC в играх — это **фризы (hitches)**, возникающие при анализе достижимости (reachability analysis), когда сборщик останавливает мир для сканирования всех объектов. Начиная с UE5, движок предлагает экспериментальное решение — **инкрементальный GC**. Эта функция позволяет разнести анализ достижимости на несколько кадров, устанавливая мягкий лимит времени на кадр (например, 2 мс через параметр `gc.IncrementalReachabilityTimeLimit`) .
+
+Инкрементальный режим использует **барьер записи (write barrier)** через умный указатель `TObjectPtr`. При присвоении значения свойству `UPROPERTY` во время сборки мусора объект немедленно помечается как достижимый. Однако важно знать ограничение: технология не является полностью потокобезопасной и рекомендуется к применению в однопоточных сборках (например, на выделенных серверах) .
+
+Для снижения нагрузки на GC инженеры применяют **пулинг объектов (Object Pooling)**. Вместо постоянного спавна и уничтожения снарядов или врагов, пул предварительно создает фиксированное количество экземпляров, активируя и деактивируя их по мере необходимости. Это позволяет избежать дорогостоящих операций создания/уничтожения и сопутствующих пиков процессорной активности, расплачиваясь за это резервированием памяти .
+
+Понимание этих механизмов позволяет разработчику осознанно проектировать игровую логику: избегать избыточного использования `Tick` в пользу событийной модели, применять пулы для часто спавнящихся объектов и настраивать параметры сборки мусора (например, в `DefaultEngine.ini` через `gc.AllowIncrementalReachability=1`) для достижения плавного геймплея без вычислительных выбросов .

Лекции/Игровой_дизайн/Попков.md

@@ -0,0 +1,20 @@
+# Лекция 3: Системная архитектура игрового дизайна: от механик к динамическим системам
+
+**Игровой дизайн** с инженерной точки зрения представляет собой процесс формализации пользовательского опыта через иерархически организованные системы правил и обратных связей. В отличие от художественного или нарративного проектирования, системный игровой дизайн оперирует понятиями состояний, переходов, циклов обратной связи и экономических моделей, поддающихся количественному анализу и балансировке.
+
+Фундаментальной единицей анализа выступает **игровая механика** — атомарное правило взаимодействия игрока с системой. Механики, объединяясь, формируют **игровую динамику** — эмерджентное поведение, возникающее в результате их комбинированного применения. Архитектурно это напоминает композицию микросервисов: каждая механика должна быть тестируема изолированно, но ценность системы проявляется только в их интеграции .
+
+
+![Alt](GD.png)
+### Таблица 1. Иерархия абстракций в игровом дизайне
+| Уровень | Единица анализа | Инструменты формализации | Критерии оценки |
+| -------- | -------- | -------- | -------- |
+| **Механики** | Правила, действия, состояния | Блок-схемы, конечные автоматы | Функциональность, отсутствие багов |
+| **Динамики** | Стратегии, паттерны поведения | Системная динамика, графы | Баланс, глубина, вариативность |
+| **Эстетика** | Эмоциональный отклик | Психометрика, пользовательские тесты | Вовлеченность, удовлетворенность |
+
+Критическим элементом архитектуры игрового дизайна являются **петли обратной связи**. Положительная обратная связь (например, набор очков, дающий преимущества) усиливает лидерство и приближает завершение игры. Отрицательная обратная связь (например, система гандикапа в мотогонках) подталкивает систему к равновесию, увеличивая неопределенность исхода. С инженерной точки зрения, эти петли реализуются через событийную архитектуру: достижение порогового значения генерирует событие, которое триггерит модификаторы параметров.
+
+Проектирование **игрового баланса** требует применения методов системной динамики и математического моделирования. Уравнения роста урона, кривые прогрессии, экономические модели внутриигровых ресурсов — все это должно быть параметризовано и вынесено в **data-driven архитектуру** (конфигурационные таблицы, скриптовые языки). Это позволяет проводить балансировку итеративно, без перекомпиляции движка, и использовать автоматизированное тестирование для поиска "доминантных стратегий" (стратегий, нарушающих мета-игру) .
+
+Эмерджентность в игровом дизайне достигается не добавлением сложных правил, а созданием простых механик с высоким потенциалом комбинаторного взаимодействия. Как в системном программировании сложное поведение возникает из простых инструкций, так и в игровом дизайне глубина геймплея является следствием тщательно спроектированных интерфесов между механиками . Таким образом, задача игрового дизайнера-инженера — не придумать миллион правил, а спроектировать систему, где миллион ситуаций возникает из сотни правил.