Веб-версияОткрыть в Telegram
CC# Portal | Программирование

C# Portal | Программирование

@KodBlog · канал · Технологии · в индексе с 2026-04-21
13 027подписчиков−41 за неделю
1 494средний охват поста
11.5%ER — охват к подписчикам
63постов за 30 дней
C# Portal | Программирование
Фотография
нажмите — покажем
На дворе 2026 год, а вы всё ещё не используете OpenTelemetry? Вот как он может упростить жизнь software engineer. Если вам важна observability, стоит знать про OpenTelemetry. Это vendor-neutral open-source стандарт для инструментирования приложений и сбора telemetry data. Если проще — речь про: • Logs • Traces • Metrics Работает ли это с .NET? Да. Для .NET есть несколько библиотек, которые достаточно легко интегрировать в приложение. Вот простой гайд, с которого можно начать знакомство: https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet 👉 @KodBlog
10 · 1.6K ·
C
Фотография
нажмите — покажем
Ваш .NET API отлично работает локально. Но это ещё не значит, что он готов к продакшену. Перед релизом я проверяю 8 вещей, которые помогают избежать множества проблем в будущем: наблюдаемость, CORS, документацию API, версионирование, хранение данных, обработку ошибок, проверки работоспособности и ограничение частоты запросов. В статье я разобрал, что важно в каждом пункте, почему это имеет значение и как всё настроить на практике в .NET. Полная статья: https://mwaseemzakir.substack.com/p/before-your-net-api-goes-to-production 👉 @KodBlog
21 · 1.6K ·
C# Portal | Программирование
текст ещё не в индексе
7 · 1.5K ·
C
Фотография
нажмите — покажем
Когда мне нужна функциональность в реальном времени, я выбираю проверенное решение: → SignalR SignalR позволяет добавить взаимодействие в реальном времени в .NET-приложения. При этом клиент может быть написан на React, Angular или обычном JavaScript. Вы создаёте класс SignalR Hub. Это центральный компонент приложения, который управляет клиентскими подключениями и обменом сообщениями. Клиенты подключаются к Hub, чтобы отправлять и получать сообщения, поэтому связь может быть двусторонней. SignalR скрывает детали транспортного механизма. Обычно используется WebSockets, но при необходимости библиотека может переключиться на Server-Sent Events или опрос сервера. Всё, что нужно для начала: статья. SignalR определённо входит в число лучших библиотек экосистемы .NET. 👉 @KodBlog
14 · 1.5K ·
C# Portal | Программирование
текст ещё не в индексе
7 · 1.3K ·
C
Фотография
нажмите — покажем
Ваш API входа раскрывает злоумышленникам, у кого есть аккаунт? Распространённая ошибка: Если email не существует, возвращать «Пользователь не найден». Если пароль неверный, возвращать «Неверные учётные данные». Это уязвимость, позволяющая перебирать учётные записи. Любой может отправить список email-адресов в ваш API и точно узнать, какие из них зарегистрированы, даже не пытаясь подобрать пароль. Обычное исправление: всегда возвращать «Неверные учётные данные», независимо от причины ошибки. Хорошее начало. Но есть второй канал утечки, который многие упускают. Когда пользователя не существует, вы пропускаете проверку пароля и быстро возвращаете ответ. Когда пользователь существует, вы обрабатываете введённый пароль с помощью bcrypt или Argon2, а это занимает ощутимое время. Сообщение одинаковое. Время ответа разное. Злоумышленник просто измеряет миллисекунды и составляет тот же список зарегистрированных аккаунтов, используя секундомер вместо текста ошибки. Вот как закрыть эту брешь: Хешируйте фиктивный пароль, даже если пользователь не существует, чтобы обе ветки обработки занимали одинаковое время. Для фиктивной проверки используйте тот же алгоритм и параметр вычислительной сложности, что и для реальных пользователей. В дополнение к фиктивному хешированию установите фиксированную минимальную длительность ответа. Ограничивайте попытки входа по IP и по учётной записи, чтобы атаки по времени становились слишком медленными и невыгодными. 👉 @KodBlog
15 · 1.4K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Если вы используете ИИ-агентов для написания кода, стоит разобраться в архитектурном тестировании. Вот почему. Архитектурные тесты помогают контролировать технический долг. Он возникает, когда скорость разработки ставят выше продуманной структуры кода. А ИИ-агенты выдают код быстрее, чем мы с вами когда-либо смогли бы. С помощью архитектурных тестов можно контролировать: • Направление зависимостей. • Соглашения об именовании. • Различные правила проектирования. Подробное руководство, которое, думаю, вам понравится: читать статью. Можно даже объяснить агенту правила вашей архитектуры, и он напишет тесты для проверки их соблюдения. Затем достаточно запускать эти тесты в CI, чтобы гораздо быстрее выявлять нарушения. Добавили бы такую проверку в свой процесс ревью кода? 👉 @KodBlog
18 · 1.5K ·
C
Фотография
нажмите — покажем
Можете найти ошибку в этом фрагменте кода? Второй пример вставляет 10 000 записей в базу данных в 43 раза быстрее. Откуда такая огромная разница в производительности? Код в обоих примерах выглядит похоже. Но если понимать, как EF работает под капотом, ответ становится очевидным. Каждый вызов SaveChanges означает обращение к базе данных. В первом примере для вставки каждой записи выполняется отдельный вызов. И накладные расходы быстро накапливаются… Вот как правильно решить эту задачу: читать статью. Лишние запросы к БД — одна из главных причин падения производительности. Не допускайте этой ошибки в своём коде. 👉 @KodBlog
7 · 1.5K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Интерактивные курсы по Git GitHub запустила cборку онлайн курсов, где можно прокачать навыки работы с Git и GitHub бесплатно. Ветки, коммиты, pull request’ы, Actions и реальные командные сценарии. Быстрый и лёгкий способ подтянуть базу и перестать гуглить «как откатить коммит» в неподходящий момент. 👉 @KodBlog
28 · 1.5K ·
C
Фотография
нажмите — покажем
17 .NET-библиотек, которые стоит держать под рукой каждому backend-разработчику Необязательно писать всё с нуля. Вот какие задачи закрывает каждая: Wolverine — современный mediator и message bus для CQRS со встроенными outbox, retries и планированием. Dapper — лёгкий micro ORM. Особенно удобен для сложных запросов с большим количеством таблиц и JOIN. Serilog — структурированное логирование с поддержкой более 40 sinks. Bogus — генерация реалистичных тестовых данных для разработки и тестирования. FluentValidation — валидация моделей с помощью понятного fluent-синтаксиса. Refit — уменьшает количество boilerplate-кода при работе с HTTP API поверх HttpClient. Health Checks — стандартный механизм проверки состояния сервисов и интеграции с мониторингом и алертами. Hangfire / Quartz — надёжное выполнение и планирование фоновых задач для сценариев, где обычных hosted services уже недостаточно. Noda Time — корректная работа с датами, временем и часовыми поясами. Создана Джоном Скитом. Autofac — DI-контейнер для более сложных сценариев внедрения зависимостей. MiniProfiler — простой способ быстро найти узкие места в производительности приложения. FastEndpoints — библиотека для создания Web API на основе REPR-паттерна. Структурированная альтернатива controllers и Minimal APIs. NSubstitute — простой в настройке mocking framework для тестов. System.Text.Json — зрелая сериализация JSON и стандартный вариант для современных .NET-приложений. BenchmarkDotNet — точные бенчмарки производительности .NET-кода. Scalar — интерактивная документация для API, современная альтернатива Swagger UI. SignalR — упрощает реализацию real-time функций: чатов, уведомлений, live-обновлений и других сценариев. А какой инструмент из списка чаще всего используете вы? 👉 @KodBlog
56 · 1.6K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Как создавать фоновые задачи в .NET? С Quartz достаточно реализовать один интерфейс: • Создать класс задачи. • Зарегистрировать его в Quartz. • Quartz возьмёт на себя планирование и выполнение. Библиотека полностью поддерживает DI, поэтому можно внедрять нужные сервисы. Задачи выполняются в отдельном scope, что позволяет безопасно внедрять DbContext. Начав использовать Quartz, сложно вернуться к другим решениям — хотя альтернативы, конечно, есть. Подробное руководство по работе с Quartz в .NET: Читать статью 👉 @KodBlog
17 · 1.5K ·
C
Фотография
нажмите — покажем
Шпаргалка по безопасности .NET • Устанавливайте для cookies флаг HttpOnly, чтобы клиентские скрипты не могли получить к ним доступ. • Используйте [Authorize] для контроллеров и .RequireAuthorization() для эндпоинтов, чтобы ограничивать доступ. • Требуйте надёжные пароли и храните их с помощью специализированных алгоритмов хеширования паролей с уникальной солью. При использовании pepper храните его отдельно от базы данных. • При аутентификации через cookies проверяйте anti-forgery-токены для запросов, изменяющих состояние, чтобы защищаться от CSRF. • Обновляйте NuGet-пакеты и используйте инструменты, которые уведомляют об уязвимостях зависимостей. • Логируйте подозрительную активность и события безопасности, не записывая пароли, токены и другие секреты. • Для защиты от SSRF проверяйте адреса исходящих запросов, формируемые на основе пользовательского ввода, и ограничивайте доступные назначения. • Не храните секреты в appsettings.json и репозитории. Используйте предназначенные для этого хранилища секретов. 👉 @KodBlog
26 · 1.4K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Мой секрет, как не ронять продакшен: запускать тесты в CI/CD. Это даёт мне максимум уверенности в коде. Всё благодаря Testcontainers и Docker. Внешние сервисы можно запускать в контейнерах и подключаться к ним из приложения и тестов. Хотите вывести интеграционное тестирование в .NET на новый уровень? Подробное руководство Что думаете о таком подходе? Он позволяет приблизить тестовое окружение к продакшену с минимальными дополнительными усилиями. Да, выполнение CI замедлится, но для меня это оправданно: так я обнаружил множество проблем ещё до того, как они попали в продакшен. 👉 @KodBlog
17 · 1.4K ·
C
Чем отличаются middleware и фильтры в .NET? Фильтры в ASP.NET Core: • Имеют доступ к контексту MVC: данным маршрутизации и, на соответствующих этапах, результатам привязки модели. • Выполняются внутри конвейера MVC при обработке действий контроллера. • Применяются к действиям контроллеров. • Используются для задач MVC: логирования, авторизации и валидации. • Примеры: ActionFilterAttribute и ResultFilterAttribute. • Позволяют вынести общую логику обработки действий MVC в отдельные компоненты. • Имеют доступ к HttpContext, но ориентированы на обработку в рамках MVC. • Порядок выполнения зависит от типа фильтра, значения Order и области применения. • Могут применяться глобально, к отдельному контроллеру или действию. Middleware в ASP.NET Core: • Являются частью HTTP-конвейера обработки запросов. • Могут выполнять логику до и после следующих компонентов, а также прерывать обработку запроса. • Применяются ко всему приложению или к отдельным веткам конвейера. • Настраиваются в Program.cs, а в проектах с классом Startup — в Startup.cs. • Примеры регистрации: UseAuthentication(), UseAuthorization() и UseRouting(). • Решают общие задачи обработки запросов, не ограничиваясь MVC. Имеют прямой доступ к HttpContext, запросу и ответу. • Выполняются в порядке регистрации, а обработка после вызова следующего компонента проходит в обратном порядке. Что выбрать? Используйте middleware, если задача решается на уровне HTTP-запроса и ответа: обработка ошибок, логирование, аутентификация. Выбирайте фильтры, когда нужны детали выполнения MVC: аргументы действия, состояние модели или результат действия. 👉 @KodBlog
13 · 1.3K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Как использовать ИИ-агентов в .NET-разработке На freeCodeCamp вышел гайд по внедрению ИИ-ассистентов в рабочий процесс .NET-команды. Внутри примеры на C#: генерация контроллеров и DTO, написание unit-тестов, рефакторинг, отладка и работа с Entity Framework. Отдельно разобраны составление промптов, интеграция в CI/CD и безопасность. Автор показывает, как ускорить рутинные задачи, сохраняя ревью кода и автоматические проверки. Читать статью 👉 @KodBlog
30 · 1.3K ·
C
Фотография
нажмите — покажем
Что такое RBAC — управление доступом на основе ролей? RBAC помогает организовать авторизацию: роли объединяют разрешения, пользователи получают роли и вместе с ними право выполнять определённые действия. Принцип простой: • Роли задают общие правила доступа. • Каждая роль содержит набор разрешений. • Пользователи получают разрешения через назначенные роли. • Разрешения определяют, что пользователь может делать. Зачем нужны отдельные разрешения? Одних проверок ролей часто недостаточно для точных правил доступа. Например, роль «Редактор» слишком общая, если нужно отдельно управлять правами на создание, публикацию и удаление материалов. Разрешения позволяют описать каждое действие отдельно. Чтобы дать другой роли доступ к нему, достаточно назначить ей соответствующее разрешение. Начните с вопроса «Какие действия может выполнять пользователь?» — так проще выстроить понятную и гибкую систему авторизации. Подробнее о RBAC и его реализации 👉 @KodBlog
15 · 1.2K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Union types в C# 15 Годами разработчики C# имитировали union types — типы-объединения — через маркерные интерфейсы, базовые классы и библиотеку OneOf. Всё ради того, чтобы выразить простую идею: «результат — либо Success, либо Failure». C# 15 переносит эту возможность на уровень языка. Что меняется на практике: • Набор вариантов объявляется один раз, например Success или Failure, и компилятор знает все допустимые случаи. • Компилятор проверяет полноту switch: если пропустить вариант, он сообщит об этом ещё при компиляции. • Для описания закрытого набора результатов больше не нужна сторонняя библиотека. Такие возможности помогают предотвращать ошибки при моделировании состояний. То, что раньше требовало обходных решений, получает встроенную поддержку. 👉 @KodBlog
16 · 1.2K ·
C
Фотография
нажмите — покажем
Архитектура ПО — это просто?.. Объединяйте связанные концепции, и приложения станут лучше. Неужели всё настолько просто? Конечно, нет. Но направление верное. За этим стоит cohesion — связность. Идея в том, чтобы держать компоненты одной функциональности рядом. В слоистой архитектуре они обычно разнесены по разным слоям. Чтобы добавить или изменить одну функцию, приходится править код сразу в нескольких местах. Vertical Slice Architecture предлагает другой подход: все файлы одного сценария использования располагаются рядом. Так проще найти нужные компоненты, разобраться в их взаимодействии и внести изменения. Подробнее о Vertical Slice Architecture 👉 @KodBlog
10 · 1.1K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Ваш API отвечает пять минут? Это уже захват заложников Пользователь смотрит на индикатор загрузки. Запрос занимает ресурсы сервера. Балансировщик обрывает соединение по тайм-ауту. Клиент повторяет запрос — и один отчёт строится уже дважды. Здесь поможет перенос долгой операции в фоновую обработку. Как выглядит схема: • Клиент отправляет POST /reports. • API ставит задачу в очередь и быстро возвращает 202 Accepted с заголовком Location: /reports/42. • Фоновый воркер забирает задачу и выполняет пятиминутную работу. • Клиент запрашивает GET /reports/42 и получает статус Running. • При следующей проверке получает Done и ссылку на результат. Что это даёт: • HTTP-запросы завершаются быстро, не дожидаясь построения отчёта. • Длительность фоновой задачи больше не упирается в тайм-аут запроса. • Воркеры масштабируются независимо от API. • Повторная проверка статуса не запускает создание отчёта заново. Для безопасного повторения самого POST предусмотрите ключ идемпотентности, чтобы не создавать дубликаты задач. Ещё две детали: • Возвращайте Retry-After, чтобы клиент понимал, через какое время снова проверить статус. • Используйте SignalR или webhook, если нужно уведомлять о готовности вместо периодических запросов. Длительная операция становится отдельным ресурсом: её можно создать, проверить состояние и получить результат. А как вы обрабатываете долгие задачи в своих API: polling, webhooks или SignalR? 👉 @KodBlog
13 · 1.1K ·
C
Фотография
нажмите — покажем
Health Checks в .NET — два вызова методов • AddHealthChecks() регистрирует необходимые сервисы. • MapHealthChecks() добавляет эндпоинт для проверки состояния приложения. Но это только инфраструктура. Сами проверки нужно зарегистрировать отдельно. Для популярных баз данных, брокеров сообщений и других зависимостей уже существуют готовые библиотеки проверок. Подробнее о Health Checks 👉 @KodBlog
16 · 1.1K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Хватит возвращать BadRequest("какая-то строка") Когда каждый эндпоинт возвращает ошибки в своём формате, клиентам приходится отдельно обрабатывать каждый вариант. В ASP.NET Core есть ProblemDetails: AddProblemDetails() и Results.Problem() помогают использовать единый машиночитаемый формат ошибок по стандарту RFC. 👉 @KodBlog
28 · 1.1K ·
C
Фотография
нажмите — покажем
Пишете код каждый день? Помните о пяти вещах: • Сначала добейтесь, чтобы код работал. • Затем сделайте его понятным и аккуратным. • Подстрахуйте его тестами. • Избегайте избыточного усложнения. • Проводите рефакторинг, когда это необходимо — а обычно это необходимо. Рефакторинг — ваша суперсила для приведения кода в порядок. Пять проверенных техник рефакторинга С ИИ-агентами этот подход тоже работает. Но нужно уметь направлять их: ваши навыки разработки по-прежнему пригодятся. 👉 @KodBlog
10 · 1K ·
C# Portal | Программирование
Фотография
нажмите — покажем
Один API-запрос на несколько минут создаёт проблемы всем. Пользователь смотрит на индикатор загрузки, сервер держит соединение открытым, а балансировщик или прокси может оборвать запрос по тайм-ауту. Повторные попытки только усугубляют ситуацию. Решение — изменить подход к обработке долгих задач: • Принять задачу и сразу вернуть 202 Accepted со ссылкой для проверки статуса. • Выполнить тяжёлую работу в фоновом обработчике. • Позволить клиенту опрашивать статус или получить уведомление о готовности результата. Теперь отчёт, который формируется пять минут, не требует держать HTTP-запрос открытым всё это время. API остаётся отзывчивым, а фоновые обработчики можно масштабировать независимо от веб-серверов. Длительная задача — это ресурс, который вы создаёте и отслеживаете, а не ответ, которого нужно ждать в открытом соединении. 👉 @KodBlog
9 · 879 ·
Фотография
нажмите — покажем
🦈 Открытое собеседование на Middle C# | 6 октября, 19:00 МСК Приглашаем на открытое собеседование: Senior C# разработчик проведёт его в прямом эфире. Можно посмотреть, как всё устроено изнутри, и понять, насколько ты готов к такому интервью. Как это будет: 📂 Собеседует Александр Моргунов — Senior C# разработчик, 7+ лет в европейских высоконагруженных сервисах. Отвечает разработчик-доброволец; 📂 Всё как на настоящем собесе: Александр задаёт те вопросы и задачи, которые даёт кандидатам на своих интервью. Заранее их никто не знает; 📂 После каждого ответа Александр даст обратную связь: что прозвучало сильно, а что стоило раскрыть иначе. Так станет понятнее, на что обращают внимание на собесе; 📂 В конце можно задать любой вопрос. Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для C# разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир -> @shortcut_csharp_bot Реклама. О рекламодателе.
3 · 656 ·
C
Фотография
нажмите — покажем
Не начинайте с микросервисов ❌ Даже если уверены, что в будущем они понадобятся вашему приложению. У микросервисов есть скрытые издержки: • Координация команд. • Сбои в распределённой системе. • Работа с eventual consistency — согласованностью данных в конечном счёте. • Автоматизация развёртывания нескольких сервисов. • Управление множеством инфраструктурных компонентов. • Выделение дополнительных ресурсов по мере необходимости. На старте проекта такая сложность часто не оправдана. Менее рискованный подход: • Начните с монолита. • Определите границы предметной области — bounded contexts. • Решите, нужно ли выделять отдельные контексты в самостоятельные сервисы. На выбор архитектуры влияют и другие факторы, которые не уместить в одном посте. Но начинать с более простой системы и усложнять её по мере необходимости — разумная отправная точка. 👉 @KodBlog
3 · 540 ·

Открытая публичная лента из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.

Только публичный контент, официальный API Telegram. О проекте · Вопросы · Чего мы не делаем · Убрать страницу из выдачи · Каталог · Поиск · Как мы считаем