Captive Dependencies

В недавнем посте про Cancellation Token я вскользь упоминал про эту проблему. Пришло время рассказать о ней поподробнее.

Captive Dependency - это ситуация, когда объект с быстрым жизненным циклом является зависимостью для объекта с медленным жизненным циклом. В контексте ASP.NET такая ситуация возникает тогда, когда вы регистрируете класс как Singleton, а в его зависимостях присутствуют классы, зарегистрированные как Scoped.

В отношении CancellationToken ситуация аналогичная. CancellationToken - это токен отмены текущего запроса, он зарегистрирован как Scoped и имеет короткий жизненный цикл. И если мы загружаем CancellationToken в конструктор Singleton-объекта, то вот и получается Captive Dependency. Именно по этой причине самым безопасным путем будет прокидывать CancellationToken параметром метода, потому что вызов метода (даже у singleton-объекта) гарантированно происходит в рамках scope-а.

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

Например, стандартный Microsoft DI имеет встроенный механизм валидации, который за вас пройдется по всему дереву собираемых зависимостей и определит наличие captive dependencies, а затем даст леща выбросит эксепшн с указанием, мол "ай-ай-ай, так делать нельзя", но его нужно не забыть включить при сборке скоупа. Красиво, Майки, спасибо!

А вот популярная библиотека для зависимостей Autofaс прямым текстом говорит:

Stopping captive dependencies is the responsibility of the developer.

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

Избегать этой проблемы нужно начиная с самых ранних этапов зарождения проекта, а самый дельный совет при этом стар как сам фортран - избегайте singleton'ов, а если они и необходимы, то делайте их максимально независимыми от других объектов.

👾 PICO

NuGet Central Package Management

Каждому шарписту приходится сталкиваться с обновлением внешних зависимостей. Обычно, это достаточно болезненная операция, а если вы перескакиваете сразу несколько мажорных версий у зависимости - вам потребуется минимум месяц реабилитации на Сейшелах (передаю привет Selenium-у).

В последнее время Майки хорошо подтянули инструментарий по управлению зависимостями и постепенно перенимают лучшие практики у новых пакетных менеджеров. Так появился функционал Central Package Management в нашем NuGet Package Manager'е.

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

Это закрывает сразу несколько проблем:

1. Когда в одном проекте используется внешний пакет версии X, а в соседнем используется тот же пакет версии Y. С применением CPM такая ситуация более невозможна. Обходим стороной целый пласт потенциальных проблем.

2. Отслеживать и управлять зависимостями стало гораздо проще и быстрее. Надо обновить минорную зависимость? Изменяем только 1 строчку во всем репозитории - готово.

Как подключить?

Необходимый минимум - это .NET 6.0

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

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

По умолчанию при создании новых проектов эта система выключена. Наверное поэтому мало кто знает о том, что в шарпах присутствует централизованное управление зависимостями (уже полтора года как, кстати)

👾 PICO

Четкие миграции

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

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

За свою практику я встречал 2 подхода к выкатке миграций и просто невероятное количество их костыльных реализаций.

Первый подход - идемпотентный (важно прочитать это слово правильно). Есть набор скриптов в котором описано конечное состояние базы данных. Накатываем скрипты - получаем готовую к использованию бд. При этом важно, чтобы повторная накатка скриптов не приводила к изменению состояния бд и не дублировала сущности (это и есть свойство идемпотентности). Нужно поменять схему? Меняй этот скрипт и накатывай повторно.

Второй подход - инкрементальный. Есть набор скриптов, у каждого скрипта есть версия. Все скрипты выполняются последовательно, в соответствии своих версий. Нужно поменять схему? Пиши новый скрипт.

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

Очень хорошим инструментом (но, к сожалению, не идеальным) для совмещения обоих подходов в .NET экосистеме является библиотека Evolve.

В концепцию гибридного подхода положено четкое разделение типов миграций: версионные и повторяемые.

Версионные миграции выполняются инкрементальным подходом, имеют версию и жёсткий порядок выполнения.

Повторяемые миграции ориентированы на идемпотентный подход. При каждом выполнении миграций все повторяемые миграции безусловно накатываются на БД.

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

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

👾 PICO

Chocolatey

В новом году, пожалуй, начнем разгон с чего-то попроще, скажем, с популярного пакетного менеджера для установки ПО на Windows.

Мой опыт переустановки винды сопряжён с болью, когда после каждой инсталляции необходимо заново ручками бегать по интернету и качать программулины. Примерно 30% от нужного софта вообще забываю поставить. Знакомо?

С пакетным менеджером Chocolatey этой проблемы больше нет. По сути тулза представляет собой централизованное место, откуда можно установить (почти) любой софт с помощью одной консольной команды.

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

Помимо установки, Чоко поможет вам и с обновлением приложений, весь софт, установленный с помощью пакетного менеджера можно обновить одной командой, как в маке или линуксе (если приложение имеет функцию автообновления, его можно исключить из обновлений Чоко)

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

Пользуюсь шоколадкой уже какой год и вам советую)

Chocolatey: Getting Started

#tools

👾 PICO

💻 Разработка под десктоп в 2024

Последние несколько лет не вылезаю из бекенд разработки, поднадоело.

Решил освежить в памяти и заодно узнать, какого это, пилить приложухи под виндовый десктоп в 2к24.

Из технологий у нас все так же есть WinForms и WPF - (не) стареющая классика. К ним добавились UWP (который за 3 года успел устареть и откиснуть) и MAUI (позиционирующий себя как эволюция Xamarin.Forms)

Трогать новые технологии от Майкрософта себе дороже, поэтому решил взять старый добрый WPF и проверить, а как же дела сейчас у старичка. Спойлер: все у него круто!

Во-первых, наконец, прислушались к сообществу и вместо необходимости использовать тысячи тысяч сторонних MVVM фреймворков нас встречает дружелюбный CommunityToolkit.Mvvm - официальный фреймворк от Майков.

Его снабдили полноценной документацией, большим количеством примеров и, что самое приятное, в него также встроили современные фичи языка, а именно Source Generators. Теперь писать ViewModel для XAML разметки стало на порядки быстрее и проще.

Пару слов про IDE. Я пользуюсь JetBrains Rider, и по сравнению с тем, какая поддержка WPF была в нем 5 лет назад - ощущение от разработки сейчас - это небо и земля.

Джеты подтянули XAML дизайнер, оптимизировали навигацию между разметкой и code-behind, надо проверить, есть ли hot-reload, а то руки не дошли посмотреть.

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

Может, стоит попробовать MAUI?..

👾 PICO

Data Oriented Design

Мы живём в мире, ориентированном на объекты. Есть сущности, они обладают определенными свойствами, поведением. Часть свойств можно увидеть из-вне, часть только при углубленном изучении, какие-то системы могут быть скрыты, поведение объектов может меняться в зависимости от обстоятельств...

Чистой воды объектно ориентированное программирование. Именно поэтому оно так популярно в айтишной среде, из-за своей обыденной простоты. "Ближе к народу", так сказать.

Мы уже давно отошли от процедурного программирования, перешли на следующей уровень абстракции, моделируем целые предметные области через призму реального мира (DDD), чтобы запускать успешные продукты. И это работает.

Но будучи сфокусированными на разработке конкретного проекта по устоявшейся методологии - упускаем очень много чего интересного вокруг.

Например, существует целое направление, пришедшее к нам из игровой индустрии под названием Data Oriented Design (DOD).

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

Как часто вы наблюдаете тормоза при работе с современными продуктами? Они, к сожалению, часто являются следствием неоптимального применения DDD, где используется богатая модель, когда надо, допустим, собрать объект из 10 таблиц для выполнения операции, занимающей 1 наносекунду.

Современные игры, однако, строят в основном с использованием подхода DOD, именно благодаря ему мы получаем 144 кадра в секунду при огромном количестве происходящих действий на экране. Вот это я понимаю, мощь.

DOD заставляет посмотреть на ООП под другим углом, а после прочтения информации об архитектурах, применяемых в DOD, например об Entity Component System (тема одного из следующих постов, кстати), трудно не воскликнуть "А что, так можно было?"

Про DOD на Хабре
Книга по DOD

👾 PICO

Безграничная фильтрация в MongoDB (нет)

Люблю монгу. Правда, отличная СУБД для повседневных задач. Когда начинаешь работу с этим инструментом - как будто попадаешь в сказку. Все удобно, быстро, что ни захочешь - будет.

И вроде бы все зашибись, но как и всегда бывает, в каждой бочке меда есть ложка дегтя.

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

Как это сделать на монге? Подержите мое пиво, берём документ, денормализуем все входящие в него поля в один массив, например, props, следующим образом:

{
    "_id": "000",
    "DisplayName": "Label",

    // ...

    "props": [
        { "k": "_id", "v": "000" },
        { "k": "DisplayName", "v": "Label" }

        // ...

    ]
}

Пишем механизм синхронизации этого поля, и все, что остается сделать - повесить индекс { "props.k": 1, "props.v": 1 } и перенацелить фильтрацию. В итоге мы получаем очень быстрый поиск по любой комбинации полей, при относительно небольших трудозатратах.

В чем загвоздка? Хе-хе-хе, а вот это нифига не очевидно. Как только вы попробуете посчитать количество документов, удовлетворяющих фильтру, вы будете неприятно удивлены скоростью работы этой операции.

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

В общем случае решить эту проблему (с сохранением первоначальных требований) на монге просто невозможно. Такие "тупые" ограничения и становятся причиной появления технологических "зоопарков", в данном случае можно внедрять ElasticSearch и поддерживать еще тонну кода.

Печально.

Пока что единственная СУБД, которая ни разу не подводила в таких вещах - это PostgreSQL.

👾 PICO

Entity Component System

Как-то года 4 назад я вбил в поиск гугла "хорошая архитектура". Вот так просто, без заморочек. Не "идеальная", чтобы не кликбейт, а вот просто "хорошая". Открыл вкладку с видео и начал смотреть.

На первой странице находился доклад Кирилла Надеждина про "архитектуру для всех" - ECS.

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

Так о чем эта архитектура?

Концепт достаточно прост, есть три типа "объектов":

- Сущность (entity). Это абстрактный объект, у которого есть только одно свойство - идентификатор (гуид, число - не важно). Можно представить, что это просто строка в базе данных с одним единственным полем - ID.

- Компонент. Это маркер, которым можно пометить сущность. На сущности могут находиться сколь угодно много компонентов самых разных типов. Если сущность можно было представить как строку в бд, то компонент - это колонка для этой строки.

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

Комбинация взаимодействий этих трёх объектов позволяет развивать сложные проекты достаточно большого масштаба. Overwatch, Operation Flashpoint, Raid: Shadow Legends, Baldur's Gate 3 - все эти проекты стали следствием применения паттерна ECS.

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

В ECS из коробки вы получаете data-oriented design, а следовательно, и performance. Наличие малого количества составных частей архитектуры (всего лишь три) гарантирует, что ваш код не превратится в ball of mud (хотя, если постараться, - все возможно)

Но паттерн подойдёт не всем. Я делал как минимум два подхода в попытке применить его к стандартным backend-сервисам, ориентированным на CRUD-операции. И каждый раз получается шляпа, все-таки не подходит ECS для стандартных бизнес-приложений, очередной "не silver bullet".

С другой стороны, в нестандартных задачах эта технология может раскрыться с очень положительной стороны. Например, если взять из ECS только концепт, связанный с хранением данных (entity и component), то оказывается, что подход идеально ложится на ситуации, когда вы не знаете доменную область на момент начала разработки. Динамические связи компонентов и сущностей позволяют менять доменную область "на лету", формируя ее по ходу разработки, а впоследствии закрепить стандартной реляционной схемой, когда вся доменная область будет "разведана" и понятна для команды.

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

Отличная статья на хабре про ECS - базовые концепции и overview

Dev Talk разработчиков Overwatch про ECS и сетевой код на backend'e

Доклад от разработчика Larian (Baldur's Gate 3) про правильное применение ECS

👾 PICO

PT Dephaze

Фух, мы это сделали.

На прошедшем мероприятии Positive Security Day наша команда продемонстрировала крупнейшим компаниям РФ первого автопентестера компании Positive Technologies - Dephaze.

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

Собственно, это основная причина изменений в частоте публикаций на канале. Я по уши в работе 💃

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

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

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

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

Мы точно очень скоро вас удивим ✌️

А запись мероприятия доступна тут (Зал Молекула, есть таймкоды, PT Dephaze на 05:23:00):
https://psd.ptsecurity.com/#live

Обязательно посмотрите вступительную заставку в самом начале (00:30:00), она очень кайфовая.

👾 PICO

Разработчики Visual Studio написали отдельный блог пост про то, что теперь в этой IDE можно КОПИРОВАТЬ ФАЙЛЫ между разными окнами приложения.

Шел 2024 год.

https://devblogs.microsoft.com/visualstudio/copy-files-across-instances-of-visual-studio/

👾 PICO

Приколы межпроцессной буферизации

В операционных системах существует традиционное разделение потоков консольного вывода программ на stdout и stderr.

Stderr - поток для сигналов, что что-то идёт не так. Обычно туда попадают ошибки, исключения и различного рода крэши.

Stdout в свою очередь - это место, куда летит оставшийся вагон логов исполняемой программы.

Но кроме концептуальных различий между ними есть ещё кое-что. Буферизация.

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

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

Стандартный поток вывода по-умолчанию буферизируется, а вот поток ошибок - нет.

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

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

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

А если речь идёт о процессе, который нужно повесить в фоновое исполнение надолго... То из родительской программы в реальном времени мы увидим логи примерно никогда.

Такое поведение можно переопределить, и в языках высокого уровня (например в dotnet) это "исправлено" из коробки: мы увидим построчный вывод даже из другого процесса. Но на низкоуровневых языках типа C/C++ разработчики сами принимают решение о "выносе мусора".

И если они не подумали об этом и оставили поведение по-умолчанию, и уж тем более не дали возможность этим управлять - придется наслаждаться пустым аутпутом в дочерних процессах или городить костыли, эмулируя подключение терминала, либо же запускать программу через прокси-процесс для контроля буферизации.

Так и живем.

👾 PICO

PT Dephaze - наш первый вебинар

Приглашаю всех заценить какой же все-таки кайф мы делаем 17 декабря в 14.00 (МСК) на вебинаре, посвященном Dephaze - флагманскому атакующему продукту Positive Technologies по автоматическому пентесту корпоративных инфраструктур!

А еще, мы запустили обратный отсчет до коммерческого запуска и старта первых пилотов. Смотрю на этот таймер и страшно становится. Но! Придуманная нами технология настолько перспективная, что приходится вырабатывать механизмы "сдерживания" этого монстра, чтобы он не сделал то, что не должен (а может он огого).

Кароч, завтра, 14.00 по мск, покажем реальную инфру, реальные атаки, без ерунды, будет интересно, залетай 😎

https://dephaze.ptsecurity.com/

👾 PICO

Лучший скриптовый язык для .NET разработчика

Наверняка всем знакома история с bash/poweshell-скриптами для деплоя приложения на окружение.

Приходишь в проект, а там ЭТО: сотни строк кода вперемешку с магическими константами, циклы и условные конструкции, которые несут для разработчика, читающего этот код, только одно - страдание.

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

Есть универсальное решение этой задачи - грамотно выстроенный CI, но иногда без скриптов обойтись действительно нельзя ввиду различных ограничений, или просто нужен быстрый fallback-вариант автоматизации.

C# обладает скриптовым диалектом, но жесткость синтаксических конструкций может приводить к появлению лишнего кода, а лишний код мы писать не хотим, особенно когда дело касается скриптов :)

Для такой задачи идеально подходит F#.

Во-первых, в F# вы (практически) никогда не словите NullReferenceException. Что бы вы не написали, если код компилируется - значит он будет исполнен так, как вы его написали, без всяких неявностей и потенциальных warning-ов. Добавим сверху ещё иммутабельность по-умолчанию и получим удобную и эффективную отладку.

Во-вторых, используя F#, вы получаете возможность использовать всю силу экосистемы dotnet. Нужно подключить в скрипт внешнюю .dll-библиотеку? Или вообще использовать внешний nuget-пакет? Легко, добавляем директиву #r и используем внешний код из коробки. А подключить код из другого скрипта поможет директива #load

В-третьих, F# очень давно заточен быть в том числе скриптовым языком, что способствовало появлению масштабных инструментов, ориентированных на использование в контексте скриптов. Например, F# Make (FAKE), с помощью которого можно разбивать скрипт на шаги и контролировать пайплайн его исполнения более декларативно. По удобству - почти как docker compose, с сохранением гибкости языка.

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

Активно пользуюсь F# скриптами в своей деятельности, и вам советую)

А начать свое погружение в удивительный мир функциональщины на F# рекомендую тут:
https://fsharpforfunandprofit.com/

👾 PICO