C# *

Необходимо реализовать возможность приёма транзакций от разных клиентов для процессинга и дальнейшей отправки в разные банки. Клиенты могут присылать как равномерно (например, по 1шт в секунду), так и большими пачками (1000шт каждый час или 10000 раз в день), банки обрабатывают транзакции последовательно.

Для простоты интеграции необходимо использовать REST API для приёма транзакций

Необходимо исключить ситуации, когда:

Тысячи клиентов по несколько транзакции ожидают двух, у которых по 10000 транзакций

Несколько клиентов по 10000 ждут тысячи клиентов по несколько транзакций.

Уже середина осени, а это значит, что новая версия C# на пороге. Самое время узнать, какие изменения настигнут язык совсем скоро. Хоть количество нововведений в этот раз уступает предыдущим релизам, интересных среди них немало.

Привет, Хабр! Меня зовут Игорь, и я Unity Developer. В этой статье я хотел бы поделиться кейсом, как Test Driven Development помогает мне разрабатывать мою RTS игру.

Недавно анализатор PVS-Studio начал выдавать предупреждения о возможностях оптимизации кода в проектах под Unity Engine. Какие они, эти предупреждения? Как анализатор понимает, какой код стоит оптимизировать? Почему это сделано именно для Unity? Ответы в заметке.

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

[Читать на английском]

Hangfire — распределенный и расширяемый планировщик задач для приложений на.NET.

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

Меня зовут Игорь, и я Unity Developer. В этой статье я хотел бы поделиться кастомной архитектурой, которую сделал в процессе разработки своей RTS игры.

Скажу сразу: что основные концепции и принципы уже используются в различных DI фреймворках, таких как Zenject & VContainer. Поэтому чего-то феноменального в этой статье вы не увидите. Но, поскольку я люблю делать свои велосипеды, то в свою архитектуру я привнес парочку интересных вещей, которых нет в других DI фреймворках на Unity. Ну шо, поехали :)

Разработкой Entity Framework Core занимаются профессионалы, не допускающие ошибок благодаря опыту, ревью и мощной системе тестирования. Впрочем, даже в таком проекте не без приколов. Перед вами статья о странностях, укрывшихся от взгляда разработчиков высшего класса.

Так сложилось, что я на данный момент работаю автоматизатором тестирования, до недавнего момента моим основным стеком в работе был C# + Selenium 3, однако не так давно было принято решение о переходе на Playwright и в данной статье я решил рассказать о своем опыте перехода с Selenium на Playwright и о том с каким трудностями и подводными камнями я столкнулся во время данного перехода.

Плагины в фотоне предназначены для того, чтобы запускать какую-то свою логику на своём Photon облаке. Так же даже если используется Photon SDK плагин является более быстрым способом, получить что-то работающее без погружения в дебри SDK.

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

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

Конечно, мне придется продемонстрировать применение на практике принципов ООП: инкапсуляция, наследование, полиморфизм и то, как они работают.

Конечно, разберем как все это влияет на производительность. Я надеюсь, что получится сформулировать некое подобие ответа на критику постулатов «чистого» кода от достаточно успешного (видимо) иностранного программиста в переводе на Хабре: «Чистый» код, ужасная производительность.

Правила «чистого» кода, изложенные в той статье помогут нам подойти к реализации принципов ООП в нашей задаче.

Привет, Хабр! Меня зовут Игорь, и я Unity Developer. В этой статье хотел бы рассказать, как можно делать модульные механики для игровых объектов, за счет разделения данных и логики без ECS.

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

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

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

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

Синтаксис: Аналогичен объявлению метода в интерфейсе, за исключением того, что требует ключевое слово 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 Хуан Линьетски опубликовал ответ на этот пост.

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

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

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

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