C# *

Вступление
В прошлой статье я показывал,как мы в AGIQ Solver Enterprise применили квантово‑вдохновлённый популяционный подход на GPU для NP‑задач и получили ускорение на практических постановках в 50–100 раз по сравнению с последовательным перебором и плохо распараллеливаемыми схемами.

Сегодня — следующий шаг:покажу,как задачи машинного обучения можно кодировать в SAT/MaxSAT, а затем решать обычным NP‑солвером — тем же AGIQ Solver Enterprise.

О чём статья (и что мы НЕ делаем)
Мы не будем пытаться “запихнуть” в SAT весь мир DL (ResNet/LLM/градиенты/батчи). Это плохая идея: там, где нужна дифференцируемая оптимизация, SGD остаётся королём.

Зато есть большой класс ML‑задач, где:
модель дискретная или может быть дискретизирована,
важны ограничения (fairness/монотонность/запреты/политики),
важна проверяемость и воспроизводимость решения,
нужен глобальный поиск (а не локальная оптимизация по градиенту).

Вот здесь SAT/MaxSAT — это не экзотика,а универсальный язык “правила + ограничения + оптимизация”.

Почему SAT вообще способен “кодировать что угодно”
В теории, любой NP‑вопрос можно редуцировать к SAT. На практике это означает простую вещь:

Статья для junior‑разработчиков C#, которые хотят развиваться в профессии, но теряются в разнообразии источников знаний: книги, подкасты, видео, разборы, ChatGPT. Читать и смотреть все подряд никакой жизни не хватит, а выделить нужный базовый стэк сложно — не хватает знаний и опыта. В статье даем структуру: какие темы и по каким источникам изучать, чтобы получить необходимую базу для профессионального роста.

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

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

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

- часть проверок живeт во фронтенде

- часть - в API,

- часть - в промежуточных сервисах

- часть — во временных проверках, добавленных после инцидентов

Добавили новый сервис в цепочку - и изменилось поведение.

Вынесли проверку в отдельный процессинг - и появились состояние гонки.

Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.

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

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

Мы отвлекаем существенные ресурсы в поисках решения для проблем.

Хочу поделиться проектом, который может оказаться полезным тем, кто всё ещё разрабатывает/поддерживает десктопные .NET Framework приложения на WinForms.
В моей организации - как, наверное, и во многих других - среда разработки Microsoft Visual Studio оказалась под запретом, причём как её коммерческие версии, так и Community Edition. Всем было рекомендовано перейти на VS Code, которая хороша во всём, кроме полноценной поддержки WinForms-приложений. А именно - VS Code, в отличие от "обычной" Visual Studio, не имеет встроенного редактора (дизайнера) форм, без которого вёрстка сложных форм становится как минимум неудобной. Если с редактированием "code behind" файла проблем нет (Form1.cs, UserControl1.cs), то с файлом, описывающим «визуальщину» (Form1.designer.cs, UserControl1.designer.cs) - беда: в VS Code его можно править только на уровне кода, "WYSIWYG experience" тут недоступен.

В статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных» рассмотрен подход к построению многослойной архитектуры приложения с использованием трёх слоёв и девяти подслоёв.

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

Анализируя типовой функционал приложения можно выделить 9 основных архитектурных блоков.

Привет, Хабр! Я магистрант первого курса по направлению «Искусственный интеллект и предиктивная аналитика» и параллельно — действующий разработчик. Пройдя несколько кругов ада собеседований, я задалась почти философским вопросом: а можно ли самостоятельно определить собственный грейд, еще и не ошибиться относительно рынка и целевой компании?

Этот вопрос стал основой моей ВКР на тему «Разработка методики определения квалификационного уровня программиста на основе мультимодального анализа».

Вместо того чтобы гадать, я решила довериться данным. Я собрала датасет из 721 вакансии стека C#/.NET и 16 различных репозиториев, прогнала их через LLM (Saiga Llama 3) и нейросеть GraphCodeBERT, чтобы найти объективные метрики «сеньорности».

По моей задумке (и уже работающему прототипу), методика позволит оценивать грейд не по лайв-кодингу, а по «цифровому следу» программиста — его репозиторию. Цель этой статьи — показать «внутреннюю кухню» исследования, поделиться первыми инсайтами о том, как нейросети видят наш код, и получить вашу обратную связь, чтобы подготовиться к главному вопросу на защите: «А зачем всё это надо?».

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

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

Всех приветствую - меня зовут Худошин Илья (https://t.me/Official_Lays), я разработчик десктопных, серверных и веб приложений.

Хоть и в последнее время я не пишу решения на .net, но мне совсем недавно пришла одна интересная мысль как можно решить одну из самых распространенных проблем в разработке плагинов для Autodesk Revit и я решил попробовать реализовать это.

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

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

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат.

В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

Разбираем изменения в OWASP Top 10 версии 2025 года на примерах и рассматриваем, как SAST может помочь избежать уязвимостей.

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

Заваривайте чай и готовьтесь к погружению: сейчас мы будем препарировать код метриками, эмбеддингами и суровой статистикой

229 заездов, 140 пилотов, 28 часов работы — столько данных мы собрали из Assetto Corsa за три дня SOC Forum 2025.

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

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

Итак, Вам не повезло, Вы – техлид (тимлид, главный инженер etc) большого и старого проекта на C#, который был написан в доисторические времена, когда async еще не завезли. Проект старый и большой, но живой и развивается. Может быть даже, что проект использует современный .NET, современную версию C#, но вот незадача – не использует async, а очень бы хотелось.

 Как осуществить такой рефакторинг и какие трудности ожидают на этом пути?

Программа визуализирует решение и промежуточные результаты задачи Дирихле для уравнения Лапласа/Пуассона в прямоугольнике на CPU и GPU.

Уравнение Пуассона(при уравнение Лапласа) :

Задача Дирихле(краевые условия 1-го рода) - заданы значения на границе области(в данном случае в прямоугольнике).

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

Введение

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

Написал ИИ-оверлей для прохождения собеседований

Я — .NET-разработчик, и уже некоторое время прохожу собеседования. Иногда на них задают вопросы про такие «пыльные уголки» .NET, что если я и читал про них, то лишь в самом начале своего пути, листая книги Рихтера, Троелсена и Шилдта.

А ещё встречаются откровенно странные задачи, далёкие от реальной работы.

Зачем всё это? Очевидно, чтобы отсечь новичков из онлайн-курсов и тех, кто «вкатился» в IT без должной подготовки.

Ну а раз на собеседовании всё изначально настроено так сказать «враждебно», и интервьюер подозревает, что каждый мухлюет… почему бы действительно не начать мухлевать?

В рамках одного из обсуждении с чатах я предложил использовать функцию Merge для  IAsyncEnumerable<T>, чтобы объединить результаты чтения однотипных данных из разных источников. Но когда попытался сделать пример оказалось что такой функции в System.Linq.Async нет. Есть аналог в Reactive Extensions, но тащить библиотеку для одного примера не захотел и решил написать сам.

В команде, большая часть серверных фич пишется с помощью стейт машин.
Стейт машина позволяет выразить окружающее состояние и то как с объектом можно взаимодействовать предельно конкретно. Хорошо составленный стейт граф позволяют понять как работает фича без глубокого погружения в код. При прохождении code review большое внимание уделяется составленному графу состояний. Часто возникает потребность в чтение или модификации уже существующего кода. Отсюда возникает потребность в ускорении процесса восстановления контекста или понимании как работает код.

На помощь приходит статический анализ кода.

Привет! Меня зовут Игорь, я занимаюсь разработкой на Unity c 2018 года.
В этой статье расскажу, как с помощью Roslyn можно автоматизировать задачи.