C# *

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

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

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

Привет, Хабр! На связи снова разработчик из компании АльфаСтрахование. Наша скрам-команда занимается автоматизацией бизнес-процессов Операционного блока, и для решения многих задач нам часто требуются фоновые операции. В этой статье я расскажу о шаблоне фонового сервиса на .NET, который мы используем в своей работе

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

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

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

Привет! Я Миша Симонов. Работаю в Контуре ведущим специалистом по тестированию и являюсь техлидом по автоматизации тестирования кластера из 18 команд.

Когда говорят про архитектуру UI-тестов на Selenium или Playwright, то ограничиваются объяснением паттерна Page Object Model. Но достаточно ли только знания POM в современном мире программирования?

В этой статье я постараюсь мягко провести вас от классического Page Object Model к архитектуре, основанной на композиции и Dependency Injection. Я убеждён, что написание тестов — это такое же программирование, как и разработка фич. Здесь нужны те же современные практики: DI, чистая архитектура, композиция, SOLID — всё, что делает код гибким и живучим.

Потому предлагаю рассмотреть значимые части архитектуры тестов и разобраться в том, что за зверь такой — композиция — и как его приготовить. А готовить мы будем на NUnit, Playwright на C# и Microsoft.DependencyInjection. 👨‍🍳

BlockingCollection<T> долгое время был стандартом для producer/consumer в .NET. Он работает, но построен на блокирующих примитивах — когда очередь пуста, читающий поток висит на Monitor.Wait(). В мире async/await это антипаттерн: заблокированный поток — потраченный ресурс.

System.Threading.Channels грамотно решил эту проблему. Lock-free структуры данных, async API, контроль backpressure, интеграция с пайплайнами обработки данных. Это не замена BlockingCollection — это просто другой уровень.

Разберём, как Channels устроены, когда их использовать, и какие паттерны они открывают.

Привет, Хабр! Меня зовут Гоша, я старший инженер-программист в Контуре. Практически любой сценарий ЭДО связан с использованием криптографии, будь то ЭДО с государством или контрагентами: где-то нужно подписать документы, где-то зашифровать архив с отчётом, где-то проверить подпись документа от контрагента. Каждый из таких сценариев хочется тестировать не на реальных данных, но на наиболее похожих в реальности. Помимо самих данных нам нужны сертификаты, имитирующие сертификаты участников ЭДО: организаций, физлиц, государственных органов. Ранее для генерации тестовых сертификатов мы использовали сервис на базе ПАК УЦ, проприетарной штуки, выпускающей сертификаты по определённым правилам, не позволяя издеваться над сроками действия серта как хочется.

Отсюда появилась идея в качестве эксперимента написать небольшой сервис, который мог бы генерировать какие угодно сертификаты с ГОСТ-алгоритмами, но при этом успешно работающие с КриптоПро. В этой статье хочу поделиться, какая техника скрывается под капотом такой функциональности.

Теги: #monogame #gamedev #оптимизация #csharp #графика #индиразработка

Введение: Проблема падающих FPS и желание красоты

Каждый разработчик 2D-игр, мечтающий о живом, населённом мире, рано или поздно упирается в суровую реальность: рендеринг множества уникальных анимированных персонажей — это дорого. Хочется дать игроку кастомизацию, смену снаряжения, разнообразие врагов, но классический подход «нарисовать каждый спрайт отдельно» ведёт к сотням draw calls и падению производительности.

В своей инди-игре (симуляторе жизни в мире фэнтези-жуков) я столкнулся с этой проблемой в полный рост. Мне нужны были десятки NPC на экране, каждый — с возможной сменой брони и оружия. Решением стала гибридная система рендеринга, основанная на разделении персонажей по уровням детализации и использовании инстансинга. В статье я разберу её архитектуру, код и полученные выгоды.

Часть 1: Анализ проблемы — почему «в лоб» не работает

Допустим, у персонажа 10 слоёв: тело, голова, ноги, броня, шлем, оружие в каждой руке и т.д. Если рендерить каждый слой отдельным вызовом SpriteBatch.Draw(), для 50 NPC мы получим 50 × 10 = 500 draw calls. При целевом значении в 60 FPS у нас есть всего ~16.6 мс на кадр. Если один draw call занимает ~0.1 мс, только на отрисовку персонажей уйдёт 50 мс — это в три раза больше бюджета!

Ключевой инсайт: Не всем персонажам нужна одинаковая детализация. Фоновому горожанину или стае врагов не требуется динамическая смена снаряжения. А главному герою — требуется.

Часть 2: Гибридная архитектура — 3 уровня детализации

Привет, Хабр! Меня зовут Митя, я инженер-программист в Контуре. Во время написания кода анализаторы иногда предлагают заменить привычные конструкции на pattern matching. Однако то, что призвано повысить читаемость, нередко делает код более трудным для восприятия, особенно, если не понимать, во что именно разворачиваются те или иные конструкции. И в один из дней я задался вопросом: а есть ли какие-нибудь подводные камни при использовании pattern matching и во что именно его преобразует компилятор? В этой статье — мои мысли и заметки.

Меня зовут Степан, я C# профессионал уже более 7 лет на рынке и рассказываю об этом в Telegram каналe StepOne. В этой статье я покажу вам личную подборку 9ти underground NuGet пакетов. Вы наверняка не встречали их на работе, потому что они либо решают конкретную специальную задачу, либо решают известные задачи нестандартным подходом, либо ещё недостаточно известны на рынке РФ. Мне же удалось затащить их на прод и пощупать в бою!

Я люблю простые костыли.

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

// Name/Value item
public class NVItem {
public string? Name;
public object? Value;
public IEnumerable? SubItems;

public NVItem(string? name, object? value) {
Name = name;
if (value==null) return;
SubItems = value as IEnumerable;
if (SubItems != null) return;

// Упс!
Value = value as string;
if (Value != null) return;

var num = value as IEnumerable;
if (num==null) {
Value = value;
} else {
SubItems = num.Cast<object>().Select(t => new NVItem(null, t));
}
}
}

Если вы когда-нибудь задумывались, можно ли запустить бенчмарк, используя всего один C#-файл, то ответ: да, можно. Начиная с .NET 10, существует возможность создавать C#-приложения в одном *.cs‑файле. Проблема в том, что BenchmarkDotNet (BDN) не поддерживает такие бенчмарки с настройками по умолчанию. В этой статье я покажу, как обойти это ограничение, используя режим in-process.

Все мы знаем стандартную лестницу: Junior, Middle, Senior. Но где на самом деле проходит граница? Почему в одном стартапе «сеньор» — это тот, кто вчера узнал про LINQ, а в кровавом энтерпрайзе от «мидла» требуют проектировать распределенные системы под нагрузкой в миллион RPS?

Я задалась вопросом оценки собственного грейда, когда уходила со своего первого места работы. Кто я для рынка? Почему мои знания на собесе в одной компании соответствуют чуть ли не уровню Senior, а в другой – покрывают максимум вакансию Junior’a?

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

Я решила отойти от субъективности и спросить у самого рынка. В этой статье — результаты анализа 700+ актуальных вакансий .Net разработчика, графы связности навыков и ответ на вопрос: в какой момент количество выученных библиотек наконец-то превращается в качество инженера.

Разрабатывая новую систему отчетности, возник вопрос – а не добавить ли нам AI как-нибудь куда-нибудь? Не, ну а что – это модно, стильно, да и вообще - ни один нормальный новый проект не может вынести отсутствия AI. Задача не выглядела сильно сложной. Прокинуть вопрос пользователя из интерфейса на бэк – стандартная задача, Ollama устанавливается парой кликов, скачать и запустить модель – это 2 команды, а то и одна, если хорошо постараться. Доступ к модели возможен по web api из бэка на C#, документация по Ollama есть… Что тут может пойти не так, верно?

В .NET есть обширный набор типов для работы с временем. Но нет решения для работы с интервалами времени. Я такое решение сделал и хочу о нем рассказать.

Продолжаю разрабатывать Minecraft на движке Unity. В этой статье я покажу мою реализацию разрушения блоков - перестройки чанков. Это будет моя вторая реализация.

Перед прочтением этой статьи, советую ознакомиться с моей предыдущей статьей.

Моя первая логика основывалась на полной перестройке чанка после удаления блока. Это работало без багов и не сильно влияло на производительность. Но я решил поэкспериментировать со своей игрой, поставил высокую скорость разрушения и блоки разрушались 1 блок за кадр или около 100 - 300 блоков в секунду. При таком раскладе игра начинала тормозить, не сильно, но заметно. Конечно я не планировал оставлять такую скорость разрушения, но, если я могу увеличить производительность, то нужно реализовывать.

Как же на меня ругался ИИ, когда я скидывал ему свой код. Он мне советовал остановиться на полной перестройке чанков (моя первая логика), но я все же ее переделал, и остался доволен результатом.

Далее расскажу о всех деталях:

Первым делом я вынес Mesh и его параметры (Vertices, Triangles и т.д.)

В этой статье я покажу, как с нуля подключить OpenTelemetry в ASP.NET Core проект и получить полноценную наблюдаемость: распределённые трейсы, метрики и логи. Мы не будем углубляться в теорию (что такое спаны/трейсы/метрики и почему это важно) - сфокусируемся на практике.

Мы развернём небольшой "микросервисный" стенд в Docker Compose и после пары запросов увидим в SigNoz полный набор сигналов: трейсы, метрики и логи с корреляцией по trace_id. Все исходники доступны в репозитории GitHub так что каждый шаг можно повторить самостоятельно.

Часть 1

Во второй части руководства для начинающих будет рассмотрено ООП и некоторые другие возможности.

Метод программирования, именуемый аспектно-ориентированным, впервые явился миру в конце девяностых годов прошлого века, когда группа исследователей из Xerox PARC под руководством Грегора Кичалеса решила, что объектно-ориентированного подхода человечеству недостаточно. Они создали AspectJ — расширение для Java, призванное разрешить проблему, которую окрестили «сквозной функциональностью». Суть проблемы проста до безобразия: код логирования, обработки ошибок, проверки прав доступа и прочих служебных радостей размазывается по всему приложению, как масло по по́лу, превращая элегантную бизнес-логику в свалку повторяющихся конструкций.

Аспектно-ориентированное программирование предлагает выделить эти сквозные concerns в отдельные сущности — аспекты, которые можно применять к коду декларативно, не засоряя основную логику техническими деталями. В теории звучит как серебряная пуля. На практике AspectJ оказался инструментом, требующим от программиста понимания магических pointcut expressions и готовности смириться с тем, что код компилируется через специальный компилятор, производящий байткод, который отладить можно только с поллитрой, бубном или молитвенником.

Ранее я написал об этом пост, но потом набралось больше материала и я расширил до статьи.

Работая над одним из проектов, который недавно переехал из Framework 4.8 на Core 9, обнаружил множество самых разных вариантов использования модификатора required и атрибута Required, примерно каждый второй из которых был использован неправильно. Я написал это коллегам и хочу поделиться этим здесь. Это не обязательные правила, но сильно упрощают работу с кодом.

Большинство гайдов по C# в Интернете или давно утратили актуальность, или содержат лишь небольшие вкрапления новых возможностей, но лишены последовательности. Есть и другая крайность - ИИ простыни сгенерированного текста под видом статей, которые очень тяжело читать. Я хочу сделать свою попытку изменить ситуацию.