В эпоху стремительного развития ИИ, привычка заглядывать в Википедию постепенно уходит — зачем читать целую статью, когда любой ответ можно получить за доли секунды от чат-бота?
Я решил переосмыслить этот тренд и вдохнуть новую жизнь в классический формат рубрик «Что было в этот день». Внутри описание, как мы с помощью игрового телеграм бота, Wikipedia API, GPT-моделей и Flux мотивируем читать людей википедию.
Классический ILogger.LogInformation($"User {userId}") выглядит безобидно, но на деле компилятор: формирует итоговую строку через string.Format‑like логику, боксит userId, DateTime, struct‑ы и прочее добро, а так же линкует все в object[] ради структурированных логов.
Аллокационная цена вопроса — порядка 80 Б на сообщение (плюс трансферы в LOH, если вы особо многословны).
В.NET 8 Microsoft даже вынесла отдельный раздел «high‑performance logging» и честно сказала: «Да, обычные extension‑методы логов боксят и аллоцируют»
С выходом C# 10 компилятор научился разбирать $"строка" не напрямую в string, а в handler: структуру, которая получает куски литералов и плейсхолдеры. Базовый — DefaultInterpolatedStringHandler.
Что может заставить обратить внимание на красно-чёрные деревья, и как их реализовать? Статья ответит на оба эти вопроса. Бонусом будет показано, как на основе красно-чёрного сконструировать дерево интервалов.
Первые шаги в дополненную реальность. Простой туториал по AR Foundation в Unity для начинающих. Создай свое первое AR-приложение.
Всё проще, чем кажется!
Надругательство над C#, C++ и HLSL, игрища с булками и буферами, тройная полиглотность, SIMD, пепекторы, DirectX, экономия 800 Тб ОЗУ, новая парадигма программирования, многопроцессность, быстрая степень и многое другое.
В этой части я расскажу, как делал софт на собственном фреймворке, который управляет ядерной подсветкой и механической видеостеной.
Реализация системы управления волнами для создания захватывающих столкновений с противниками — это достаточно эффективный способ постепенно увеличивать сложность, поддерживая вовлеченность игроков. В этом руководстве я поделюсь с вами своим опытом реализации WaveManager'а в Unity, включая создание скриптов, генерацию врагов и интеграцию пользовательского интерфейса.
Представьте: Вы добавляете новую механику, а игра ломается в пяти местах. Вы тратите часы на поиск того самого скрипта, который неожиданно зависит от ваших изменений. Знакомо?
Zenject (Extenject) решает это раз и навсегда.
Эта статья о том, что такое zenject и как им пользоваться.
Разработка через типы (Type-Driven Development, TypeDD) — это методология программирования, при которой вы начинаете с написания определений типов, которые служат точной спецификацией вашей программы. Вместо того чтобы сначала писать код, а потом добавлять тесты или типы, вы используете компилятор как интерактивного ассистента, который направляет вас к созданию программы, удовлетворяющей заданным типам.
Idris — это чистый функциональный язык программирования, созданный Эдвином Брэди, который идеально подходит для этого подхода благодаря поддержке зависимых типов.
Но попробуем использовать его идеи на практике вне Idris.
Попробуем сравнить такие метрики как
1. Время проектирования (момент, после которого разработчик может больше не соприкасаться с предметной областью, а руководствоваться только ТЗ)
2. Время до выкатки на прод
3. Частота ошибок на проде (и как следствие, ущерб бизнесу и затраты на сопровождение)
В этой статье мы разберем неявное использование многопоточности с Unity Job System: узнаем про преимущества использования такого подхода перед явным созданием потоков, поговорим про неуправляемую память, про преимущества неуправляемой памяти перед управляемой и многое другое...
ГОСТ Р 71207-2024 "Статический анализ кода" выделят класс дефектов в коде, называемых критическими ошибками. При разработке безопасного программного обеспечения (РБПО) такие дефекты должны в обязательном порядке выявляться и исправляться в приоритетном режиме. Статический анализатор PVS-Studio разрабатывается с учётом этого стандарта и позволяет выявлять все типы критических ошибок в коде программ, написанных на языках C, C++, C#, Java. Рассмотрим эти типы предупреждений и как их можно выделить среди других предупреждений, выдаваемых анализатором.
Garbage Collector (GC) — одного из самых важных «невидимых помощников» в.NET.
Он избавляет нас от ручного управления памятью, но как именно?
Я много общаюсь о микросервисных архитектурах с «не-Java-людьми» — будь то разработчики на C#, энтузиасты Node.JS/JavaScript или GoLang. Все они сталкиваются с необходимостью оркестрации в микросервисной архитектуре — или просто хотят использовать workflow, упорядочивание действий, обработку таймаутов, Saga и компенсации, а также другие полезные возможности.
Open Source BPM-платформа Camunda отлично подходит для этих задач. Ориентированность на разработчиков — один из ключевых принципов продукта, но при изучении документации может показаться, что она рассчитана в основном на Java-разработчиков. Платформа предоставляет множество точек расширения и интеграции, но всё это реализуется на Java. Значит ли это, что другим разработчикам путь закрыт?
Нет! На самом деле, запустить Camunda и работать с ней без знания Java очень просто — архитектуру можно выстроить так, чтобы писать код на любом удобном языке. В этом посте:
Я хочу поделиться практическим подходом, который позволяет переиспользовать ваш игровой код на C# из Unity на .NET-бэкенде — это даёт возможность верифицировать действия игрока, защищает от читерства и обеспечивает мгновенный отклик без лагов.
Я использую такую архитектуру в продакшене уже более 10 лет, и она отлично зарекомендовала себя как надёжное и эффективное решение. В этой системе один и тот же код выполняется и на клиенте (для мгновенной обратной связи), и на сервере (для авторитетной проверки).
Как это работает:
• Команды игрока мгновенно выполняются на клиенте.
• Та же команда вместе с хэшем состояния отправляется на сервер и повторно выполняется для верификации.
• Любые попытки изменить код или память клиента будут обнаружены и отклонены сервером.
• Игровая логика вынесена в .dll-плагин, который используется и в Unity-клиенте, и на .NET-бэкенде.
В статье есть полноценный пример на Unity («Connect Four»), открытый исходный код и подробное описание архитектуры.
Автоматическое тестирование, включая модульное и интеграционное, хорошо документировано и поддерживается множеством библиотек и платформ. Однако с ростом сложности приложений и увеличением количества пользовательских сценариев возникают новые проблемы, требующие современных инструментов.
В этой статье мы рассмотрим Scand Storm Petrel — инструмент для .NET-разработчиков, который автоматизирует однотипную работу по формированию и обновлению ожидаемых значений в тестах. Это особенно актуально при большом количестве тестовых сценариев или сложной структуре тестируемых объектов, что является неотъемлемой частью разработки современных приложений.
Сложная и тяжелая статья с непропорционально простым выводом. Вспомним фон Неймана, затронем процессорный кеш, поговорим про регистры и компиляторы. Тем, кому не хочется погружаться в детали, достаточно прочитать только Введение и Выводы.
Я, думаю, многие уже слышали о появившихся в .NET 6 Minimal API - легковесной замене контроллеров/MVC. Кто-то уже успел ознакомиться и задался вопросом: "Ваше API в 3 строчки, это, конечно, здорово, но как это будет работать в реальном проекте с сотнями эндпоинтов, кучей фильтров, аттрибутов, расширениями OpenAPI/Swagger и прочих радостях?"
В этой статье я хочу ответить на этот вопрос: пройдемся от основ, преимуществ, недостатков, и закончим нюансами работы и проблемами, которые обязательно возникнут при миграции с контроллеров на Minimal API в крупном проекте.
А забегая чуть вперед: если думаете, стоит ли переводить проект на Mini API, вот вам сразу полезная информация: они могут жить в проекте вместе, причем даже без дублирования инфраструктуры: не обязательно переводить все разом - подробнее под катом.
Бонусом, заменим SwaggerGen на реализацию OpenAPI от Microsoft.
Простой вопрос: делая задачу, касающуюся API - вы чаще работаете с одним эндпоинтом, или пишете, условные, репозитории, которые используются сразу в нескольких эндпоинтах? Скорее всего, первое, тогда почему мы разбиваем проект по слоям, а не по фичам (эндпоинтам)?
Это видно в часто используемых нынче архитектурных подходах: Layered, Clean Architecture, Onion, и так далее. Не буду выделять что-то конкретное и объясню общую разницу в подходах:
Vertical Slice Architecture (VSA) строится вокруг каждого отдельного feature-слайса (эндпоинта, как самый простой пример), а не вокруг слоев.
То есть, если код относится к конкретному эндпоинту, мы не размазываем его по всему проекту в папках Commands/Services/Repositories/DTOs и т.п., а кладем в одно место, там где и будет находиться эндпоинт
Главный принцип - уменьшаем связанность между слайсами (фичами), увеличиваем связанность внутри слайса
В прошлом месяце я зарелизил ZLinq v1 — революционную LINQ-библиотеку, которая достигает zero allocation на структурах и дженериках. Она может похвастаться такими расширениями, как LINQ to Span, LINQ to SIMD, LINQ to Tree (FileSystem, JSON, GameObject и т.д.), drop-in replacement Source Generator для произвольных типов, поддержкой нескольких платформ, включая .NET Standard 2.0, Unity и Godot и на данный момент ZLinq имеет более 2000 звезд на GitHub.
Пол года назад я начал копаться в исходном коде рослина, что бы понять, что такое красно-зеленые деревья, и вот это моя выжимка, и то что я бы хотел прочитать полгода назад.
