C# *

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

Делегат, по сути, это ссылка на метод. Техническим языком, это типобезопасный указатель на функцию. То есть делегат хранит адрес метода, позволяя нам вызвать этот метод без необходимости вызывать его напрямую.

Определение: Делегат - это переменная ссылочного типа, которая может хранить ссылку на метод.

Типобезопасность: Делегаты очень конкретны в том, на что они могут ссылаться. При попытке использовать делегат, предназначенный для ссылки на метод, принимающий целое число и возвращающий строку с методом, который принимает строку и возвращает целое число программа даже не скомпилируется.

Синтаксис: Аналогичен объявлению метода в интерфейсе, за исключением того, что требует ключевое слово delegate.

Представьте, что у нас есть спутниковая система, обрабатывающая космические данные от далеких звезд. После обработки данных системе необходимо уведомить базовую станцию на Земле.

Как создатель и руководитель курсов по C# я вижу, что часто у людей, начинающих изучать этот язык, принципы Объектно-Ориентированного Программирования вызывают затруднения в понимании. А так как один из лучших способов что-то понять, это посмотреть применение на примерах, то я решил написать статью с примерами принципов. Рекомендую найти какую-нибудь статью или книгу, где прочитать основную теорию, а в этой статье уже посмотреть примеры применения этой теории, чтобы понять её лучше.

На текущий момент есть различные точки зрения на то, сколько же в ООП всё-таки принципов и в этой статье мы будем считать, что этих принципов четыре: Инкапсуляция, Наследование, Полиморфизм и Абстракция. Примеры будут приведены на языке C#, однако, они очень простые, да и сама суть не зависит от языка, поэтому будет полезна всем начинающим изучать ООП программистам.

Всем привет, Меня зовут Олег и я .NET разработчик в компании Bimeister. Я хотел поделиться своим интересным опытом по связи проекта на ASP.NET Core Web App с использованием IAsyncEnumerable коллекций и современного фронт-енд SPA приложения на Typescript.и Vue.js 3 версии.

Все эти технологии не новы и, на самом деле, фреймворк и технологии для веб части могут быть любые на ваш вкус: Angular, или React, или что-либо еще. Весь интерес представляет собой именно унификация процесса обмена с бэкендом на C# с современной асинхронной коллекцией. Я не буду заострять внимание на структуре обеих половин приложения подробно, скажу лишь, что использовал один из сложившихся в моей практики шаблонов для запуска  ASP.NET Core Web приложения с SPA. Все детали можно будет посмотреть в приложенном репозитории.

Эта статья выросла из бесед с Godot-разработчиками. Они заботятся о том, чтобы поднимаемые проблемы решались, и стремятся улучшать ситуацию. Определённо, в Godot грядут серьёзные изменения, но сама платформа пока находится на ранней стадии развития. Поэтому сложно говорить с уверенностью, что именно изменится и в какой степени. На самом деле, я полагаю, что Godot ждёт самое светлое будущее.  

Апдейт: ведущий разработчик Godot Хуан Линьетски опубликовал ответ на этот пост.

Привет! Меня зовут Даниил, я занимаюсь саунд-дизайном (sound design) и пишу музыку. Это первая моя статья и по совместительству пилотная в планируемом цикле; поэтому, вероятно, она будет содержать дополнительную информацию, которую я планирую перенести в отдельную публикацию (если данная серия получит продолжение).

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

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

Примечание: предполагается что читатель знаком с базовыми принципами работы в FMOD и Unity.

Сейчас я планирую рассмотреть наиболее нетривиальные моменты с упором на процесс имплементации аудио. В противном случае статья может незаметно превратиться N-страничный нечитабельный талмуд. Все учебные проекты, о которых будет рассказано, находятся в свободном доступе и выполнены на Unity engine (Asset Store) и Unreal engine (Unreal Engine Marketplace).

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

Это вторая статья из серии про использование async/await в Unity. В первой мы разобрали восемь причин отказаться от Coroutine в пользу Async. В данной же статье посмотрим на самые распространённые ошибки при использовании async/await.

В Unity есть класс Gradient, который предоставляет удобные средства для управления градиентом в рантайме и редакторе. Но т.к. это класс, а не структура использовать его через Job system и burst нельзя. Это первая проблема. Вторая проблема — это работа с ключами градиента. Получение значений осуществляется через массив, который создаётся в куче. И как следствие напрягает сборщик мусора.

Сейчас я покажу как можно решить эти проблемы. И в качестве бонуса получить увеличение производительности до 8 раз при выполнении метода Evaluate.

Идея небольшого дополнения архитектуры контейнера инъекции зависимостей для решения распространённой проблемы.

В статье разбираются ситуации, когда операции над вещественными числами с плавающей двоичной точкой (типы float и double в C#) дают результаты, отличные от ожидаемых интуитивно. Подробно разобраны причины этих отличий, приведены примеры, когда результат получается разный в .NET и .NET Framework или изменяется при переключении между конфигурациями Debug и Release, а также между x86 и x64. Даны общие сведения о стандарте IEEE 754 и особенностях этого стандарта, приводящих к названным эффектам. Объяснены принципиальные различия между .NET и .NET Framework в части операций с вещественными числами.

Праздник «день программиста» отмечается в 256-й день года, а это 2⁸, т.е. два в степени восемь. Это не просто так — на степенях двойки многое завязано в компьютерах и программировании, они повсюду. Настолько повсюду, что иногда даже слишком.

Благодаря празднику я вспомнил, что давно хотел написать эту статью, и поделиться несколькими техническими байками, где числа, являющиеся степенями двойки, вставляли «палки в колёса» мне или моим коллегам.

Традиционно, для реализации CI/CD сценариев DevOps-инженеры используют различные платформы, такие как Jenkins, TeamCity, Azure DevOps и т.д. Их конфигурирование для сборки, версионирования, создания релизов решений может быть сложным и трудоемким, особенно если решение состоит из множества проектов/единиц развёртывания.

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

• Сложность поддержки: использование такого количества скриптов делает их поддержку более сложной и трудоемкой. Каждый скрипт может иметь свою синтаксическую структуру и требовать специфических знаний для его изменения или исправления ошибок.

• Отсутствие стандартизации: в случае использования скриптов, каждый разработчик может использовать свой собственный подход к настройке процесса. Это приводит к отсутствию стандартов и единого подхода в организации, затрудняя совместную работу и повышает сложность обслуживания.

• Непредсказуемость: нет уверенности, что процесс будет проходить одинаково на всех серверах сборки, поскольку он зависит от настроек окружения и установленных там SDK. Более того, сборка или запуск тестов могут проходить на одной ОС, а развёртывание - на другой, приводя к непредсказуемым ошибкам.

• Зависимость от инструментов: для настройки CI/CD с использованием скриптов обычно требуется определенный набор инструментов, создавая зависимость от них и усложняя переносимость настроек.

• Отсутствие контроля версий: нередко бывает так, что скрипты не хранятся в системе контроля версий, тем самым затрудняя отслеживание изменений и воспроизведение конфигурации для определенной версии приложения.

• Отсутствие вовлеченности разработчиков: поскольку, зачастую, настройка CI/CD выполняется DevOps-инженерами, разработчики не могут вносить изменения в процесс сборки напрямую. Более того, разработчики могут не знать, как настроен весь процесс, что делает его менее прозрачным и увеличивает время реакции на изменения или проблемы.

• Зависимость от внешних поставщиков: в постоянно изменяющихся условиях рынка, коробочные решения для CI/CD могут устаревать, переставать соответствовать требованиям организации или просто уходить с рынка. Всё это может приводить к необходимости перехода на другие решения и влечёт дополнительные затраты на переобучение и перенастройку процесса.

Что можно сделать, чтобы решить эти проблемы?

При начале разработки нового проекта у моей команды всегда появлялся вопрос, какую библиотеку выбрать для межсервисного взаимодействия? А какую использовать для походов в сторонние сервисы? В этой статье я постарался вкратце осветить различные обёртки над HttpClient.

До недавних пор для проведение подобных измерений требовалось использовать промышленные приемники/передатчики ультразвука. Только они могли дать приемлемую точность и дальность. Но они были слишком большие и дорогие. Использовать дешевые китайские модули, такие как HC-SR04/US-025, не выйдет. Точность, стабильность, повторяемость результата оставляет желать лучшего.

Ситуацию изменило появление нового чипа CH-201. Его основная проблема заключается в том, что он китайский. Я еще не видел китайский чип с хорошей документацией и хорошей службой поддержки.

На следующих изображениях продемонстрирован результат работы этого чипа.

В этой статье мы рассмотрим реализацию библиотеки MassTransit в сочетании с RabbitMQ в приложении ASP.NET Core. Для начала, мы затронем некоторые из продвинутых функций RabbitMQ, а также ряд концепций, с которыми можно столкнуться, используя библиотеку MassTransit. Ну и наконец, мы разберёмся, как использовать эту библиотеку в приложении ASP.NET Core Web API.

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

В .NET кэширование в оперативной памяти реализует пакет Microsoft.Extensions.Caching.Memory, входящий в набор .NET Extensions. И поводом для написания этой статьи послужили приключения (с успешным концом), связанные с упомянутым в заголовке интерфейсом ICacheEntry из этого пакета, возникшие при попытке его нестандартного использования.

Но рассказать я хочу не только о той недокументированной засаде, в которую я попал, сделав шаг в сторону от примеров использования из документации. И не только о том, как я из нее выбрался. Дело в том, что при выяснении правильного способа работы с ICacheEntry я наткнулся на довольно необычный приём программирования (он же Design Pattern), который я для себя назвал "Скрытый построитель". И наткнулся я на него в коде библиотек .NET не в первый раз. И я раньше нигде не читал про подобный приём. А потому я решил включить в статью ещё и описание этого приёма. А так как этот приём не специфичен для C#, и его вполне можно использовать и на других языках, то он может быть интересен и тем, кто не работает с C# и .NET.

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

В современном мире программной разработки качество продукта играет ключевую роль. В процессе разработки надежное функционирование веб-приложений становится неотъемлемой частью обеспечения высокого качества программного обеспечения. Автоматизированное тестирование — это эффективный способ обеспечить надежность и стабильность веб-приложений. И здесь на сцену выходят Selenium и язык программирования C#.