DotNet developer blog C# | .Net
802 subscribers
85 photos
36 links
Blog about C# .NET development. Almost all posts are published in english on my linkedin page https://www.linkedin.com/in/yegor-sychev/
Download Telegram
Наконец решился запустить свой YouTube-канал с короткими роликами про C#.

Первый минутный ролик о том, как работает отложенное выполнение (deferred execution) в LINQ с IEnumerable и ключевым словом yield.

https://www.youtube.com/shorts/rfDAsAsx68c

Буду рад обратной связи и идеям, о чем снять следующие короткие разборы а также подписки на канал
👍20🔥1
Пошаговая миграция с легаси MVC на современный .NET стек используя паттерн Strangler Fig

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

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

Практический кейс

Миграция ASP.NET MVC на ASP.NET Core У нас есть старое приложение на .NET Framework 4.8. Переписывать все сразу рискованно поэтому используем Strangler Fig.

Шаг 1. Поднимаем новый ASP.NET Core API Новый API начинает содержать современную бизнес-логику и независимые контроллеры.

Шаг 2. Старый MVC начинает вызывать новую систему. Легаси-контроллер остается на месте, и маршруты работают как раньше, но внутри запрос перенаправляется на ASP.NET Core API.

Таким образом UI не меняется, URL остаются прежними, но функциональность уже живет в Core. В продакшене лучше использовать HttpClientFactory или один статический экземпляр HttpClient.

Преимущества подхода

— Постепенность. Переносим функциональность по одному эндпоинту за раз.
— Минимальный риск. Старая логика остаётся как fallback-вариант.
— Тестирование в реальных условиях. Новый API сразу работает под боевой нагрузкой, но в контролируемом режиме.
— Отсутствие простоя. Пользователи не замечают миграции.

Что происходит после переноса бэкенда?


Когда всё API уже находится в .NET Core старые MVC Views заменяются по одной странице на современный фронтенд (React / Vue / Angular), старая система постепенно усыхает, и в итоге остается только новая архитектура.

Strangler Fig - один из самых безопасных способов модернизировать устаревшие приложения. Он позволяет переносить логику на ASP.NET Core постепенно и безболезненно, сохраняя стабильность и контроль на каждом шаге.

Пост на LinkedIn, Medium
🔥11👍4
Итоги 2025 года

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

Получил благодарственное письмо от Министерства ИИ и цифрового развития Республики Казахстан и лично министра Жаслана Мадиева за вклад в IT-сферу страны.

Перевод письма:
МИНИСТЕРСТВО ИСКУССТВЕННОГО ИНТЕЛЛЕКТА И ЦИФРОВОГО РАЗВИТИЯ РЕСПУБЛИКИ КАЗАХСТАН
БЛАГОДАРСТВЕННОЕ ПИСЬМО

Уважаемый Сычев Егор

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

С уважением, Заместитель Премьер-Министра Республики Казахстан – Министр искусственного интеллекта и цифрового развития

Жаслан Мадиев
🔥32👍5
Личный опыт работы с OpenClaw

Наверно, уже многие наслышаны про OpenClaw. Я ковыряю его уже около месяца и хочу поделиться своим опытом использования.

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

Почему я решил, что он мне нужен?

Уже давно думал, как автоматизировать трекинг своих задач и базу заметок. Пробовал разные подходы, в том числе Notion и Obsidian. Поэтому, когда услышал про OpenClaw, понял, что это как раз то, что мне нужно.

Как это работает
У меня есть основная база заметок в Obsidian. Я храню ее в приватном GitHub-репозитории. Если работы с базой много, то работаю с ней через VS Code + Claude или GitHub Copilot, ну и, конечно, вручную.

На VPS у меня развернут OpenClaw. Он сам может подтягивать актуальную версию базы и делать ее summary в отдельном md-файле. Помимо базы заметок, у меня есть отдельный файл со списком дел - todolist md.

Взаимодействие с ассистентом идет через Telegram-бота, можно писать текстом, можно отправлять голосовые сообщения. Два раза в день по cron в чат прилетает список задач. Вечером - список на завтра, утром - список на сегодня.

Помимо Telegram, я настроил общение через Яндекс Станцию с Алисой. Это была, наверно, самая сложная интеграция, на которую я убил несколько дней. Но оно того стоило, довольно удобно голосом добавить задачу в список или запросить текущий список, даже не беря в руки телефон.

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

Примеры юзкейсов

- Голосом добавить через Telegram задачу в todolist или в базу заметок.
- Голосом через Алису добавить задачу.
- Запросить список задач или summary базы через Telegram или Алису.
- Закинуть в Telegram-чат скрин чего-либо для обогащения базы.
- Настроить cron-напоминания.
- Вытащить письма из почты.

Кому это нужно

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

Какой стек использую

База заметок - Obsidian + GitHub
Распознавание голосовых сообщений - Groq
ИИ-модели - OpenRouter
Интеграции с почтой - Gmail
Чат - Telegram
Голосовой помощник - Яндекс Станция с Алисой + Yandex Cloud Function

Что посмотреть
чтобы поднять себе свой OpenClaw

Первое видео, по которому я начинал у Владилена Минина
https://www.youtube.com/watch?v=z1DHw3djzY8

Но он использует довольно дорогой VPS. Поэтому еще можно посмотреть видео другого автора - Крестникова.

Часть 1:
https://youtu.be/0TQFhuv1PVA?si=GXcIyejF49-Kf22I

Часть 2:
https://www.youtube.com/watch?v=Yw1LKDf0RPE

Там уже используется более бюджетный VPS за 5 долларов.

Создание навыка Алисы - https://youtu.be/QyN9DUaLQ3c?si=pJ7JtSbBLiNP79gG
👍14🔥2✍1
Опубликовано наше исследование производительности Dapper и EF Core

Недавно мы опубликовали статью с результатами сравнительных тестов Dapper и Entity Framework Core в сценариях доступа к данным в .NET.

Вместе с Азатом @dudefromwest хотели понять где разница в производительности становится действительно заметной.

Для этого мы провели серию тестов с использованием .NET, PostgreSQL и BenchmarkDotNet - от простых сценариев чтения до запросов с частыми JOIN, обновлений и параллельных выборок.

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

В простых сценариях чтения разница была заметна, но не критична.

Но в запросах с частыми JOIN и сложных обновлениях разрыв стал гораздо более существенным. В одном из сценариев JOIN Dapper показал улучшение времени выполнения примерно на 51%, а в сложном сценарии обновления - примерно на 48%.

Компилированные запросы EF Core помогли в некоторых сценариях чтения, но существенно не изменили профиль выделения памяти.

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

Еще один интересный момент - в ходе исследования Азат проанализировал исходный код Dapper и открыл issue в репозитории Dapper'a после обнаружения избыточной операции преобразования в nullable в асинхронном пути запроса

Ссылка на научную работу
Исходники проекта и бенчмарки



PS Мне периодически пишут на счет личного менторства, к сожалению, я его не провожу. Но смело могу рекомендовать Азата @dudefromwest как сильного дотнетчика, мы с ним коллеги с 2021 года, плюс он уже имеет опыт менторства
🔥18
Сегодня в 18:00 (время Астана/Алматы) будет онлайн митап со мной
Forwarded from Community Qostanai Hub
🚀 Уже сегодня! Не пропустите!

В 18:00 состоится онлайн-встреча «Как стать бэкенд-разработчиком в финтехе: путь к Senior .NET Engineer» с Yegor Sychev — Senior Software Engineer и Microsoft Learn Contributor.

Поговорим о карьере в FinTech, развитии до уровня Senior и о том, какие навыки действительно нужны бэкенд-разработчику.

🕕 18:00
🌐 Онлайн

Ссылка на трансляцию — https://meet.google.com/sfm-uoxb-tuw
🔥10👍1
Мой конспект по примитивам синхронизации в .NET для собеседования

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

Легкие внутрипроцессные механизмы


К ним можно отнести Interlocked, SpinWait и SpinLock.
Например:

Interlocked.Increment(ref counter);


Interlocked
выполняет простую операцию атомарно, не позволяя нескольким потокам потерять обновления.

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

Примитивы на основе механизмов ОС


Mutex, Semaphore, AutoResetEvent и другие наследники WaitHandle используют объекты ожидания операционной системы.

Если ресурс занят, ОС может приостановить поток. Он не расходует CPU на постоянную проверку ресурса, но системные вызовы, работа планировщика и последующее пробуждение делают такое ожидание более дорогим.

Некоторые из этих примитивов поддерживают межпроцессную синхронизацию. Например, именованный Mutex может координировать несколько приложений на одной машине.

Почему lock называют гибридным


lock основан на Monitor.

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

Поэтому lock старается оставаться легким, но при необходимости использует более затратную стратегию.

Привязка к потоку


Некоторые примитивы запоминают поток-владельца:
- lock / Monitor
- Mutex
- ReaderWriterLockSlim

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

У SemaphoreSlim привязки к потоку нет, поэтому он подходит для асинхронного кода:

await _gate.WaitAsync(cancellationToken);
try
{
await SaveAsync(cancellationToken);
}
finally
{
_gate.Release();
}


Если войти сразу нельзя, WaitAsync() возвращает незавершенный Task. Операция ожидает, не удерживая поток заблокированным на всё время ожидания.

После await продолжение может выполняться в другом потоке. Поэтому компилятор запрещает await внутри lock - Monitor привязан к потоку, и освободить его должен тот же поток, который захватил блокировку.

Что выбирать


- Короткий синхронный критический участок — lock
- Простое атомарное изменение — Interlocked
- Асинхронный критический участок — SemaphoreSlim(1, 1)
- Ограничение параллелизма до N операций — SemaphoreSlim(N, N)
- Синхронизация между процессами — именованный Mutex
- Много чтений и мало записей — ReaderWriterLockSlim, но только после измерений
- Исключительно короткое низкоуровневое ожидание — SpinWait или SpinLock

На собеседовании при сравнении примитивов стоит ответить на три вопроса:

Как происходит ожидание и сколько оно стоит?
Кто владеет примитивом и может его освободить?
Совместим ли он с async/await?

Именно эти различия объясняют, почему lock, SemaphoreSlim, Mutex, Interlocked и SpinWait решают разные задачи.

Развернутая версия конспекта - на dotnetdevsblog.com.
🔥13✍5👍3
Теперь я Microsoft MVP в направлении .Net
🔥43