​​Non-Abstract Large System Design (NALSD)
Процесс проектирования:
1 стадия включает принципиальную возможность построения решения:
- Возможно ли это?
- Можем ли мы сделать лучше?
2 стадия вписывает принципиальное решение в рамки проекта:
- возможно ли реализовать в заданных границах (деньги, время и т.д.)
- устойчиво ли полученное решение?
- можно ли сделать лучше?

Далее итеративно делается следующее:
- формируются требования
- выполняется дизайн системы
- выполняется калькуляция ресурсов
- определяются варианты развития системы
- процесс повторяется со второй позиции, до получения удовлетворяющего требованиям решения.


Конвейеры обработки данных используются в следующих приложениях:

1. ETL (Extract Transform Load)
ETL служат для:
- изменения состава данных
- выполнения промежуточных расчетов
- назначение индексов
- обогащение данных

2. Анализ данных (например на базе BI системы). Используются для оперативного мониторинга, построения отчетов, анализа данных.
3. Машинное обучение используется для поиска корреляций и «умного» анализа данных.

​​Цикл разработки

1. Прототипирование
2. Запуск на малом объеме реальных данных (пробный запуск)
3. Стейджинг (или препродакшен)
4. Канареечное тестирование (частичный запуск)
5. Частичное развертывание на «боевом» окружении
6. Развертывание на всем «боевом» окружении

Принципы построения релизов:
- воспроизводимые сборки
- автоматизированные сборки
- автоматизированные тесты
- автоматизированные публикации
- небольшие развертывания
В цикле выше важный этап – это канареечное тестирование, когда деплой выполняется на ограниченное количество ресурсов и может быть ограничен по времени, так же предполагается возможность быстрого отката. Для эффективного канареечного тестирования нужно реализовать принципы построения релизов. В конечном итоге это ложится в модель CI/CD
При выполнении канареечного тестирования нужно подобрать время и ресурсы, которые с одной стороны обеспечат необходимый объем тестирования, с другой стороны (в случае сбоя) риски будут минимизированы. Для проведения канареечного тестирования важно выбрать набор репрезентативных метрик, которые могут наглядно показать, что развертывание прошло успешно.
Варианты канареечного развёртывания:
- Синее/зеленое развертывание – зеленые – куда реально идет трафик и выполняется развертывание, синее – резерв куда можно перейти, если найдены ошибки в релизе
- искусственная генерация данных – вместо реальной среды канарейка помещается под нагрузку, но с синтезированными данными
- теневое копирование – когда канарейка развертывается в тестовой среде, но с копией реальных данных

Выводы: Книга глубоко рассматривает выстраивание рабочего процесса на базе SRE, приведено очень много примеров и разъяснений, которые помогают «нащупать» основные моменты реализуемые в стандарте и наметить путь внедрения SRE. Но при этом эта одна из тех книг, которые требуют повторного прочтения и переосмысления. Особенно удобно использовать книгу в процессе реального развертывания SRE. Рекомендую к прочтению все кто занимается организационными вопросами в командах разработчиков.

Конспект книги Software System Architecture
(автор Nick Rozanski, Eoin Woods)

Книга рассматривает три основные концепции, которые используются при построении архитектуры любой системы:
1. Stackholders (заказчики системы) – люди, которые принимают решения относительно того, какие функции должны быть реализованы, а какие нет
2. Viewpoins и view (представление) – это способ структурировать систему, дать описание каждого важного аспекта системы как самостоятельной сущности. Для построения представлений используется принцип «разделяй и властвуй». Каждое преставление описывает «что» должна делать программа или система, а так же взаимодействие и влияние представлений между собой.
Обычно через представления описываются «функциональная структура», «информационная организация», «среда развертывания» и т.д.
3. Perspective (архитектурные перспективы) это аналог представлений, но используются они для того чтобы описать «как» должна работать система. Обычно через представления описываются вопросы относящиеся к качественным характеристикам – безопасность, надежность, производительность. Перспективы могут быть общими для многих представлений.

Архитектура - это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы.

Структуры в архитектуре:
- статичные структуры – определяют то чем является проектируемая система (описание интерфейсов, аппаратного обеспечения, модулей и т.д.)
- динамические структуры – описывают как именно работает система, обычно эти структуры создаются и используются в рантайме.

Свойства системы - такие свойства, которые может увидеть или оценить внешний наблюдатель, воспринимая систему как черный ящик. То ради чего система создается.

Качественные характеристики – это целевые показатели системы, которые важны для разработки системы.

Архитектурные кандидаты – варианты организации архитектуры.

Архитектурные элементы – это элементы из которых состоит система.
Ключевые атрибуты архитектурных элементов:
- четко определенные обязанности
- четко определенные ограничения
- набор строго определенных интерфейсов, которые определяют сервисы для взаимодействия архитектурных элементов.

​​Обычно архитектурные элементы – это компоненты или модули.

Для архитектуры так же справедливо правило «Быстро, качественно, недорого» - можно выбрать только два из трех.

Представления

Сама большая ошибка при разработке архитектуры проекта – создание сложных моделей, отвечающих и выполняющих все на свете. Таких перегруженных решений нужно избегать.

Правильное решение – декомпозировать систему на набор представлений.

Определять представления каждый раз при проектировании системы – бессмысленно, для переиспользования готовых решений можно применять паттерны, соглашения и другие наработки созданные в рамках представлений, которые в рамках книги называются viewpoint.

Преимущества использования идеи «архитектурных представлений»:
- разделение проблем
- управление сложностью
- упрощение коммуникаций со стекхолдером
- сфокусированность на проблема разработки

Подводные камни:
- несогласованность представлений
- неправильный выбор представлений
- фрагментация

Перспективы

Основные: безопасность, производительность, масштабируемость, доступность, устойчивость, эволюционность.

​​Цели использования перспектив:
- улучшения
- создание артефактов

Роль «Архитектор»
- определение и взаимодействие со стекхолдерами
- определение требований
- определение ограничений
- построение архитектуры соответствующей требованиям и ограничениям

Специализации архитектора:
- product architect – отвечает за поставку продукта внешним заказчикам или стекхолдерам
- domain architect – основные функции по построению архитектуры высокого уровня (бизнес-архитектура, архитектура данных и т.д.)
- solution architect - отвечает за архитектуру на уровне решения
- enterprise architect – высокоуровневые задачи управления предприятием – продажи, маркетинг, продукты, сервисы и т.д.

Подходы к проектированию архитектуры:
- Каскадная модель (waterfall) – модель при которой архитектор проходит стандартные фазы: анализ требований, проектирование, реализация и т.д.
- Итеративный подход – разделение проектирования на итерации (обычно каждая итерация – это отдельный вопрос проектирование) и проход по каждой итерации как по самостоятельному проекту
- Agile - непрерывный цикл проектирования включающий «дизайн», «разработка и тестирование», «развертывание», «анализ».

Важные элементы архитектуры:
- Бизнес цели и «драйверы» - конкретны задачи, которые хочет решить бизнес, а так же способы их достижения;
- Архитектурный контекст – это описание важных элементов архитектуры, которые определяют ее взаимодействие с внешним миром, а так же ее функциональные возможности. Описывается коротко, с достаточной для понимания сути детализацией, без жаргона и скрытой «магии»;
- Архитектурные вопросы – описание того какие проблемы существуют и как они решаются в рамках построения системы, а также ограничения которые нужно учитывать. Описание как правило включает архитектурные цели, функциональные требования, архитектурные требования и т.д.
- Архитектурные принципы – это принципы построения системы, ее каркас, а так же подсказка какие решения в рамках архитектур должны приниматься. Принципы должны быть конструктивными, обдуманными, существенными.

Архитектурные паттерны как правило бьются на три группы:
- архитектурные стили – паттерн описывающий архитектуру на системном уровне, основное отличие в том что стиль рассматривает систему целиком, не концентрируясь на деталях. Стиль как правило описывается в терминах «архитектурных элементов» их взаимодействии и ограничениях.
- шаблон проектирования – это более конкретное решение, которое направлено на решение специфического вопроса и содержит описание какой-то конкретной ситуации;
- идиомы языка программирования – шаблоны для реализации на уровне языка программирования, учитывающие особенности языка и реализующие лучшие практики.

Распространённые архитектурные стили:
- Pipes and filters
- Client/Server
- Tiered Computing (отличается от Layered тем, что порядок взаимодействия tier-ов может быть любым)
- Peer-to-Peer
- Layered Implementation
- Publisher/Subscriber (реактивные архитектуры)
- Asynchronous Data Replication (отличается от pub/sub тем, что предназначена для синхронизации источников данных)
- Distribution Tree (publisher -> distributor -> consumer)
- Integration Hub (отличается от Data Replication тем, что синхронизация данных идет между системами, а не репликами БД)
- Tuple Space

Важные артефакты описания архитектуры:
- Архитектурное описание (общее описание системы)
- Моделирование (модель отражает упрощенное представление реальной бизнес задачи и служит для выстраивания аспектов системы)
- Сценарии использования готовой системы
- Валидация (проверка технических и логических моментов на корректность)

Вывод: книга состоит из двух частей в первой части идет рассмотрение основных архитектурных концепций и других вопросов построения архитектуры, во второй части идет каталог архитектурных представлений и перспектив, которые рассматривают конкретные реализации архитектур. В книге не рассмотрены современные архитектуры, такие как микросервисная или варианты реактивных архитектур. Это связана с тем, что книга довольно старая, поэтому есть некоторые моменты, которые не соответствуют сегодняшнему дню. Но в целом книга дает основное понимание работы архитектора – это работа с заказчиком, анализ и обобщение требований, выделение главного, и только в последнюю очередь использование конкретных паттернов. Рекомендую книгу к прочтению.

Practical Microservices Architectural Patterns
Event-Based Java Microservices with Spring Boot and Spring Cloud

Вводная часть книги содержит общее описание классического подхода к построению архитектуры систем:
- менйфрейм архитектура, когда есть центральный супер компьютер и куча «тупых» терминалов, которые отображают данные, но весь стейт хранится на сервере;
- клиент/серверная архитектура, когда стейт хранится на клиента, а тяжелые операции выполняются на сервере
- 3-х уровневая архитектура системы – классическое разделение на клиентский уровень, бизнес логику (средний уровень) и данные
- многоуровневая архитектура – выделение из среднего уровня несколько промежуточных уровней.

В большинстве случаев архитектура систем используется сетевую инфраструктуру для взаимодействия между клиентом и сервером. Для этого есть несколько стандартных решений:
- соединение точка/точка
- брокер сообщений
- общая шина сообщений

В свою очередь, архитектурные уровни, входящие в систему, могут разделяться на слои приложения, которые бьются на модули. Модульный подход – классика построения сложных систем.
У модульного подхода несколько недостатков:
– ад зависимостей, которые с ростом системы все труднее поддаются управлению;
- ограничения масштабирования, которые вытекают из предыдущего пункта;
- монолитность на уровне системы, несмотря на то что внутри приложение разделено на слои и модули, разделение уровней системы невозможно и они развертываются как единый элемент.

Основные принципы построение масштабируемых систем:
- Стейтлес дизайн – без единой точки состояния система может тиражироваться на любое количество узлов;
- Использование принципа разделяй и властвуй – способ разбить монолит на части и вынести части за пределы единого узла развертывания;

Альтернативой классическим монолитным подходам выступает архитектура с независимыми модулями, которая имеет два основных преимущества:
- параллельная разработка
- разделенная публикация

Основная проблема такого решение – организация взаимодействия между модулями. При синхронном взаимодействии возникают длительные периоды когда модуль ничего не делает ожидая ответ, поэтому асинхронная природа запросов – вынужденное зло.

Наиболее продвинутым вариантом построения архитектуры с независимыми модуля является микросервисная архитектура, у нее следующие особенности:
- общение сервисом посредством сообщений, которые передаются через сетевую инфраструктуру
- разнородная, независимая природа сервисов (могут быть реализованы на разных языках, в разных модулях развертывания)
- сосредоточенность на бизнес задачах
- размер сервиса небольшой, ограничен решением маленькой задачи, с возможностью независимой публикации сервиса и его обновления.

В основе взаимодействия микросервисов лежат REST-запросы и JSON нотация для представления данных. Но так же может быть использован другой формат, например XML.

MASA (Mesh App and Service Architecture) – архитектурное решение, которое позволяет объединить и организовать различных пользователей, с различными девайсами, работающих на различные типах сетей. В такой архитектуре бесшовно должны работать мобильные приложения, веб-приложения, десктопные приложения, IOT устройства.

Варианты построения облачной инфраструктуры:

Infrastructure as a Service — одна из моделей обслуживания в облачных вычислениях, по которой потребителям предоставляются по подписке фундаментальные информационно-технологические ресурсы — виртуальные серверы с заданной вычислительной мощностью, операционной системой и доступом к сети

Platform as a Service — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования

Software as a Service — одна из форм облачных вычислений, модель обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером

Варианты виртуализации: виртуальные серверы или контейнеры.
#microservice

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи.

CQRS строится на базе двух концепций:
- команды
- события

#microservice

​​Для построения крупных распределенных приложений используется механизм обмена сообщениями. Процесс строится на принципе «положил в очередь/взял из очереди», обычно в роли места куда складываются сообщения выступает брокер сообщений.

Микросервис который «кладет» в очередь называется Producer
Микросервис который «берет» из очереди называется Consumer

AMQP — открытый протокол для передачи сообщений между компонентами системы

Высокая доступность при использовании микросервисов подразумевает планирование и определение сервисов, к которым предъявляются требования высокой доступности. Для этих сервисов должны быть определены возможные точки отказа и варианты восстановления.
Один из эффективных подходов – файлуре толеранс (принятие сбоев).
Уровень доступности определяется процентом времени в аптайме, 100% - 24/7
Основная идея для повышения доступности системы – дублирование основных элементов архитектуры.
Сюда относится:
- балансировка DNS
- дублирование интернет провайдеров (ISP), использование BGP протокола
- дублирование СУБД
- дублирование инфраструктуры для развертывания микросервисов

​​Для повышения производительности микросервисов рекомендуется:
- использовать асинхронные http запросы
- Protocol Buffers — протокол сериализации структурированных данных, предложенный Google как эффективная бинарная альтернатива текстовому формату XML. Основные задачи – маршалинг/демаршалинг данных

Для управления состоянием системы построенной на базе микросервисов часто используется Event Driven Architecture (EDA)

EDA обычно включает в себя отправителей и получателей событий.
Событие - это факт, который произошел и имеет место быть. При этом оповещение о событии и событие – это два разных понятия. И часто их путают, когда возникновение событие связывают неразрывно с механизмом оповещений.
EDA:
- Каналы
o Передача событий
o Поддержание очереди событий
- Отправители (emmiters/agents/source)
o Генерация событий
o Детекция событий
o Сбор событий
o Отправка событий
- Получатели (sinks/consumers)
o Прием и обработка событий

В EDA архитектуре основой является BASE (Basically Available, Soft State, Eventually Consistent) Systems.
Для обеспечения взаимодействия между микросервисами используется транзакционный подход. При этом каждая транзакция должна соответствовать ACID.

Транзакционные модели:
- плоская – последовательное выполнение транзакций с единой точкой отката
- вложенная – каждая транзакция может создавать дочерние транзакции, при этом откат родительской транзакции несет за собой откат дочерних транзакций, а откат дочерних транзакции влечет необходимость принятия решения об откате на уровне родительской транзакции
- цепочки транзакций – каждая последующая транзакция зависит от предыдущей
- шаблон saga – тоже самое что вложенная модель, но каждая родительская транзакция имеет специальные «компенсационные» транзакции.

Механизмы изоляции транзакций:
- блокировка
- сериализация

Варианты транзакций:
- ACID транзакции (единственные кто может гарантировать целостность данных)
- BASE транзакции (используют принцип «целостность в конечном итоге»)

Наибольшие проблемы в сопровождении вызывают распределенные транзакции, значительная часть времени на разработку микросервисной архитектуры тратиться на проработку сценариев получения и распространения распределенных транзакций.

Преимущество нужно отдавать локальным транзакциям, избегая распределенных транзакции как можно дольше.

Для управления платформой на базе микросервисов используются «конфиг серверы». Конфиг сервер может быть микросервисом в задачи которого входит распространение конфигурации системы между другими микросервисами.

Стек:
- конфиг сервер - ZooKeper
- регистратор сервисов - Eureka
- API шлюз - Zuul

Вывод: книга – отличное пособие для Java разработчиков, желающих развернуть микросервисную архитектуру у себя на проекте. Большая часть книги – это описание конкретных примеров использования и создания микросервисов на базе Java Spring. Около трети книги рассматривает теоретические аспекты построения микросервисной архитектуры. В книге много иллюстрирующих изображений, котороые помогают понять как может быть описана архитектура микросервисной системы.

Конспект книги «Functional and reactive domain modeling»

Книга начинается с краткого введения в Доменно-ориентированный дизайн (DDD) кратко рассмотрены следующие моменты:
Доменная модель (модель предметной области) – это вся информация, необходимая для перевода бизнес-задачи на язык программирования.
Bounded context (ограниченный контекст) – реализация принципа слабого зацепления на уровне модулей. Та граница внутри которой существует модель предметной области.
Domain Driven design разделяет два понятия Entity (Сущность) и Value Object (объект-значение)
Value Object – это объект связанный с конкретным значением, которое является его состоянием.
Entity – понятие более выского уровня, относящееся к доменной модели и имеющее свою собственную идентичность (неповторимость)
Service (сервис) в том числе доменный сервис – понятие более высокого уровня объединяет несколько сущностей и объектов-значений.
Сущности имеют свою собственную, внутренне присущую им идентичность. Объекты-значения — нет.
Объект-значение имеет внутреннюю иммутабельность и могут свободно перераспределяться между сущностями
Понятие эквивалентности идентификаторов относится к сущностям; понятие структурной эквивалентности — к объектам-значениям; ссылочной эквивалентности — к обоим.
Сущности имеют историю; у объектов-значений нулевой жизненный цикл.
Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить собственной жизнью.
Объекты-значения должны быть неизменяемыми; сущности почти всегда изменяемы.
Чтобы распознать объект-значение, мысленно замените его на integer.
Объекты-значения не должны иметь собственной таблицы в БД.
Предпочитайте объекты-значения сущностям при моделивании домена.

Доменный объект - это объекты в объектно-ориентированных компьютерных программах, выражающие сущности из модели предметной области
Доменные объекты могут создаваться через фабрики, которые создают агрегаты.
Агрегат является самым сложным из всех тактических инструментов DDD. Агрегатом называется кластер из объектов сущностей или значений. То есть эти объекты рассматриваются как единое целое с точки зрения изменения данных.
Агрегаты сохраняются в репозиториях, которые представлены базами данных (неважно SQL или NO SQL)
Словарь – важный элемент DDD содержит основные определения и термины предметной области.
Основные принципы проектирования доменных моделей в функциональном стиле
- Модель иммутабельна и представлена через алгебраические типы данных (АТД)
- поведение модели реализуется через функции в модуле, где модуль представляет из себя блок бизнес логики
- поведение оперирует над АДТ

Далее в книге идет обзорное рассмотрение функциональной парадигмы.
В основе функционального программирования лежит функциональная композиция. Например, f(g(h)) – это функциональная композиция функций одной переменной. Идея в том, что целое состоит из взаимодействия частей.
Функции высшего порядка – такие функции, которые принимают в качестве аргументов другие функции. Частным примером является функция map которая применят к списку значений какую-либо функцию и возвращает список измененных значений. Такие функции называются «комбинаторы».
Сайд эффект – любые действия функции, которые меняют внешнее окружение.
Чистые функции – такие функции, которые не имеют сайд эффектов.

Подстановочная модель вычислений (substitution model) – модель вычислений при которой происходит подстановка значений констант на место их идентификаторов
Ссылочная прозрачность и ссылочная непрозрачность — это свойства частей компьютерных программ. Выражение называется ссылочно прозрачным, если его можно заменить соответствующим значением без изменения поведения программы
Рассуждения в терминах эквивалентности (Equational reasoning) – парадигма в рамках которой и функции и их значения являются одним и тем же и их можно свободно заменять друг другом.

Реактивная модель
В рамках определения реактивной модели в книге раскрываются стандартные понятия.
Реактивная модель – модель ориентированная на потоки данных и распространение изменений. В основе модели лежит обмен сообщениями.
Основные атрибуты реактивной модели:
- отзывчивость (responsive) – реакция на действия пользователя
- эластичность (elastic) – возможность обрабатывать разную нагрузку
- отказоустойчивость (resilient) - устойчивость к ошибками
- обмен сообщениями и событиям


Обмен сообщениями подразумевает обмен событиями (Event) и командами (Command).
Доменные события обычно представлены одним из двух вариантов:
- идентификация по типу – каждому событию сопоставлен тип в системе
- собственное состояние – вся информация о событии находится внутри события.

Влияние событий обычно представлено одним из двух вариантов:
- система как снапшот – все события сразу изменяют состояние системы
- система как журнал изменений (Event log) – все события сохраняются и потом последовательно применяются к системе.


Далее в книге идет описание как в рамках языка Scala реализуются основные концепции управления и проводится связь между языком и перечисленными ранее парадигмами:
- управление «эффектами»
- управление задержками
- управление ошибками.
Основные момент связанные со Scala:
- Мощная система типов
- Функциональная парадигма как основная
- Алгебраические типы данных
- Модули как члены первого класса
Далее глубоко рассмотрены функциональные паттерны для реализации реактивных моделей, в основе лежат монады и функторы (примечание, без понимания монад и функторов читать раздел бессмысленно). Так же рассмотрены вопросы построения модулей и модулеризации приложения.
Способы создания реактивных доменных моделей
- promise и future - Под future обычно имеется в виду представление переменной, доступное только для чтения, а под promise — изменяемый контейнер с одиночным присваиванием, который передаёт значение future.
- явный обмен сообщениями
- модель акторов (например, на базе Akka) – стиль обмена «отправил и забыл» позволяет организовать асинхронное, событийно-ориентированное и неблокирующее взаимодействие. Акторы – однопоточные упрощенные модели вычислений. Конкурентность достигается за счет использования большого количества акторов.
- потоковая модель

Акторы:
- извлекают сообщение из «почтового ящика»
- создают новых акторов
- обновляют собственное состояние
- отправляют сообщения другим акторам
Целостность доменных моделей
При использовании стандартного CRUD для хранения состояния моделей в реляционных СУБД есть одна проблема – в БД сохраняется конечный результат вычислений, при этом не существует возможности определить «как» этот результат был получен. Например, при выполнении цепочки банковских транзакций в БД сохраняется конечная цифра – баланс. Это проблема, так как не позволяет делать «трассировку» состояний. Это блокиурет возможность отследить исторические изменения, сделать откат транзакции и т.д. Так же реляционные БД обычно имеют существенные ограничения по гарантированию целостности данных за пределами одной ноды.
Чтобы избежать данных проблем используется два варианта моделей, обеспечивающих целостное состояние:
- CQRS – разделение операций чтения и записи на два потока
- Event sourcing – сохранения в БД не конечного состояния, а набора «событий», которые привели к этому состоянию.
Основные принципы доменного моделирования:
- мысли выражениями
- сначала абстракция, затем вычисления
- используй наиболее простую абстракцию, которая подходит
- показывай «что делать», скрывай «как делать»
- изолируй с помощью bounded context
- предпочитай future акторам
- прогнозирую на ближайшую перспективу

Вывод: книга обзорно рассматривает основные понятие связанные с функциональным программированием и DDD. Затем подробно показывает как с помощью основных инструментов SCALA реализовать DDD с помощью функционального программирования. В книге подробно рассматриваются основные паттерны и приемы функционального проектирования. Рассматриваются вопросы построения целостных моделей, вопросы тестирования. Книга требует хорошего понимания SCALA и функционального программирования, использовать книгу как учебник по SCALA не получится.

А вот это уже интересно, кажется MS окончательно отчаялся починить свои отношения с docker-nvidia и просто добавит в WSL2 возможность прямого обращения к GPU.
https://devblogs.microsoft.com/directx/directx-heart-linux/

Иначе как "китайским чудом" назвать TikTok я не могу, пару лет назад его оценивали в 75 млрд. долларов, а сегодня он уже переваливает за 100 млрд.
https://www.bloomberg.com/news/articles/2020-05-20/tiktok-owner-s-value-surpasses-100-billion-in-private-markets

Вот так думаешь создать репозиторий, где собрать основные алгоритмы, а он уже есть - https://github.com/TheAlgorithms

"Сначала они тебя не замечают, потом смеются над тобой, затем борются с тобой. А потом ты побеждаешь." Махатма Ганди. Похоже Microsoft все больше "заимствует" из мира GNU/Linux. На этот раз речь идет о Windows Package Manager... Что дальше?
https://www.theverge.com/2020/5/20/21264739/microsoft-windows-package-manager-preview-download

Я не фанат C&C от Electronic Arts, но меня радует новость, что они решили открыть исходные коды TiberianDawn.dll и RedAlert.dll под GPL. Пока это только намерение, но уже скоро код должен появиться в открытом доступе.
https://www.ea.com/games/command-and-conquer/command-and-conquer-remastered/news/remaster-update-modding