Чтобы до конца разобраться с содержанием Поста: How Async/Await Really Works in C#, который мы начали анализировать в предыдущей статье, неплохо бы познакомиться с изначальным определением концепции SynchronizationContext, на которую ссылается автор этого поста, без которой, по мнению того же автора, нельзя понять реализацию Async/Await.
Это перевод Поста: Parallel Computing - It's All About the SynchronizationContext
До того, как Java 7 вышел, я хотел написать в своем блоге статью о различных предложениях для Java 7, касающихся замыканий. Однако, когда я начал писать эту статью, я обнаружил, что начать ее без какого-либо введения в замыкания очень трудно. Со временем введение стало настолько длинным, что я опасался утратить интерес большинство читателей еще до того, как я доберусь до темы Java 7. Я решил, что вместо этого стоит написать отдельную статью о замыканиях в целом. В итоге получилось, что статья о Java 7 в моем блоге так и не появилась.
Большинство статей о замыканиях написаны с точки зрения функциональных языков, поскольку именно они, как правило, могут похвастаться лучшей поддержкой замыканий. Однако именно поэтому я счел полезным написать статью о том, как они проявляются в более традиционных объектно-ориентированных языках. Скорее всего, если вы пишете на функциональном языке, вы уже знаете о них все, что вам нужно. В этой статье речь пойдет о C# (версии 1, 2 и 3) и Java (до версии 7).
В последнее время среди игровых разработчиков возрос интерес к паттерну "Шина Событий". Этот паттерн часто ругают за его тенденцию к "размыванию логики" и "скрытию зависимостей". Однако, несмотря на критику, полный отказ от этого паттерна также глуп как и написание кода в блокноте вместо специализированной 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, загружаются все сборки по мере запроса. В отличии от констант и их типов, они заранее копируются в дочернюю сборку и больше не зависят от родительской сборки. Но в определённых случаях типы констант не копируются в дочернюю сборку и их изменение может сломать работу приложения, несмотря на то, что тип константы не должен этого делать. Эта статья Вам поможет разобраться в каких случаях это может произойти и почему так происходит.
Привет, Хабр! 👋
Меня зовут Игорь, и я Unity Developer. Последние несколько месяцев я реализовывал зомби шутер на атомарном подходе. Несмотря на то, что подход оказался очень удобным и гибким, я столкнулся я рядом архитектурных проблем в процессе разработки. Поэтому в этой статье я хотел бы раскрыть текущую концепцию атомарного подхода: объяснить что это такое, какие есть преимущества и недостатки, и самое главное, показать как правильно использовать атомарный подход у себя в проекте.
Это перевод первой главы из поста 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.
Минимакс - популярный алгоритм для принятия решений в играх с нулевой суммой (один выиграл - другой проиграл). Казалось бы, раз он так популярен, то всё что можно было про него сказать уже сказано? Не совсем. Информация сильно раздроблена, иногда ошибочна, а найти какие-либо примеры в играх довольно сложно. Поэтому в этой статье я постараюсь прояснить процесс разработки ИИ на основе минимакса для игры "Поймай Овечку".
Использование спецификации открыло для меня новый мир в создании приложений.
Репозитории предоставляют удобное решение для доступа к данным.
Однако за многолетний опыт разработки, побывав в нескольких компаниях, сменив кучу проектов я НЕ ВСТРЕЧАЛ паттерн "Спецификация" совместно с паттерном "Репозиторий".
