Это вторая статья из серии про использование 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#."
Есть бесконечное количество способов ошибиться при написании кода. Однако иногда можно заметить явные интересные закономерности, как и где ошибаются программисты. Поговорим о коде, который "притягивает" опечатки.
С целью тестирования и продвижения статического анализатора кода PVS-Studio мы проверяем различные открытые проекты. Найдя ошибки, мы сообщаем о них авторам проектов, коллекционируем их и пишем статьи про наиболее интересные случаи.
Рассматривая все эти ошибки, я постепенно замечаю различные повторяющиеся паттерны опечаток. За редким исключением они не зависят от языка программирования. По крайней мере, они одновременно свойственны коду, написанному на C, C++, C#, Java. В этой статье я опишу 7 паттернов, которые заметил к настоящему моменту:
Заметность закономерностей в ошибках свидетельствует о том, что они крайне распространены. Полезно знать о них, чтобы избегать написания потенциально опасного кода или более эффективно находить их в процессе обзоров кода. Другим словами, вы узнаете, какой код притягивает ошибки, и будете более внимательно его проверять. Конечно, PVS-Studio способен выявить многие подобные ошибки, но не все. Поэтому дополнительное внимание не повредит.
Приветствую, товарищи-программисты!
Материалы по разработке Telegram ботов на C# начинают потихоньку устаревать, новой информации я не нашел, поэтому решил написать свою статью.
В своей статье я написал простенького Telegram бота для обучения и использования его основы в ваших будущих проектах. А как я сделал, смотрите в моей статье!
Прочитав эту статью до конца вы поймете какими навыками вам нужно обладать для того, что бы стать smart-contract разработчиком!
В конце статьи прикреплен Solidity developer roadmap.
В новой публикации мы исследуем сферу магии кода и низкоуровневого программирования. Перед вами увлекательная история, как я смог обрести контроль над рабочим столом, используя лишь небольшие фрагменты C# кода. Вам будет интересно узнать, как я смог покорить мир обоев и сделать их подчиненными волшебства. Не упустите шанс окунуться в мир горячих клавиш и таинственных сообщений Windows API.
В этой истории о магической мощи программирования мы расскажем, как открываются двери к возможностям, о которых вы даже не подозревали. Узнаете ли вы, что стоит за командами, вдохновленными Ctrl+Alt+B и Shift+C? Все это и многое другое ждет вас внутри. Следите за нашим путешествием сквозь замысловатые лабиринты кода и давайте волшебству свободу! ✨
Зачастую, разработка сложных пользовательских интерфейсов приводит к появлению словарей, енамов, состояний интерфейса, чтобы грамотно следить за тем что происходит. Однако, иногда это может противоречить идеологии, что интерфейс должен лишь отображать состояние, не изменяя его.
Для систематизации работы интерфейса предлагается заимствовать опыт из веб разработки.
