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

Социальный долг

На днях посчастливилось прочитать в книге Креативный программист (Ваутер Грунефелд) про один термин, который сильно привлек мое внимание - социальный долг.

Сначала, я интерпретировал его как долг перед обществом или коллективом, про личную ответственность в рамках какого-то сообщества. Но тезис про другое.

В среде программистов есть устоявшееся словосочетание - технический долг. Мы говорим про него как про что-то, что мешает долгосрочному развитию кодовой базы, достижению архитектурной гибкости, негативно влияет на Developer Experience или просто "плохо пахнет".

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

Для этого он приводит очень интересные примеры "маркеров" социального долга, которые могут присутствовать в любом сообществе, объединенном общей целью, ниже примеры некоторых из них:

- Заброшенность новичков. Ситуация, при которой процессы онбординга неэффективны или отсутствуют вовсе.

- Одинокие волки. Сотрудники, которые действуют не учитывая мнение других членов команды.

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

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

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

И даже, немного, собственному самоопределению в коллективе.

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

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

👾 PICO

MECE - Mutually Exclusive and Collectively Exhaustive

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

Не знаю, вдохновлялись ли аналитики, придумавшие MECE, ВУЗовским тервером, но в 1960-х они как будто бы переизобрели полную группу событий, но для бизнеса, накинули ярлык "принципа" и достаточно замысловато назвали: Mutually Exclusive (взаимно исключающее) and Collectively Exhaustive (совместно исчерпывающее).

Начнем рассмотрение принципа с очевидного примера, так будет проще.

Задача
Мне нужно быть в офисе завтра в 10.00 утра

Очевидные решения
- Пойти в офис пешком
- Поехать на машине
- Поехать на метро

Теперь попробуем применить MECE к данной задаче.

Видно, что два последних варианта не являются взаимно исключающими, так как в них используется один и тот же способ движения - "поехать".

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

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

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

Задача
Мне нужно быть в офисе завтра к 10.00 утра

Решения по MECE
- Пойти в офис пешком
- Использовать транспорт
- Не покидать офис сегодня

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

Хотя MECE и помогает в поиске решений, он также подвергается критике из-за жестких условий применения. Например, что если пересекающиеся решения будут более оптимальны к применению в рамках задачи? Или бывает так, что проблематика очень многогранна и не делится на взаимоисключающие блоки отдельных проблем, о которых можно думать подобным образом.

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

👾 PICO