C# *

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

Напомню, я решил, что вместо прошивки мне подойдёт и нейрослоп - в конце концов это не серийное устройство, а поделка для себя. И тут, как обычно, в процессе работы пошли фейерверки.

ESP32-S3 имеет два USB выхода - обычный через микросхему CH340, которая конвертирует USB в UART, и второй USB OTG, который подключен к чипу напрямую. То есть чип может управлять тем, какое "устройство" он предоставит хостовой ОС! Более того, он может предоставлять несколько устройств одновременно. Это было как раз то, что надо: одним устройством будет USB HID клавиатура для "сырого" ввода в консоль, например, а вторым - USB RAW устройство, которое будет слушать софт бекенда - запускать приложения по ярлыкам, регулировать громкость, отправлять в устройство настройки. И всё это минуя тормознутый UART. Сказка. Но, как оказалось, для взрослых.

Казалось бы, полный интернет примеров того, как это настраивать. Даже в самом фреймворке esp-idf есть пример композитного устройства, значит, информация уж точно легкодоступная, бери да пользуйся. Я попросил ИИ добавить это в прошивку и... Оно не смогло. То есть вообще. Два дня и токенов примерно на 30 баксов - и я взял дело в свои руки, потому что ИИ выдумывал всё более и более изобретательные причины того, почему прошивка не компилируется, но вот выдумать компилирующуся прошивку не мог никак.

В этой серии туториалов мы реализуем простой Third Person Controller на базе MonoGame.

Серия рассчитана на читателей, уже знакомых с основами MonoGame и 3D-графики.

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

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.

Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

Привет, Хабр! Меня зовут Михаил, в Циане я занимаюсь развитием культуры и developer experience. Архитектура у нас микросервисная, за каждый микросервис отвечает конкретная команда. В любой команде обычно есть микросервисы, которые помогают ей достигать собственных целей, и микросервисы, которые достались по наследству — поскольку архитектура наша не всегда развивалась достаточно последовательно. Бывает, что сервис приходит с каким-нибудь разработчиком из другой команды. Бывает, что сервис когда-то отдали команде, потому что больше некому было отдать.

Наш бэкенд написан на Python и C#. Иногда в одной команде могут быть микросервисы и на Python, и на C#. Я считаю, что это нНе самый удобный расклад, я считаю: лучше все-таки иметь один стек в рамках одной команды. Если, например, в команде с питонистами и единственным шарпистом последний уходит в отпуск, то при поломке сервиса на C# остальной команде придется этого шарписта ждать. Либо срочно вызывать на подмогу другого шарписта.

Можно переписать все микросервисы на один язык. Довольно трудоемкая задача, если заниматься этим вручную. Разработчику нужно погрузиться в микросервис, максимально покрыть тестами бизнес-логику и аккуратно все переписать. Не забывая, что делать один в один нужно не всегда, поскольку архитектурные паттерны Python и C# различаются.

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

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

В DATAREON Platform эту проблему можно решить через программные модули — механизм для хранения и повторного использования собственных функций на C#.

В статье покажу как создавать такие функции и использовать в ваших процессах.

Как я уже писал в своей прошлой статье, дурная голова рукам покоя не даёт. Так что не прошло и месяца после завершения работы над звонком, как руки уже начали чесаться. И занятие им нашлось достаточно быстро...

Я пользуюсь MAD CATZ S.T.R.I.K.E. 7, которая всем чудо как хороша, кроме того, что вышла больше 10 лет назад, её производитель обанкротился в 2014 и её софт на Win 11 уже надо ставить с бубном. Все мы смертны, клавиатуры - тем более, так что я стал задумываться над заменой. Но проблема в том, что я привык к россыпи макроклавиш, которые позволяют одним нажатием, не задействуя мозг, переключать ветки гита, исправлять криво введённые команды или вбивать пароли в окошки по 15 раз за день (о боги хаоса, как я "люблю" параноиков-безопасников). А современные клавы имеют в лучшем случае 4-5 макроклавиш (что вдвое меньше, чем нужно), а некоторые ещё и стоят как приватный остров. И тут в унынии я наткнулся на это...

C# я до сих пор считаю одним из самых удобных языков для backend разработки. В нём много вещей к которым быстро привыкаешь: свойства, LINQ, async/await, generics без type erasure, хороший tooling и понятная модель разработки.

Но банковский enterprise редко выбирает стек только по удобству языка. На практике важны не только синтаксис и экосистема, но и инфраструктура, сопровождение, безопасность, регламенты, legacy, найм, CI/CD, требования к платформам и долгосрочная стратегия организации.

Так я оказался в ситуации где C# мне субъективно нравится больше, но Java объективно стала полезнее в конкретном банковском контуре.

Эта статья не про холивар C# vs Java. Это попытка спокойно разобрать почему backend разработчику в enterprise иногда приходится расширять стек, даже если текущий язык его полностью устраивает.

Введение

Content Pipeline — это официальный способ работы с ассетами в MonoGame. Однако в сообществе уже давно существует немалая группа разработчиков, которые его не любят и предпочитают загружать ассеты в «сыром» виде. Особенно это заметно в сообществе FNA(ещё одной реализации XNA4) — там такой подход используют практически все.

Я тоже давно в этой «партии» и в этой статье объясню, почему…

В dev-среде аутентификация может годами выглядеть безобидно: логин прошёл, cookie выпущена, [Authorize] работает. А потом приложение переезжает в продакшен — и часть пользователей начинает вылетать из системы без понятной ошибки. Иногда всплывает 431 Request Header Fields Too Large, иногда сервер просто перестаёт принимать сессию, которая ещё минуту назад выглядела корректной.

В статье разбираем, почему cookie аутентификации в ASP.NET Core разрастаются до опасных размеров, как это проявляется в реальных системах и какие решения помогают не лечить симптомы, а привести схему аутентификации в нормальное production-ready состояние.

При создании новой игры, одним из первых вопросов является выбор игрового движка.

Основные кандидаты у всех на слуху: Unity, Unreal Engine и Godot.

Но кроме них существует ещё немало движков второго эшелона, про которые мало кто знает.

Собственно, про один из них - под названием MonoGame - я и хочу рассказать.

Привет, меня зовут Алексей и я C# разработчик. Однажды передо мной стояла задача написать утилиту для взаимодействия с различными UI-элементами в Windows и во всех популярных браузерах. Сама утилита не была связана с тестированием, но вполне годилась для автоматизации некоторых действий на машине, так как была простой в управлении и интуитивно понятной. Мне понравилось работать в этом направлении и возникла идея создания инструмента, который не будет перегружен широким функционалом RPA решений, но возьмёт от них всё что нужно для тестирования интерфейсов, чтобы получился действительно полезный инструмент-помощник для QA с низким порогом входа.

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

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

В статье покажу, как реализовать механизм повторной отправки сообщений из архива в обработку с использованием DATAREON Platform.

В одной из прошлых статей я писал о том, как рефакторил CLI-сервис на C#, в котором не был реализован маппинг аргументов в класс конфигураций. Пришлось писать свой.

Есть разные библиотеки для этого, в т.ч. от MS. Но эта слишком сложная, другие не очень понравились. А главное то, что нет реализаций пайплайна, т.е. в сервис передаётся набор команд с параметрами и значениями, которые потом выполняются по порядку.

Привет, Хаброжители! Революционный гид по программированию на C# поможет превратить занудную учебу в захватывающее приключение.

Вы научитесь использовать классы и объектно-ориентированное программирование, создавать 3D-игры в Unity, работать с данными через LINQ-запросы. И все это — решая головоломки, выполняя практические упражнения, создавая реальные приложения.

Мечтаете о карьере разработчика? Вы освоите важнейшие методы и концепции разработки — подобно многим, кто научился программировать по этой книге и стал профи, тимлидом, стримером-кодером и не только. Для обучения не требуется никакого опыта, достаточно желания учиться.

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

В современных реалиях, когда интернет всё чаще напоминает минное поле с

блокировками и замедлениями, надежда на зарубежные (да и на некоторые

локальные) сервисы тает с каждым днем. В какой-то момент я пришел к выводу:

если хочешь, чтобы инструмент работал стабильно и не зависел от настроения

провайдеров или геополитики — напиши его сам.

Так появился, например, Fury Messenger (о котором я уже писал здесь) — мессенджер для

Android, заточенный под нестабильное соединение. Но решив проблему текстового

общения, я столкнулся со следующей «болью»: обмен файлами и документооборот. Именно на большом обьеме, а не кидая файлики или фоточки через мессенджер.

 В этой статье расскажу, как я реализовал систему прямой передачи данных между

компьютерами, почему облака — это иногда лишнее звено, и как мой «велосипед»

в итоге уехал в B2B-сегмент.

Проблема: Танцы с бубном вокруг VPN

 Типичный сценарий обмена файлами сегодня выглядит так:

 1.  Залить в Telegram (ограничение по размеру, скорость иногда «режут»).

2.  Закинуть на Google Drive/Dropbox (нужен VPN, который нужно то включать, то

    выключать, чтобы не отвалились другие сервисы).

3.  Передать через локальную сеть (сложно настроить права доступа, если люди

    сидят в разных сегментах или городах).

Мне хотелось простоты: как в старой доброй Windows Shared Folder, но через

интернет и без необходимости быть системным администратором 80-го уровня.

Чтобы можно было просто «расшарить» папку конкретному человеку и передать файл

на максимально возможной скорости канала.

Перевод статьи, посвящённой устройству конечного автомата асинхронных методов. Разбор основных понятий, декомпилированный код с подробными комментариями, раскрытие секретов магии асинхронности и подробная схема.

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

На первый взгляд задача звучит просто: нашли элемент, кликнули, пошли дальше. Но в реальных приложениях у элемента может не быть (считай не будет) нормального AutomationId, у нескольких окон может быть один и тот же заголовок, дерево интерфейса может прогружаться не сразу, а старое desktop‑приложение вообще не предназначено для взаимодействия с современными API для автоматизации.

В итоге в моей библиотеке появилось два основных Windows‑подхода:

Голос в текст, текст в перевод: строим десктопное приложение для распознавания речи с Azure Speech SDK и NAudio