Media is too big
VIEW IN TELEGRAM
Компания выпустила расширение, которое напрямую связывает редактор кода со средами выполнения Google Colab. Иными словами, теперь можно работать с локальными .ipynb файлами, но выполнять код на Google Colab. Поддерживается подключение как к бесплатным средам выполнения, так и к премиум-тарифам Colab Pro.
Для начала работы достаточно установить расширение Google Colab из VS Code Marketplace. При выборе ядра для ноутбука появится опция «Colab», после чего нужно будет авторизоваться в аккаунте Google. Расширение также опубликовано в реестре Open VSX для совместимых редакторов.
developers.googleblog.com
Please open Telegram to view this post
VIEW IN TELEGRAM
Реактивное программирование в C# Advanced: сложные операторы, обработка ошибок и холодные/горячие Observable
Асинхронность в C# может быть простой, если знать, как с ней работать правильно. На открытом вебинаре курса OTUS C# Developer. Advanced Елена Сычева покажет, как реактивное программирование помогает избавиться от Callback Hell и писать код, который сам реагирует на данные и события.
📌 26 ноября, 20:00
Реактивное программирование в C# Advanced
— продвинутые операторы Rx.NET: Switch, GroupBy, Buffer, Throttle
— устойчивые к сбоям системы: Catch, Retry, Finally
— холодные и горячие Observable: Publish, Replay, RefCount
— управление подписками и жизненным циклом реактивных компонентов
Вебинар будет полезен разработчикам на C#, работающим с асинхронным кодом, потоками данных и событиями. Участники узнают, как проектировать реактивные системы, способные восстанавливаться после ошибок, и писать декларативный, читаемый и эффективный код.
👉 Зарегистрируйтесь: https://otus.pw/16bE/?erid=2W5zFJg2ejJ
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Асинхронность в C# может быть простой, если знать, как с ней работать правильно. На открытом вебинаре курса OTUS C# Developer. Advanced Елена Сычева покажет, как реактивное программирование помогает избавиться от Callback Hell и писать код, который сам реагирует на данные и события.
📌 26 ноября, 20:00
Реактивное программирование в C# Advanced
— продвинутые операторы Rx.NET: Switch, GroupBy, Buffer, Throttle
— устойчивые к сбоям системы: Catch, Retry, Finally
— холодные и горячие Observable: Publish, Replay, RefCount
— управление подписками и жизненным циклом реактивных компонентов
Вебинар будет полезен разработчикам на C#, работающим с асинхронным кодом, потоками данных и событиями. Участники узнают, как проектировать реактивные системы, способные восстанавливаться после ошибок, и писать декларативный, читаемый и эффективный код.
👉 Зарегистрируйтесь: https://otus.pw/16bE/?erid=2W5zFJg2ejJ
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
10 практических шагах, которые делают запросы EF Core быстрее в 10 раз — и о том, что чаще всего проблема не в EF, а в том, как разработчики его используют.
1️⃣ Добавлять индексы
EF не создаёт их сам. Он рекомендует вручную индексировать колонки из WHERE, JOIN и ORDER BY.
2️⃣ Оптимизировать проекции
Не нужно забирать целую сущность, если нужны 2–3 поля — лучше использовать .Select().
3️⃣ Использовать AsNoTracking для чтения
Отслеживание сущностей расходует память и CPU, поэтому для read-only операций он предлагает .AsNoTracking() или глобальное правило NoTracking.
4️⃣ Аккуратно использовать Include
Слишком много Include приводит либо к N+1, либо к огромным JOIN. Он советует включать только нужные связи.
5️⃣ Избегать больших IN / Contains
Тысячи значений в Contains() превращаются в тяжёлые IN. Лучше бить на батчи или использовать временные таблицы.
6️⃣ Делать пагинацию
Он подчёркивает, что нельзя грузить тысячные выборки целиком: нужны .Skip().Take() или курсорная пагинация.
7️⃣ Использовать скомпилированные запросы
Часто вызываемые запросы можно ускорить через EF.CompileQuery().
8️⃣ Включать SplitQuery
Это помогает избежать «картезианского взрыва», когда много Include создают огромное количество дублирующихся строк.
9️⃣ Писать RAW SQL, если логика сложная
Иногда проще и быстрее использовать FromSqlRaw(), чтобы контролировать план запроса напрямую.
🔟 Использовать кэширование
Часто запрашиваемые данные должны идти из кэша — MemoryCache, Redis или новый HybridCache в .NET 9+.
Бонус:
Перед оптимизацией он советует обязательно измерять узкие места: BenchmarkDotNet, SQL Profiler, планы выполнения.
Ссылка на оригинал
1️⃣ Добавлять индексы
EF не создаёт их сам. Он рекомендует вручную индексировать колонки из WHERE, JOIN и ORDER BY.
2️⃣ Оптимизировать проекции
Не нужно забирать целую сущность, если нужны 2–3 поля — лучше использовать .Select().
3️⃣ Использовать AsNoTracking для чтения
Отслеживание сущностей расходует память и CPU, поэтому для read-only операций он предлагает .AsNoTracking() или глобальное правило NoTracking.
4️⃣ Аккуратно использовать Include
Слишком много Include приводит либо к N+1, либо к огромным JOIN. Он советует включать только нужные связи.
5️⃣ Избегать больших IN / Contains
Тысячи значений в Contains() превращаются в тяжёлые IN. Лучше бить на батчи или использовать временные таблицы.
6️⃣ Делать пагинацию
Он подчёркивает, что нельзя грузить тысячные выборки целиком: нужны .Skip().Take() или курсорная пагинация.
7️⃣ Использовать скомпилированные запросы
Часто вызываемые запросы можно ускорить через EF.CompileQuery().
8️⃣ Включать SplitQuery
Это помогает избежать «картезианского взрыва», когда много Include создают огромное количество дублирующихся строк.
9️⃣ Писать RAW SQL, если логика сложная
Иногда проще и быстрее использовать FromSqlRaw(), чтобы контролировать план запроса напрямую.
🔟 Использовать кэширование
Часто запрашиваемые данные должны идти из кэша — MemoryCache, Redis или новый HybridCache в .NET 9+.
Бонус:
Перед оптимизацией он советует обязательно измерять узкие места: BenchmarkDotNet, SQL Profiler, планы выполнения.
Ссылка на оригинал
На SourceCraft легко создать бот: хранить код, настраивать задачи, писать автотесты, автоматизировать развертывание. А вместе со встроенным AI-ассистентом это можно сделать еще быстрее!
💡 И вот что ещё круто: всем пользователям дарим грант 6 000 ₽ на сервисы облака, чтобы бот жил на полноценной инфраструктуре.
Получить грант и запустить бота
Создавай бота для любых задач на платформе SourceCraft!
Please open Telegram to view this post
VIEW IN TELEGRAM
🧠 EF Core и Repository: когда паттерн мешает, а не помогает
👶 Junior: использует EF Core прямо в контроллере
🧑 Middle: строит BaseRepository, IUnitOfWork, IOrderRepository, IOrderDataAccess...
🧓 Senior: снова использует EF Core — без репозиториев
Почему так?
Сначала Repository Pattern кажется удобным:
4 метода на CRUD — всё аккуратно.
Но как только домен растёт, появляются проблемы:
- Репозиторий на каждую сущность
- Общая логика между сущностями? Куда её девать?
- Репозитории раздуваются до 10+ методов
- Тестируемость становится фикцией: мокаем абстракцию от абстракции
А что насчёт "мы вдруг сменим базу"?
В 99% случаев — не смените.
EF Core и так абстрагирует SQL.
А при переходе на NoSQL придётся переписывать модели, запросы и подход целиком.
А что с "это улучшает разделение ответственности"?
На деле:
- В сервисах висит куча репозиториев
- Общая логика размыта
- Больше обвязки, больше боли, меньше пользы
✅ DbContext уже реализует Repository и Unit of Work.
И это официально указано в исходниках EF Core.
🔥 17 000+ разработчиков уже ушли от репозиториев к практичному использованию EF Core в:
- N-Layered архитектуре
- Clean Architecture
- Vertical Slice
- Specification Pattern
- Интеграционных тестах с in-memory
📖 Подробнее:
https://antondevtips.com/blog/why-you-dont-need-a-repository-in-ef-core
#dotnet #efcore #architecture #backend #repositorypattern
👶 Junior: использует EF Core прямо в контроллере
🧑 Middle: строит BaseRepository, IUnitOfWork, IOrderRepository, IOrderDataAccess...
🧓 Senior: снова использует EF Core — без репозиториев
Почему так?
Сначала Repository Pattern кажется удобным:
4 метода на CRUD — всё аккуратно.
Но как только домен растёт, появляются проблемы:
- Репозиторий на каждую сущность
- Общая логика между сущностями? Куда её девать?
- Репозитории раздуваются до 10+ методов
- Тестируемость становится фикцией: мокаем абстракцию от абстракции
А что насчёт "мы вдруг сменим базу"?
В 99% случаев — не смените.
EF Core и так абстрагирует SQL.
А при переходе на NoSQL придётся переписывать модели, запросы и подход целиком.
А что с "это улучшает разделение ответственности"?
На деле:
- В сервисах висит куча репозиториев
- Общая логика размыта
- Больше обвязки, больше боли, меньше пользы
✅ DbContext уже реализует Repository и Unit of Work.
И это официально указано в исходниках EF Core.
🔥 17 000+ разработчиков уже ушли от репозиториев к практичному использованию EF Core в:
- N-Layered архитектуре
- Clean Architecture
- Vertical Slice
- Specification Pattern
- Интеграционных тестах с in-memory
📖 Подробнее:
https://antondevtips.com/blog/why-you-dont-need-a-repository-in-ef-core
#dotnet #efcore #architecture #backend #repositorypattern