C# *

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

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

Теги: #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# в Интернете или давно утратили актуальность, или содержат лишь небольшие вкрапления новых возможностей, но лишены последовательности. Есть и другая крайность - ИИ простыни сгенерированного текста под видом статей, которые очень тяжело читать. Я хочу сделать свою попытку изменить ситуацию.

С момента прошлой статьи прошло достаточно много времени и я заметил одну интересную вещь: немало людей добавили статью в закладки, несмотря на небольшое число отметок “нравится”. Это убедило меня в полезности материала и потому я решил написать вторую часть.

Я начал разработку Minecraft на движке Unity. Пока не решил, какие механики я повторю из оригинала, а какие добавлю от себя. Но сегодня я вам расскажу о моей логике построения чанка.

Далее предоставлю полный скрипт для построения чанка.

Абстракции… Абстракций много не бывает!

SerializeReference в Unity интересная штука, а что если попробовать использовать ее чуть дальше базовой реализации?

Используй JSON для создания LINQ-выражений!

Если черный ящик поддерживает входные сигналы в форме JSON, то им могут пользоваться самые разные клиенты!

Доброго времени суток, уважаемые хабровчане! Я живу в Ташкенте.

Как превратить беспокойство о качестве воздуха в полезный Open Source проект?