Фича-флаги в .NET с IFeatureManager
Где пригодится
— Временное включение или быстрое отключение фичи, например при релизе новой версии или хотфиксе
— Отключение проблемного функционала при сбоях
— A/B-тесты
— Временные сценарии, такие как акции
Как это устроено
Регистрируем Feature Management в DI, проверяем состояние флага через
В итоге поведение приложения можно менять конфигурацией, без нового деплоя.
Такой подход экономит время, снижает риск ошибок при релизах и дает команде больше контроля над функциональностью прямо в продакшене.
IFeatureManager из пакета Microsoft.FeatureManagement управляет фича-флагами в .NET. Он позволяет выбирать нужную ветку логики во время работы приложения.Где пригодится
— Временное включение или быстрое отключение фичи, например при релизе новой версии или хотфиксе
— Отключение проблемного функционала при сбоях
— A/B-тесты
— Временные сценарии, такие как акции
Как это устроено
Регистрируем Feature Management в DI, проверяем состояние флага через
IFeatureManager и задаем значения в appsettings.json. При необходимости добавляем фильтры например, TimeWindow активирует флаг только в заданном интервале времени.В итоге поведение приложения можно менять конфигурацией, без нового деплоя.
Такой подход экономит время, снижает риск ошибок при релизах и дает команде больше контроля над функциональностью прямо в продакшене.
👍17🔥3
Как из Visual Studio 2022 работать с файлами в корне решения
В Visual Studio 2022 неудобно работать с файлами и папками в корневой директории, где лежит
Это особенно заметно, когда нужно быстро править/добавить конфиги, документы или служебные каталоги (например, .github с copilot-instructions md - лишь один из частых кейсов).
Мы, конечно, можем вместо решения открыть сразу корневую папку. Однако чаще удобнее работать именно с открытым
В VS Code это решено наличием полноценного File Explorer рядом с Solution Explorer.
В VS2022 аналог можно получить через расширение
Что дает File Explorer в VS2022
— Полный доступ ко всем файлам и папкам в корне репозитория, а не только к проектам из решения.
— Меньше переключений между IDE и проводником Единое рабочее окно Solution Explorer + файловый эксплорер.
Как настроить
—
— Установите и перезапустите Visual Studio.
— В Solution Explorer появится папка которая отображает содержимое корневой папки репозитория/решения
Если вы часто работаете с файлами в корне репозитория (конфиги, CI/CD, документацию, тот же .github), это расширение - must-have.
Пост на LinkedIn, Medium
В Visual Studio 2022 неудобно работать с файлами и папками в корневой директории, где лежит
.sln. Solution Explorer (Обозреватель решения) показывает состав решения, а не реальную структуру репозитория - многие папки/файлы остаются вне обозревателя. Это особенно заметно, когда нужно быстро править/добавить конфиги, документы или служебные каталоги (например, .github с copilot-instructions md - лишь один из частых кейсов).
Мы, конечно, можем вместо решения открыть сразу корневую папку. Однако чаще удобнее работать именно с открытым
Solution Explorer.В VS Code это решено наличием полноценного File Explorer рядом с Solution Explorer.
В VS2022 аналог можно получить через расширение
File Explorer от Mads Kristensen. Что дает File Explorer в VS2022
— Полный доступ ко всем файлам и папкам в корне репозитория, а не только к проектам из решения.
— Меньше переключений между IDE и проводником Единое рабочее окно Solution Explorer + файловый эксплорер.
Как настроить
—
Extensions - Manage Extensions - найдите File Explorer (Mads Kristensen). — Установите и перезапустите Visual Studio.
— В Solution Explorer появится папка которая отображает содержимое корневой папки репозитория/решения
Если вы часто работаете с файлами в корне репозитория (конфиги, CI/CD, документацию, тот же .github), это расширение - must-have.
Пост на LinkedIn, Medium
👍5✍2
Только что вышла превью Visual Studio 2026 Insiders. Уже тестирую. https://visualstudio.microsoft.com/insiders/
🔥12👍1
Валидация appsettings.json в .NET. Предотвращаем ошибки до их появления
При построении надежных .NET-приложений одной из лучших практик является проверка конфигурации на старте.
Это позволяет избежать сценариев, когда критически важные параметры, например, feature-флаги (ранее публиковал пост о IFeatureManager), отсутствуют в
Такая ситуация опасна тем, что приложение может запуститься без ошибок, но будет работать некорректно, используя значения по умолчанию (например, false для bool типа), что приводит к трудноуловимым багам.
Вместо того чтобы столкнуться с проблемами в рантайме, лучше придерживаться подхода "fail-fast" падать сразу при запуске, если конфигурация невалидна.
Реализовать это довольно просто:
1. Создайте класс конфигурации. Определите класс, который будет представлять вашу секцию в
Однако этого будет недостаточно, так как свойство `NewDashboard` будет иметь значение по умолчанию - false.
2. Добавьте атрибуты валидации. Используйте стандартные атрибуты
3. Включите проверку при запуске. При регистрации конфигурации в Program.cs добавьте вызовы методов
Теперь, если обязательное поле будет отсутствовать в appsettings.json, приложение не запустится и выбросит исключение
Это немедленно укажет на проблему с конфигурацией, защищая систему от непредсказуемого поведения в продакшене.
Этот простой механизм шаг к созданию более стабильных и предсказуемых приложений.
Пост на LinkedIn, Medium
При построении надежных .NET-приложений одной из лучших практик является проверка конфигурации на старте.
Это позволяет избежать сценариев, когда критически важные параметры, например, feature-флаги (ранее публиковал пост о IFeatureManager), отсутствуют в
appsettings.json, что может случиться из-за неудачного разрешения конфликтов при слиянии веток или случайного удаления.{
"FeatureManagement": {
//"NewDashboard": true // Случайно закомментированный или удаленный параметр
}
}Такая ситуация опасна тем, что приложение может запуститься без ошибок, но будет работать некорректно, используя значения по умолчанию (например, false для bool типа), что приводит к трудноуловимым багам.
Вместо того чтобы столкнуться с проблемами в рантайме, лучше придерживаться подхода "fail-fast" падать сразу при запуске, если конфигурация невалидна.
Реализовать это довольно просто:
1. Создайте класс конфигурации. Определите класс, который будет представлять вашу секцию в
appsettings.json, например, FeaturesConfig.public class FeaturesConfig
{
public bool NewDashboard { get; set; }
}
Однако этого будет недостаточно, так как свойство `NewDashboard` будет иметь значение по умолчанию - false.
2. Добавьте атрибуты валидации. Используйте стандартные атрибуты
DataAnnotations, такие как [Required] или [NotNull], для обязательных полей.public class FeaturesConfig
{
[Required]
[NotNull]
public bool? NewDashboard { get; set; }
}
3. Включите проверку при запуске. При регистрации конфигурации в Program.cs добавьте вызовы методов
.ValidateDataAnnotations() и .ValidateOnStart(). который появился, начиная с .NET 6.builder.Services.AddOptions<FeaturesConfig>()
.Bind(builder.Configuration.GetSection(nameof(FeaturesConfig)))
.ValidateDataAnnotations()
.ValidateOnStart();
Теперь, если обязательное поле будет отсутствовать в appsettings.json, приложение не запустится и выбросит исключение
OptionsValidationException. Это немедленно укажет на проблему с конфигурацией, защищая систему от непредсказуемого поведения в продакшене.
Этот простой механизм шаг к созданию более стабильных и предсказуемых приложений.
Пост на LinkedIn, Medium
👍15✍4🔥4
В журнале Universum вышла моя статья -
«Применение систем искусственного интеллекта при проектировании архитектуры приложений: от требований к реализации».
В ней я разбираю интересный кейс использования GitHub Copilot при проектировании архитектуры.
С помощью заранее подготовленных промптов на основе архитектурных требований формируются записи ADR, которые можно корректировать, а затем автоматически генерируется solution с нужными проектами и библиотеками.
Полный текст: https://7universum.com/ru/tech/archive/item/20834
«Применение систем искусственного интеллекта при проектировании архитектуры приложений: от требований к реализации».
В ней я разбираю интересный кейс использования GitHub Copilot при проектировании архитектуры.
С помощью заранее подготовленных промптов на основе архитектурных требований формируются записи ADR, которые можно корректировать, а затем автоматически генерируется solution с нужными проектами и библиотеками.
Полный текст: https://7universum.com/ru/tech/archive/item/20834
👍17🔥12
Неочевидные факты из истории C#, которые стоит знать
C# - это гораздо больше, чем «еще один язык программирования».
За ним стоят годы умных экспериментов в Microsoft, которые изменили не только .NET, но и всю индустрию ПО.
Вот несколько ключевых моментов, показывающих, как C# стал настоящим инноватором:
1. 2002 - рождение C# и .NET
Главный архитектор: Андерс Хейлсберг (также создатель Turbo Pascal и Delphi).
C# 1.0 вышел вместе с .NET Framework 1.0.
Цель: создать современный, безопасный и простой язык - проще, чем C++, но с собственным взглядом Microsoft.
2. Начало 2000-х - исследовательский проект Cω (Comega)
Cω был не продуктом, а исследовательским проектом Microsoft Research.
Он объединял идеи Polyphonic C# и Xen, экспериментируя с работой с данными и конкурентностью.
Результат: Cω не стал реальным языком, но вдохновил на создание LINQ.
3. 2007 - LINQ и идеи функционального программирования
С выходом C# 3.0 Эрик Мейер привнёс идеи из функциональных языков вроде Haskell и ML.
Новые фичи: LINQ (from/where/select), лямбды, extension methods, var, анонимные типы, expression trees (используются в Entity Framework).
Эти идеи сделали C# выразительнее и позволили писать чище и мощнее.
4. 2012 - влияние F# и появление async/await
В C# 5.0 был перенесен и адаптирован async/await из F#, где уже были “async workflows”.
Это помогло уйти от старых, громоздких моделей асинхронности.
5. 2015–2021 - как C# повлиял на другие языки
Асинхронность (async/await):
Python 3.5 (2015)
JavaScript ES2017 (2017)
Kotlin 1.3 (2018)
Rust 1.39 (2019)
Swift 5.5 (2021)
Функциональный стиль (идеи LINQ):
Java Streams API (Java 8, 2014)
Вывод
C# не просто следовал трендам - он их задавал.
Он изменил то, как разработчики думают об асинхронности, данных и дизайне языков.
P.S. Интересный факт после публикации
После публикации этого поста в LinkedIn к нему оставил комментарии сам Don Syme - создатель и главный архитектор языка F#. Он подчеркнул важные моменты:
Он также отметил, что важный вклад в C# в 2000-х внесли следующие люди:
Gavin Bierman - COmega
Cédric Fournet - COmega
Nick Benton - COmega
Erik Meijer - LINQ и многое другое
Todd Proebsting - iterators
Andrew Kennedy - generics
Claudio Russo - generics
Пост на LinkedIn
C# - это гораздо больше, чем «еще один язык программирования».
За ним стоят годы умных экспериментов в Microsoft, которые изменили не только .NET, но и всю индустрию ПО.
Вот несколько ключевых моментов, показывающих, как C# стал настоящим инноватором:
1. 2002 - рождение C# и .NET
Главный архитектор: Андерс Хейлсберг (также создатель Turbo Pascal и Delphi).
C# 1.0 вышел вместе с .NET Framework 1.0.
Цель: создать современный, безопасный и простой язык - проще, чем C++, но с собственным взглядом Microsoft.
2. Начало 2000-х - исследовательский проект Cω (Comega)
Cω был не продуктом, а исследовательским проектом Microsoft Research.
Он объединял идеи Polyphonic C# и Xen, экспериментируя с работой с данными и конкурентностью.
Результат: Cω не стал реальным языком, но вдохновил на создание LINQ.
3. 2007 - LINQ и идеи функционального программирования
С выходом C# 3.0 Эрик Мейер привнёс идеи из функциональных языков вроде Haskell и ML.
Новые фичи: LINQ (from/where/select), лямбды, extension methods, var, анонимные типы, expression trees (используются в Entity Framework).
Эти идеи сделали C# выразительнее и позволили писать чище и мощнее.
4. 2012 - влияние F# и появление async/await
В C# 5.0 был перенесен и адаптирован async/await из F#, где уже были “async workflows”.
Это помогло уйти от старых, громоздких моделей асинхронности.
5. 2015–2021 - как C# повлиял на другие языки
Асинхронность (async/await):
Python 3.5 (2015)
JavaScript ES2017 (2017)
Kotlin 1.3 (2018)
Rust 1.39 (2019)
Swift 5.5 (2021)
Функциональный стиль (идеи LINQ):
Java Streams API (Java 8, 2014)
Вывод
C# не просто следовал трендам - он их задавал.
Он изменил то, как разработчики думают об асинхронности, данных и дизайне языков.
P.S. Интересный факт после публикации
После публикации этого поста в LinkedIn к нему оставил комментарии сам Don Syme - создатель и главный архитектор языка F#. Он подчеркнул важные моменты:
“Language integrated async programming was shipped first in F# in 2006 and was copied and adapted into C# in the following years.”
“The history of Generics, LINQ and async programming, iterators and more is covered tangentially in ‘The Early History of F#’
https://dl.acm.org/doi/abs/10.1145/3386325
There’s no corresponding peer reviewed paper on the history of C# unfortunately.”
Он также отметил, что важный вклад в C# в 2000-х внесли следующие люди:
Gavin Bierman - COmega
Cédric Fournet - COmega
Nick Benton - COmega
Erik Meijer - LINQ и многое другое
Todd Proebsting - iterators
Andrew Kennedy - generics
Claudio Russo - generics
Пост на LinkedIn
👍15🔥11
Наконец решился запустить свой YouTube-канал с короткими роликами про C#.
Первый минутный ролик о том, как работает отложенное выполнение (deferred execution) в LINQ с IEnumerable и ключевым словом yield.
https://www.youtube.com/shorts/rfDAsAsx68c
Буду рад обратной связи и идеям, о чем снять следующие короткие разборы а также подписки на канал
Первый минутный ролик о том, как работает отложенное выполнение (deferred execution) в LINQ с IEnumerable и ключевым словом yield.
https://www.youtube.com/shorts/rfDAsAsx68c
Буду рад обратной связи и идеям, о чем снять следующие короткие разборы а также подписки на канал
YouTube
Deferred Execution in C# LINQ Explained in 1 Minute
Discover how deferred execution work in C# LINQ.Watch how a LINQ q...
👍20🔥1
Пошаговая миграция с легаси MVC на современный .NET стек используя паттерн Strangler Fig
Паттерн Strangler Fig (названный в честь фикуса-душителя, который постепенно оплетает и замещает дерево-хозяина) это стратегия постепенной модернизации легаси-систем.
Вместо рискованного полного переписывания всей системы сразу, мы заменяем старую функциональность новой постепенно, пока система продолжает работать.
Практический кейс
Миграция
Шаг 1. Поднимаем новый
Шаг 2. Старый MVC начинает вызывать новую систему. Легаси-контроллер остается на месте, и маршруты работают как раньше, но внутри запрос перенаправляется на
Таким образом UI не меняется, URL остаются прежними, но функциональность уже живет в Core. В продакшене лучше использовать
Преимущества подхода
— Постепенность. Переносим функциональность по одному эндпоинту за раз.
— Минимальный риск. Старая логика остаётся как fallback-вариант.
— Тестирование в реальных условиях. Новый API сразу работает под боевой нагрузкой, но в контролируемом режиме.
— Отсутствие простоя. Пользователи не замечают миграции.
Что происходит после переноса бэкенда?
Когда всё API уже находится в .NET Core старые MVC Views заменяются по одной странице на современный фронтенд (React / Vue / Angular), старая система постепенно усыхает, и в итоге остается только новая архитектура.
Strangler Fig - один из самых безопасных способов модернизировать устаревшие приложения. Он позволяет переносить логику на
Пост на LinkedIn, Medium
Паттерн 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-сферу страны.
Перевод письма:
МИНИСТЕРСТВО ИСКУССТВЕННОГО ИНТЕЛЛЕКТА И ЦИФРОВОГО РАЗВИТИЯ РЕСПУБЛИКИ КАЗАХСТАН
БЛАГОДАРСТВЕННОЕ ПИСЬМО
Уважаемый Сычев Егор
Выражаем Вам нашу искреннюю благодарность за Ваш значительный вклад в развитие 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
Наверно, уже многие наслышаны про 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 года, плюс он уже имеет опыт менторства
Недавно мы опубликовали статью с результатами сравнительных тестов 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
В 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