.NET *

Меня зовут Степан, я C# профессионал уже более 7 лет на рынке и рассказываю об этом в Telegram каналe StepOne. Иногда мне скучно на работе, потому что перекладывать JSON это слишком просто, даже если микросервисы.

Я отучился на системного программиста-компиляторщика и столкнулся с отсутствием спроса рынка на такие навыки. Но выбрал быть счастливым и написал язык программирования hydrascript, чтобы JSON гонялся даже в докере на макбуке. Решение под катом вас точно удивит!

Давно интересовал вопрос использования 16-битного АЦП STM32H7 для обработки I/Q сигналов в реальном времени.

Почти год ушел на эксперименты реализации SDR приемника на базе Tayloe mixer и MCU STM32H723ZGT6, и вот что у меня получилось: принимаемый КВ диапазон 1...30МГц, вывод обработанного аудио через внутренний 12-битный ЦАП или вывод I/Q потока на ПК через UAC1.

Хочу рассказать о конфигурации AI-агента для полного цикла разработки (SDLC), которую я обкатал на паре своих pet-проектов. Суть: цепочка из пяти команд — от черновика фичи до готового к ревью кода — где каждый этап выполняет AI, а я контролирую и корректирую результат между этапами.

За вечер (3-4 часа) в таком режиме AI выкатывает фичу, ручная разработка которой “по вечерам” занимала бы неделю (15-20 часов). Никаких откровений тут нет — всё, что описывается, обсуждалось тысячи раз. Новизна в том, что из общеизвестных кубиков получилось собрать работающий конвейер, которым удобно пользоваться каждый день.

Любой десктопный монолит имеет один фатальный изъян: если UI поток падает - умирает вся бизнес-логика. Я решил это применив бэкенд-подход на десктопе.

Задача была амбициозной: создать единый центр управления рабочим местом. Чтобы одной кнопкой (или по расписанию) переключать ПК и комнату между режимами “кодинг”, “игры”, “стрим”. Это значит: управлять умным домом (Home Assistant), блокировать отвлекающие процессы и сайты, запускать нужный софт, контролировать медиа (Spotify) - и всё это через плагины.

Это - четвертая и последняя (пока) статья цикла про ограничение скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей друг с другом) описание функции ограничения скорости обработки запросов в ASP.NET Core. В этой статье рассмотрено, как на базе универсального компонента ограничения скорости реализована функция ограничения скорости обработки запросов в ASP.NET Core.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.

Это - третья статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте. В этой статье я собираюсь завершить описание универсального компонента ограничения в .NET: описать входящие в его состав базовые (неселективные) ограничители.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.

В этой статье мы заглянем под капот CLR (Common Language Runtime) и разберём как хранятся разные типы данных. Также поговорим о том, что такое стек и куча, и как они взаимодействуют. И в заключении рассмотрим, как происходит выделение памяти и разберем принципы работы сборщика мусора.

Давайте представим, что вам нужно создать класс для хранения данных пользователя. Сколько строк кода вы напишете? Конструктор, свойства, метод ToString(), сравнение объектов... А если добавится новое поле? Придется обновлять конструктор, метод Equals, GetHashCode — утомительная работа, которая не добавляет бизнес-ценности вашему приложению.

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

Это - вторая статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.

Здравствуйте. Меня зовут Валерий и я - кодоголиклюблю писать программы. А ещё я люблю не только писать свои программы, но и читать чужие.

Недавно мне довелось погрузиться в чтение кода функции ограничения скорости обработки входящих запросов к веб-приложению на ASP.NET Core. И в этом цикле статей я хочу поделиться найденным и понятым мной. Тем более, ещё в самом начале своих штудий я обнаружил, что эта тема на Хабре просто не рассматривалась никак - даже на уровне пересказа документации с сайта Microsoft (весьма скудной, кстати). А потому вот прямо сейчас я хочу заполнить этот пробел.

В этой статье мы не просто посмотрим синтаксис — мы поймём зачем это нужно и как работает под капотом. Мы пройдём путь от указателей на функции в C/C++ до современных лямбда-выражений в C#, разберёмся с делегатами и научимся использовать всю мощь функциональных возможностей языка.

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

Через несколько недель

Я писал на C# программу для распаковки gzip-файлов и неожиданно поймал странное исключение, из которого следовало, что архив поврежден.

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

Асинхронное программирование в c# стало стандартом де-факто с выходом .NET FrameWork 4.5 и появление ключевых слов: async и await. В современном мире трудно представить приложение: API, десктопное приложение без асинхронных вызовов. Однако, мне стало интересно самому разобраться, что на самом деле происходит по капотом: как компилятор преобразует асинхронный код, что такое state machine и почему использование .Result/.wait() может привести к deadlock.

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

И так как их много, а меня — мало, делать что-то предстояло мне. Teams и прочие платформы, конечно, имеют опции на такой случай, но не просить же включать запись каждый раз.

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

UseCase - как организовать своё приложение с точки зрения бизнес-процессов, чтобы не погрязнуть в хаосе сервисов, контроллеров и разрозненной логики.

Domain-Driven Design (DDD) звучит как серебряная пуля. Когда мы начинаем проект на ASP.NET, идея четкого разделения на слои, изоляция бизнес-логики в домене и использование паттернов вроде Repository и Unit of Work кажется идеальной архитектурой.

Но есть один нюанс: магия DDD начинает испаряться ровно в тот момент, когда количество агрегатов (реестров) в проекте переваливает за 30. То, что было элегантным решением для CRM с 10 сущностями, превращается в бюрократический ад для ERP-системы или крупного маркетплейса.

В этой статье я разберу, почему классический DDD в ASP.NET (особенно в связке с Entity Framework Core) становится узким местом на масштабных проектах.

Эта статья про нюансы распознавания кириллицы в коде, и про волшебные файлы, которые не понимают, в какой они кодировке, и ломают работу в коде.

В этой статье разберём, как файл «притворялся» что он Macintoch, хотя был Windows-1251, и какую проверку пришлось из-за этого дописать поверх стандартного Encoding.GetEncoding(cdet.Charset);

В распределённых системах повторная доставка сообщений — не редкая аномалия, а штатный сценарий. В этой статье разберемся, как устроен паттерн «Идемпотентный потребитель» в .NET, где проходят реальные границы его надёжности и почему одних гарантий брокера недостаточно, когда обработчик затрагивает базу данных, кэш и внешние сервисы. Особенно полезно будет тем, кто проектирует событийные системы и хочет заранее убрать класс ошибок, которые обычно всплывают только под нагрузкой или при сбоях.

На собеседованиях мы слышим или говорим сами, что поиск в массиве медленнее, чем в хеш-таблице. Кто-то даже вспоминает, что поиск в массиве имеет линейную сложность или O(n), а в хеш-таблице — константную O(1). Но работает ли это на практике? Что, если есть ситуации, когда поиск в массиве оказывается быстрее? Давайте не будем торопиться с выводами.

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

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