C# *

В последнее время среди игровых разработчиков возрос интерес к паттерну "Шина Событий". Этот паттерн часто ругают за его тенденцию к "размыванию логики" и "скрытию зависимостей". Однако, несмотря на критику, полный отказ от этого паттерна также глуп как и написание кода в блокноте вместо специализированной IDE. В этой статье рассмотрим создание игры, целиком основанной на этом паттерне, и поработаем с такими библиотеками, как Zenject, UniRx, и DoTween.

Несмотря на то, что с предыдущей статьей-переводом мы выяснили что перевод уже есть на Хабре я рискну продолжить анализ этой работы.

Теперь это НЕ перевод. Это моя интерпретация тех частей содержания первой половины Поста: Как на самом деле Async/Await работают в C#, которые мне показались заслуживающими внимания в этой работе, с моими пояснениями относительно того почему у меня возникла именно такая интерпретация материала.

Судя по количеству просмотров, работа вызывает интерес, но пробиться сквозь нагромождение терминов трудно даже для подготовленного читателя, как мне кажется. Я хочу попробовать перевести не с английского на русский, а с некоторого кулуарно-профессионального на какой-то более доступный язык. Не знаю, насколько доступный, надеюсь получить некоторый отклик, который поможет мне понять, насколько у меня это получилось. Заранее хочу сказать, что автор действительно изложил как или во что компилируются конструкции Async/Await и, соответственно, как они работают изнутри. Проблема в том, что автору пришлось написать большую подготовительную часть чтобы подвести к изложению этого внутреннего устройства Async/Await. И мне, волей неволей, придется пройтись по всему что предваряет, собственно, основную идею в реализации Async/Await. Поэтому запаситесь терпением либо начинайте читать сразу последнюю часть.

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

Дисклеймер 1

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

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

Инди-команды не имея опыта в программировании собирают целые игры исключительно на нодах, а большие игры-сервисы удерживают исходники проекта в текстовом варианте? В нескольких проектах, с которыми я работал, были инструменты и системы визуального программирования: от древнего, тогда еще самостоятельного Bolt до монстров FlowCanvas/NodeCanvas и BluePrints в Unreal Engine.

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

Привет, Хабр! Сегодня я хотел бы поделиться опытом, как писать код так, чтобы системы в проекте были с одной стороны гибкими, а с другой — простыми и компактными.

На самом деле, когда нужно реализовать новую фичу в проекте, необходимо соблюдать баланс между простотой и гибкостью...

Каждый год выходит новая версия .NET. Это событие не только предоставляет нам возможность познакомиться с последними улучшениями в самом .NET и нововведениями в языке, но и даёт повод исследовать исходный код .NET. Нужно воспользоваться этим шансом!

За 2023 год разработчиками PVS-Studio было написано немало статей о проверке Open Source C#-проектов. По традиции мы делимся с вами 10-ю самыми интересными ошибками, найденными за этот год. Приятного чтения!

В CLR есть особенность, что при загрузки сборки через Assembly.Load или через Assembly.ReflectionOnlyLoad, загружаются все сборки по мере запроса. В отличии от констант и их типов, они заранее копируются в дочернюю сборку и больше не зависят от родительской сборки. Но в определённых случаях типы констант не копируются в дочернюю сборку и их изменение может сломать работу приложения, несмотря на то, что тип константы не должен этого делать. Эта статья Вам поможет разобраться в каких случаях это может произойти и почему так происходит.

Это перевод первой главы из поста How Async/Await Really Works in C#

Этот пост .Net блога является продолжением исходного поста, глубоко погружающим в историю, приведшую к созданию конструкций async/await и стоящие за этим дизайнерские решения и детали реализации async/await в C# и .NET.

Исходный пост What is .NET, and why should you choose it? предоставляет обзор платформы на высоком-уровне, перечисляя различные компоненты и решения на уровне дизайна, и предваряя последующие посты в глубину обозначенных тем.

Ссылки в развитие темы:

1. Часть 2 Артефакты от EAP шаблона, SynchronizationContext

2. Уроки по асинхронному программированию из первой половины работы

3. Параллельные вычисления — Все дело в контексте-синхронизации (SynchronizationContext)

4. Async/Await из C#. Головоломка для разработчиков компилятора и для нас

Статья поведёт нас через границу, где сходятся MIDI и метрическое время. В этом путешествии мы откроем брошюру по Международной системе единиц СИ, повстречаем файлы с более чем 6000 изменений темпа, столкнёмся с ошибками округления и напишем немного кода. Звучит заманчиво? Тогда добро пожаловать!

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

У Zenject-а есть очевидно лишние (привет, Signals) и запутанные модули и возможности. Зачастую, чтобы сделать все красиво, приходится хорошенько покопаться в устройстве DI-контейнера.

Рассказываю о способах приготовления тех фич и тонкостей Zenject, которые за несколько лет разработки нашел полезными и постоянно применял.

На просторах интернета заметил, что довольно мало статьей про ASP.NET под Linux. К сожалению, новички вроде меня копаются часами в поисках нужной информации, поэтому в этой статье мы вместе развернём минимальное приложение ASP.NET core под Linux в среде Ubuntu и в связке с PostgreSQL и с котиками на сервере nginx, а также упакуем всё в docker контейнеры. В ходе этой статьи мы разберём некоторые консольные команды для ежедневного пользования.

Это перевод вступления из электронной книги - документа.

Авторы утверждают что:

В этой главе вы увидите, как можно удовлетворить некоторые из распространенных требований корпоративных приложений (приложений для бизнеса), таких как низкая стоимость (простота) сопровождения и тестируемость, применяя слабосвязанный дизайн для вашего приложения. Вы увидите очень простую иллюстрацию этого подхода в примерах кода, которые показывают два разных способа реализации зависимости между классами ManagementController и TenantStore. Вы также увидите, как принципы объектно-ориентированного программирования SOLID связаны с теми же проблемами (имеются ввиду проблемы стоимости сопровождения = исправления ошибок + возможности расширения функциональности и тестируемости).

Модели, сделанные в блендере, о которых я рассказывал в предыдущих частях, готовы и могут быть загружены в игровой движок. В этой части пойдёт речь о том, как собрать и заставить двигаться дорогу в Unity 3d.

Среди нововведений C# 12 было достаточно больше количество по-настоящему качественных и крутых фич (например дефолтные параметры лямбд).

Но речь сегодня пойдет о ложке дёгтя в бочке мёда - Primary Constructors.

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

Как говорится, воруй как художник? Думаю, что это не про Primary Constructors, потому что насколько плохо своровать фичу это надо было постараться.

Почему же в Kotlin эта фича имеет смысл, а в C# нет? Давайте разбираться.

Традиционное определение для операции возведения в натуральную степень (или целую положительную) вводится примерно следующим образом:

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

Но более точная формулировка всё же другая:

Возведение числа X в целочисленную степень N — арифметическая операция, определяемая как результат многократного [N по модулю раз] умножения либо деления единицы на число X.

Минимакс - популярный алгоритм для принятия решений в играх с нулевой суммой (один выиграл - другой проиграл). Казалось бы, раз он так популярен, то всё что можно было про него сказать уже сказано? Не совсем. Информация сильно раздроблена, иногда ошибочна, а найти какие-либо примеры в играх довольно сложно. Поэтому в этой статье я постараюсь прояснить процесс разработки ИИ на основе минимакса для игры "Поймай Овечку".

Использование спецификации открыло для меня новый мир в создании приложений.

Репозитории предоставляют удобное решение для доступа к данным.

Однако за многолетний опыт разработки, побывав в нескольких компаниях, сменив кучу проектов я НЕ ВСТРЕЧАЛ паттерн "Спецификация" совместно с паттерном "Репозиторий".

Тестирование производительности различных способов передачи данных между моделями разных уровней слоёного прилолжения.

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

Адаптированный проект для публичного использования, рабочий на Гите, компилируется в простой exe-файл. Можно скачать как exe-файл, если доверяете своему антивирусу.  Надеюсь, кому-то пригодится. Но чтобы начать пользоваться надо научиться писать XАML определения вложенных структур, по которым работает парсер. Ссылка в конце статьи.

Не будет никаких модных слов, только то, что нужно для работы.

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

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

О том, какой путь проходит релиз и какие инструменты обеспечивают его надежность, расскажет engineering manager Mindbox, Бадал.