Available now! Telegram Research 2025 — the year's key insights 
.NET Разработчик
Open in Telegram
Дневник сертифицированного .NET разработчика. Заметки, советы, новости из мира .NET и C#. Для связи: @SBenzenko Поддержать канал: - https://boosty.to/netdeveloperdiary - https://patreon.com/user?u=52551826 - https://pay.cloudtips.ru/p/70df3b3b
Show more6 705
Subscribers
+324 hours
+87 days
+2830 days
Posts Archive
6 705
День 2681. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 11
11. Советник в AWS Redshift
Что даёт: рекомендации по оптимизации, специфичные для Redshift.
Тип: Встроенный сервис AWS
Стоимость: Бесплатно (входит в Redshift)
Зачем нужен
Redshift предъявляет уникальные требования к оптимизации: ключи распределения, ключи сортировки, сжатие. Советник анализирует шаблоны запросов и рекомендует оптимизации.
Использование
Панель управления AWS: Redshift → Advisor recommendations
Либо CLI:
aws redshift describe-cluster-recommendations \
--cluster-identifier my-clusterSELECT * FROM svv_redshift_advisor_recommendations;ALTER TABLE orders
ALTER COLUMN customer_notes ENCODE LZO;CREATE TABLE orders_new (LIKE orders)
SORTKEY (order_date, customer_id);
INSERT INTO orders_new SELECT * FROM orders;
DROP TABLE orders;
ALTER TABLE orders_new RENAME TO orders;CREATE TABLE order_items_new (LIKE order_items)
DISTKEY (order_id);
INSERT INTO order_items_new SELECT * FROM order_items;
-- …VACUUM SORT ONLY customers;
ANALYZE customers;BEGIN;
-- 1. Создаём таблицу с оптимизациями
CREATE TABLE orders_new (LIKE orders)
SORTKEY (order_date, customer_id)
DISTKEY (customer_id);
-- 2. Копируем данные (может занять часы)
INSERT INTO orders_new SELECT * FROM orders;
-- 3. Меняем таблицы (атомарно)
ALTER TABLE orders RENAME TO orders_old;
ALTER TABLE orders_new RENAME TO orders;
-- 4. Удаляем старую (после проверки)
DROP TABLE orders_old;
COMMIT;SELECT * FROM svv_vacuum_progress;6 705
День 2680. #ЗаметкиНаПолях
Когда Сценарий Выполняется Наполовину: Проектирование с Учётом Частичного Сбоя в .NET. Окончание
Начало
Стратегии обработки побочных эффектов
1. Выносим транзакционные задачи на конец процесса
Первый шаг — механический. Все транзакционные операции должны быть зафиксированы в последнюю очередь, после того как все внешние вызовы либо успешно завершены, либо их сбои явно обработаны.
var order = Order.Create(…);
var charge = await
payments.ChargeAsync(…);
if (charge.IsFailure) return charge;
order.MarkPaid(charge.Value.TransactionId);
// …
orders.Insert(order);
await unitOfWork.SaveChangesAsync(ct);
return Result.Success();// …
orders.Insert(order);
order.Raise(new OrderPlacedEvent(order.Id));
await unitOfWork.SaveChangesAsync(ct);
// …var charge = await payments.ChargeAsync(
new ChargeRequest
{
OrderId = order.Id,
Amount = order.Total,
IdempotencyKey = order.Id.ToString()
},
ct);// …
try
{
// …
await unitOfWork.SaveChangesAsync(ct);
}
catch (Exception ex)
{
await outbox.PublishAsync(
new PaymentFailedEvent(
order.Id,
charge.Value.TransactionId,
order.Total,
Reason: ex.Message),
ct);
throw;
}
// …6 705
День 2679. #ЗаметкиНаПолях
Когда Сценарий Выполняется Наполовину: Проектирование с Учётом Частичного Сбоя в .NET. Начало
Одна из повторяющихся ошибок во многих кодовых базах — дублированное списание средств. С клиента списали деньги один раз, но наша система посчитала, что платёж не удался. Платёжный провайдер снял деньги, заказ вернулся в состояние черновика, и пользователь получил сообщение «Платёж не удался, пожалуйста, повторите попытку». Одно действие пользователя привело к тому, что каждая подсистема получила разное мнение о том, что произошло на самом деле. Сценарий использования выглядит как транзакция, потому что он находится в одном вызове метода. Но как только он затрагивает более одной системы, вы сталкиваетесь с возможностью частичных сбоев.
Код, который выглядит нормально
Вот типичный сценарий «размещения заказа»:
internal sealed class PlaceOrder(
IOrderRepository orders,
IPaymentService payments,
IEmailService email,
IUnitOfWork uow)
{
public async Task<Result> ExecuteAsync(
PlaceOrderRequest or, CancellationToken ct)
{
var order = Order.Create(or.CustomerId, or.Items);
orders.Insert(order);
await payments
.ChargeAsync(order.Id, order.Total, ct);
await email
.SendOrderConfirmationAsync(order.Id, ct);
await uow.SaveChangesAsync(ct);
return Result.Success();
}
}6 705
День 2678. #Карьера
15 Уроков Программирования от Опытного Разработчика. Окончание
Начало
8. ИИ не заменит разработчиков (в ближайшее время)
ИИ может помочь в написании кода, объяснении концепций и ускорении разработки, но ему по-прежнему нужны разработчики-люди для руководства. Большая часть работы разработчика — понимание требований, решение проблем, общение с командами и принятие решений. Это сложно автоматизировать. Поэтому вместо того, чтобы беспокоиться об ИИ, используйте его как инструмент для повышения своей продуктивности.
9. Будьте добры к начинающим
Начинающие иногда могут задавать много вопросов или оспаривать ваши идеи. Но все мы были новичками. Большинство начинающих просто пытаются учиться и делать всё возможное. Часть вашей роли как старшего разработчика — направлять и поддерживать их. Они могут ещё не знать, чего они не знают. Будьте терпеливы, помогайте им расти и относитесь к ним с уважением.
10. Работайте умнее, а не усерднее
Полезная привычка — иметь чёткое «время окончания работы», чтобы сосредоточиться на здоровье, хобби и личной жизни. Планирование дня и уменьшение отвлекающих факторов также могут помочь. Такие методы, как техника Помодоро, могут улучшить концентрацию и продуктивность. Работать эффективнее означает управлять своим временем, энергией и концентрацией, а не просто работать дольше.
11. Думайте в долгую
Всегда думайте о долгосрочных последствиях своих решений: о навыках, которые вы приобретаете, о компаниях, в которые вы устраиваетесь, и о людях, с которыми вы работаете. Многие сосредотачиваются на быстрых результатах и мгновенном вознаграждении. Но построение успешной карьеры разработчика требует времени и последовательности.
Краткосрочное планирование часто приводит к техническому долгу или постоянной смене направлений без освоения чего-либо. Успешные разработчики, как правило, те, кто остаётся последовательным и продолжает двигаться вперед, даже когда становится трудно.
12. Наибольшее повышение зарплаты часто происходит при смене работы
Во многих компаниях индексация зарплаты невелика. При смене работы повышение зарплаты иногда может быть намного выше. Поэтому многие разработчики быстрее увеличивают доход, меняя компании после получения опыта. Однако нужно быть готовым к техническим собеседованиям, задачам по программированию и обсуждениям проектирования систем.
Многие разработчики избегают собеседований, но улучшение этого навыка может открыть лучшие карьерные возможности. Каждое собеседование — это также опыт обучения.
13. Не угрожайте начальнику
Вы можете расстроиться, если не получите повышения или признания. Но избегайте угроз или шантажа начальника, чтобы получить желаемое. Даже если это сработает один раз, это может подорвать доверие и навредить вашим долгосрочным отношениям. Оставайтесь профессиональными и спокойными. Постарайтесь найти позитивные решения как для себя, так и для своего руководителя. Если ситуация не улучшится, лучшим вариантом может стать поиск возможностей в другом месте.
14. Не бойтесь тяжёлой работы
Если вы хотите стать отличным разработчиком, вы должны быть готовы много работать. В интернете много советов, коротких путей и «лайфхаков», но ни один из них не заменит постоянных усилий и практики. Совершенствование навыков требует времени, терпения и целеустремлённости. В то же время, помните о необходимости делать перерывы и избегать выгорания.
15. Качество важнее количества
В мире технологий много шума — постоянно появляются новые инструменты, фреймворки и тренды. Один из важных навыков для разработчиков — умение сосредотачиваться на том, что действительно важно.
Это правило применимо к коду, проектам и даже к людям, с которыми вы работаете — всегда выбирайте качество, а не количество. Новые технологии будут продолжать появляться. Но разработчики, которые остаются сосредоточенными, последовательными и дисциплинированными, всегда будут преуспевать.
Источник: https://medium.com/@sunil17bbmp/15-programming-lessons-i-learned-from-10-years-of-coding-321a47d14b72
6 705
День 2677. #Карьера
15 Уроков Программирования от Опытного Разработчика. Начало
За время вашей карьеры вам может случиться работать как в крупных корпорациях с устаревшим кодом, так и в небольших стартапах, которые меняют стратегию почти каждую неделю. Возможно, вы будете наставником других разработчиков, помогая им расти. У вас будут и провальные, и успешные проекты. Вот вещи, которые пригодятся вам для построения успешной карьеры.
1. Придерживайтесь одного фреймворка
В первые 3-5 лет работы программистом старайтесь сосредоточиться на одном фреймворке. Игнорируйте постоянный шум и новости об очередной крутой системе. Вместо этого выберите одну и освойте её. Когда вы действительно понимаете одну технологию, будет гораздо проще изучать другие.
Многие разработчики совершают ошибку, перескакивая с одного модного фреймворка на другой. После многих лет программирования они всё ещё испытывают трудности с основами, потому что так и не освоили что-то одно досконально.
Не беспокойтесь о том, чтобы изучить всё сразу. Как только вы станете опытным разработчиком в какой-либо технологии или стеке, изучение новых станет намного проще — и многие коллеги будут считать вас опытным в том, что вы недавно изучили.
2. В случае сомнений сосредоточьтесь на основах
Фреймворки и библиотеки, которые вы используете сегодня, могут исчезнуть через 10 лет. Но основы никогда не меняются. Это особенно важно, если вы самоучка. Построение карьеры разработчика на слабых основах подобно строительству замка на песке — он в конце концов рухнет. Сосредоточьтесь на изучении структур данных, алгоритмов, решении проблем, чистом коде и проектировании систем. Эти навыки помогут адаптироваться к любой технологии в будущем.
3. Верьте в себя
Независимо от того, сколько вы знаете, вы не будете расти, если не верите в себя. Многие разработчики никогда не достигают более высокого уровня, потому что боятся пробовать. Они думают, что недостаточно хороши, и перестают высказываться или пробовать что-то новое. Вы можете достичь гораздо большего, чем думаете. Верьте в себя и продолжайте двигаться вперёд.
4. Игнорируйте хейтеров
Негатив повсюду в разработке ПО — в код-ревью, на собеседованиях или командных обсуждениях. Некоторые оставляют резкие комментарии или ненужную критику. Помните: люди, которые негативно относятся к вам, обычно негативно относятся ко всем. Не позволяйте их отношению влиять на вашу уверенность или мотивацию. Научитесь устанавливать границы. Вы учите людей, как с вами обращаться. Что вы можете сделать, с хейтерами — игнорировать их и двигаться дальше. Берегите свою энергию, уверенность и настрой.
5. Не принимайте ничего на свой счёт
В разработке вы будете получать много обратной связи. Не принимайте её на свой счёт. В большинстве случаев люди критикуют код, а не вас как личность. Используйте обратную связь как возможность учиться и совершенствоваться. Воспринимайте карьеру в разработке как игру. Иногда вы выигрываете, иногда проигрываете. Важно, чтобы вы продолжали учиться, совершенствоваться и двигаться вперёд.
6. Будьте готовы к неудачам (многочисленным)
Неудачи — часть работы разработчика. Некоторые проекты будут проваливаться. Вы можете упустить повышение, получить отказ на собеседовании или увидеть, как вашу работу отменяют. Это нормально — даже для сеньоров или технических директоров. Учитесь на неудачах. Чем больше вы пробуете, тем больше узнаёте. Не тратьте энергию на беспокойство о том, что может пойти не так. Сосредоточьтесь на решении проблем и ежедневном совершенствовании.
7. Научитесь отладке
Умение правильно отлаживать код значительно упростит вашу жизнь. Хорошие навыки отладки помогают решать критические проблемы, когда приложения ломаются. К сожалению, многие разработчики игнорируют этот навык. Если вы освоите отладку, тестирование, работу с устаревшим кодом и написание документации, вы будете выделяться как надёжный и сильный разработчик.
Окончание следует…
Источник: https://medium.com/@sunil17bbmp/15-programming-lessons-i-learned-from-10-years-of-coding-321a47d14b72
6 705
День 2676. #ЗаметкиНаПолях
Реализуем Немедленный Отзыв Токенов в .NET 10. Окончание
Начало
Настройка токенов
Переключение клиента на использование референтных токенов - одна строка конфигурации. При определении клиента в IdentityServer установите AccessTokenType:
new Client
{
ClientId = "banking_app",
ClientSecrets = { new Secret("secret".Sha256()) },
AllowedGrantTypes = GrantTypes.Code,
// Вот эта строка
AccessTokenType = AccessTokenType.Reference,
AllowOfflineAccess = true,
RedirectUris = { "https://banking.example.com/signin-oidc" },
AllowedScopes = { "openid", "profile", "accounts.read", "transfers.write" }
};new ApiResource("banking_api")
{
Scopes = { "accounts.read", "transfers.write" },
ApiSecrets = { new Secret("api_secret".Sha256()) }
};builder.Services.AddAuthentication("token")
.AddOAuth2Introspection("token", opts =>
{
opts.Authority = "https://identity.banking.example.com";
opts.ClientId = "banking_api";
opts.ClientSecret = "api_secret";
});builder.Services.AddAuthentication("token")
.AddJwtBearer("token", opts =>
{
opts.Authority = "https://identity.banking.example.com";
opts.Audience = "banking_api";
opts.TokenValidationParameters.ValidTypes = ["at+jwt"];
opts.ForwardDefaultSelector = Selector.ForwardReferenceToken("introspection");
})
.AddOAuth2Introspection("introspection", opts =>
{
opts.Authority = "https://identity.banking.example.com";
opts.ClientId = "banking_api";
opts.ClientSecret = "api_secret";
});using Duende.IdentityModel.Client;
var client = new HttpClient();
var result = await client.RevokeTokenAsync(
new TokenRevocationRequest
{
Address = "https://identity.banking.example.com/connect/revocation",
ClientId = "banking_app",
ClientSecret = "secret",
Token = stolenAccessToken
});
if (result.IsError)
logger.LogError("Token revocation failed: {Error}", result.Error);await client.RevokeTokenAsync(
new TokenRevocationRequest
{
Address = "https://identity.banking.example.com/connect/revocation",
ClientId = "banking_app",
ClientSecret = "secret",
Token = refreshToken
});6 705
День 2675. #ЗаметкиНаПолях
Реализуем Немедленный Отзыв Токенов в .NET 10. Начало
Представьте себе этот кошмарный сценарий. У клиента банка украли телефон, где ваше мобильное приложение авторизовано, предоставляя вору полный доступ к счетам клиента. В службу поддержки поступает звонок. Каждая секунда на счету. Какова скорость вашей реакции для отмены активной сессии и обеспечения безопасности средств клиента?
Если вы полагаетесь на стандартные автономные JWT-токены, честный ответ может быть «до часа», в зависимости от срока действия токена. Этого недостаточно. Рассмотрим, как референтные токены предоставляют вам кнопку экстренной остановки именно в таких ситуациях, и как это реализовать в Duende IdentityServer в .NET 10.
Проблема с автономными JWT
Автономные JWT — это основной инструмент современной авторизации. Они содержат все необходимые API данные для принятия решений о доступе внутри себя. Никаких обращений к БД или сетевых вызовов к поставщику идентификации. API проверяет подпись, проверяет срок действия, и вы получаете доступ. Просто и быстро.
Но это палка о двух концах. После выдачи JWT поставщику идентификации больше нечего о нём сказать. Токен действителен в течение срока действия, обычно от 5 до 60 минут. Если устройство украдено, учётная запись пользователя скомпрометирована или обнаружена угроза, вы не можете отозвать этот токен. Вы вынуждены ждать, пока он истечёт.
Для многих приложений такой компромисс вполне приемлем. Но для сред с высоким уровнем безопасности, таких как банковские, государственные системы или здравоохранение, это недопустимый компромисс.
Референтные токены
Вместо того чтобы встраивать все утверждения непосредственно в токен, IdentityServer хранит содержимое токена на стороне сервера в своём постоянном хранилище предоставленных прав и передаёт клиенту идентификатор (дескриптор). Когда API получает этот дескриптор, он вызывает конечную точку интроспекции IdentityServer для проверки токена и получения утверждений.
Поскольку данные токена хранятся на сервере, вы можете удалить их в любое время. Отзыв происходит немедленно. В следующий раз, когда API вызовет конечную точку интроспекции, он получит в ответ
"active": false, и доступ будет запрещён.
Однако, каждый вызов API требует обращения к конечной точке интроспекции. Для публичных API в масштабах сети интернет это излишне. Для внутренних сервисов и сред с высоким уровнем безопасности – это разумная цена за возможность мгновенного отключения.
Когда использовать референтные токены
Референтные токены не являются универсальной заменой JWT. Они проявляют свои преимущества в определённых сценариях:
- Немедленное аннулирование является жёстким требованием (банковская сфера, здравоохранение, системы, ориентированные на соответствие нормативным требованиям);
- Внутреннее взаимодействие между сервисами, где время отклика при интроспекции незначительно;
- Операции с высоким риском, где преимущества в безопасности перевешивают затраты на производительность.
Для общедоступных API в масштабе, где задержка аннулирования приемлема, автономные JWT с коротким сроком действия остаются надёжным выбором. Вы даже можете комбинировать: использовать референтные токены для клиентов с конфиденциальными данными и JWT для клиентов с более низким риском, и всё это в рамках одного развёртывания IdentityServer.
Далее рассмотрим реализацию.
Окончание следует…
Источник: https://duendesoftware.com/blog/20260428-the-emergency-stop-button-implementing-immediate-token-revocation-in-dotnet-106 705
День 2674. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 10
10. pg_qualstats (Статистика Предикатов Запросов)
Что даёт: статистику, какие условия WHERE больше всего выиграют от индексов.
Зачем нужен
Создание индексов — это гадание на кофейной гуще без данных. Какие столбцы на самом деле запрашиваются чаще всего? Какие предикаты являются с? pg_qualstats отслеживает использование условий WHERE во всех запросах, точно показывая, какие индексы окажут максимальное влияние.
Установка
1. Устанавливаем расширение
CREATE EXTENSION pg_qualstats;shared_preload_libraries = 'pg_stat_statements,pg_qualstats'
pg_qualstats.enabled = on
pg_qualstats.track_constants = onSELECT
qualid,
queryid,
userid,
dbid,
lrelid::regclass AS table_name,
lattnum AS column_number,
opno::regoperator AS operator,
eval_type,
count AS execution_count
FROM pg_qualstats
ORDER BY count DESC
LIMIT 20;table_name | column | operator | execution_count orders | customer_id | = | 450,234 orders | order_date | >= | 234,567 orders | status | = | 123,456 customers | email | = | 89,234Т.е. "customer_id = ?" использовалось 450 тыс раз. Это явный кандидат на индекс. Предложения индексов
SELECT
v.relname,
v.attnames,
sum(v.execution_count) as execution_count,
sum(v.nbfiltered) as rows_filtered
FROM (
SELECT
lrelid::regclass AS relname,
array_agg(DISTINCT attname) AS attnames,
count AS execution_count,
nbfiltered
FROM pg_qualstats
JOIN pg_attribute ON (attrelid = lrelid AND attnum = lattnum)
WHERE nbfiltered > 100 -- Только избирательные предикаты
GROUP BY lrelid, lattnum, count, nbfiltered
) v
GROUP BY v.relname, v.attnames
ORDER BY execution_count DESC;SELECT
schemaname,
tablename,
indexname,
idx_scan AS index_scans,
pg_size_pretty(pg_relation_size(indexrelid)) AS index_size
FROM pg_stat_user_indexes
WHERE idx_scan = 0 -- не используется
AND indexrelid NOT IN (
-- Исключаем индексы из pg_qualstats
SELECT DISTINCT lrelid
FROM pg_qualstats
WHERE count > 0
)
ORDER BY pg_relation_size(indexrelid) DESC;# Отслеживаем 10% запросов
pg_qualstats.sample_rate = 0.1
# Исключаем пользователей/базы
pg_qualstats.exclude_users = 'readonly_user,report_user'SELECT
pg_stat_statements.query,
pg_qualstats.count AS qualstats_calls,
pg_stat_statements.calls AS total_calls,
(pg_qualstats.count::float / pg_stat_statements.calls) AS tracking_ratio
FROM pg_qualstats
JOIN pg_stat_statements USING (queryid);6 705
День 2673. #ЗаметкиНаПолях
Как Масштабировать Длительные Запросы API
В каждой системе рано или поздно возникает конечная точка, выполнение которой занимает минуты (или даже больше). В итоге пользователи несколько минут ждут ответа, а API удерживает запрос открытым всё это время, расходуя поток, соединение и прочие ресурсы. Небольшой всплеск трафика на этой одной конечной точке потенциально может привести к сбою всего API. Рассмотрим последовательность действий для решения этой проблемы.
0. Наивная версия
Оставим всё, как есть. В этом подходе нет ничего плохого — просто за корректность приходится платить доступностью. Пользовательский опыт плох, а радиус поражения велик: каждый принятый длительный запрос — это заблокированные ресурсы, которые могли бы быть потрачены на обработку других запросов.
1. Принимаем работу, но не выполняем её
Добавим таблицу заданий для работы, которую нужно выполнить. Теперь API:
- Проверяет запрос.
- Вставляет строку в таблицу заданий со статусом «Ожидание».
- Возвращает
202 Accepted с ID задания.
Фоновый обработчик внутри того же API, читает строки со статусом «Ожидание» и обрабатывает их. Клиент либо опрашивает конечную точку GET /jobs/{id}, либо — что лучше — сервер отправляет обновления через SignalR, Server-Sent Events или email, когда задание выполнено.
Это уже даёт много преимуществ. Конечная точка быстро возвращает результат, а всплеск входящих запросов просто превращается во всплеск строк в таблице. Запись в таблицу обходится дёшево.
2. Отделение обработчика от API
Фоновый обработчик из шага 1 по-прежнему конкурирует с API за процессор, память и пул соединений. Если обработка становится ресурсоёмкой или медленной, API начинает это ощущать. Решение в том, чтобы вынести фоновый обработчик в отдельно развёртываемый компонент и разместить между ними очередь.
API публикует сообщение в очередь. Пул фоновых обработчиков получает данные из очереди и выполняет фактическую работу.
- Очередь поглощает пиковые нагрузки. API может продолжать принимать задачи с постоянной скоростью, в то время как рабочие процессы выполняют задания в своём темпе.
- Вы масштабируете рабочие процессы отдельно от API. Рост числа фоновых задач не требует увеличения количества экземпляров API.
- Сбой рабочего процесса — просто сообщение, которое возвращается в очередь, а не ошибка 500 для пользователя.
Вы также получаете возможность повторных попыток, приостановку/возобновление, структурированную обработку ошибок и очередь недоставленных сообщений — фактически бесплатно, поскольку инфраструктура очередей уже предоставляет их.
Чего это стоит
Это дополнительные компоненты, которые нужно развёртывать и отслеживать. Теперь клиент должен спрашивать, готов ли ответ, или вы должны его оповещать. И каждая задача должна быть идемпотентной, потому что доставка «хотя-бы-раз» означает, что рабочие процессы будут видеть дубликаты.
Если у вас только одна медленная конечная точка и умеренный трафик, это избыточно. Простое «запустить и забыть» с опросом статуса внутри того же процесса вполне подойдет.
Облачный сервис
Не обязательно делать всё самому. Вот несколько альтернатив:
- AWS SQS + Lambda или Azure Service Bus + Azure Functions, когда нужно масштабировать пул рабочих процессов до нуля и не охота управлять хостами.
- Azure Durable Functions или AWS Step Functions - для многоэтапных рабочих процессов с таймерами, повторными попытками и подтверждением человека. Оркестрация - их сильная сторона.
- Temporal — когда рабочий процесс длится долго (часы, дни), и необходимо первоклассное стабильное выполнение, версионирование и прозрачность между запусками.
Компромисс, как обычно, заключается в меньшем объёме операционной работы, но большей зависимости от поставщика и ценообразовании, которое необходимо тщательно оценить при росте нагрузки.
Источник: https://www.milanjovanovic.tech/blog/how-to-scale-long-running-api-requests6 705
День 2672. #Оффтоп
Построй Свой Собственный X
«Чего я не могу создать, того я не понимаю» - Ричард ФейнманОбнаружил интересный ресурс для тех, кто любит переизобретать велосипед. Хотя, не будем себя обманывать, все мы иногда нет-нет, да и да. Так вот, если вам когда-нибудь приходила в голову идея создать свою операционную систему, движок виртуальной машины, базу данных, докер, поисковый движок, 3D-рендерер, Git, командную строку или хотя бы Тетрис, этот ресурс для вас. Здесь собраны десятки (если не сотни) руководств по созданию известных нам всем вещей (в самом простом варианте, естественно) на самых разных языках программирования, в том числе на C#. Смысл, конечно, не в том, чтобы помочь вам написать новый Google и сказочно разбогатеть (хотя, кто знает). Смысл в том, чтобы объяснить, как это устроено, и в процессе научить вас создавать вещи. Единственный минус – всё на английском. https://build-your-own-x.vercel.app/
6 705
День 2671. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.
34. Лучшие практики RESTful-сервисов
«Давайте обсудим лучшие практики проектирования и реализации RESTful-сервисов в приложениях .NET. Приведите примеры того, как эти практики обеспечивают эффективные и поддерживаемые API-сервисы».
Хороший ответ
Разработка RESTful-сервисов требует соблюдения определённых принципов, обеспечивающих масштабируемость, удобство сопровождения и интуитивность этих сервисов. При реализации RESTful API в приложениях .NET можно следовать нескольким передовым практикам:
1. Правильное использование HTTP-методов: Каждый HTTP-метод (GET, POST, PUT, DELETE и т. д.) имеет определённое семантическое значение и должен использоваться в соответствии с представляемым действием. Например, GET следует использовать для получения данных, и он должен быть идемпотентным, то есть не изменять состояние сервера.
2. Именование ресурсов: Ресурсы должны быть названы логично и последовательно, как правило, с использованием существительных, представляющих сущности. Пути URI должны отражать иерархию ресурсов. Например:
GET /api/customers - получить список клиентов,
GET /api/customers/{id} - получить клиента по ID,
POST /api/customers - создать клиента,
PUT /api/customers/{id} - обновить данные клиента,
DELETE /api/customers/{id} - удалить данные клиента.
3. Без сохранения состояния: Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую серверу для понимания запроса, без использования какого-либо сохранённого контекста на сервере. Это делает API масштабируемым и упрощает управление при высокой нагрузке.
4. Правильное использование кодов состояния: HTTP предоставляет ряд кодов ответа, указывающих на успех или неудачу запросов. Правильное использование этих кодов, таких как 200 OK, 404 Not Found и 500 Internal Server Error, помогает клиенту корректно обрабатывать ответы.
5. Версионирование: По мере развития API версионирование становится критически важным для поддержания совместимости с существующими клиентами, позволяя при этом вносить улучшения и изменения. Этого можно достичь с помощью пути URI, строки запроса или пользовательских заголовков, например: /api/v1/customers, /api/v2/customers
6. Безопасность: Реализация аутентификации и авторизации, Обеспечение шифрования данных при передаче (HTTPS) является основополагающим принципом безопасности RESTful API.
7. Документация и гипермедиа: Хорошая документация имеет решающее значение для разработчиков, чтобы они могли понимать и эффективно использовать API. Использование гипермедиа (HATEOAS) может динамически направлять пользователей по операциям API.
Часто встречающийся неверный ответ
«Надо просто убедиться, что API работает хорошо и возвращает правильные данные. Конкретные HTTP-методы или коды состояния, которые вы используете, не так уж важны, главное, чтобы клиент получал то, что ему нужно».
Почему это неверно
- Недостаточное понимание принципов REST: ответ демонстрирует непонимание фундаментальных принципов REST, таких как важность использования правильных HTTP-методов и кодов состояния, которые определяют RESTful-сервисы.
- Недооценка лучших практик: ответ недооценивает важность лучших практик, таких как отсутствие состояния, именование ресурсов и безопасность, которые имеют решающее значение для масштабируемости, удобства сопровождения и безопасности API.
- Пренебрежение клиентским опытом: Несоблюдение RESTful-соглашений может привести к созданию API, который будет сложнее использовать и интегрировать для клиентов, что может повлиять на внедрение и удобство использования API.
Этот часто встречающийся неверный ответ может быть следствием недостаточного формального понимания веб-сервисов или опыта работы в средах, где приоритет отдавался быстрым результатам, а не соблюдению стандартов и лучших практик.
Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md6 705
День 2670. #ЧтоНовенького #NET11
Сжатие Zstandard в .NET 11
В .NET уже некоторое время существуют DeflateStream, GZipStream, ZLibStream и BrotliStream. В .NET 11 к ним присоединяется новый: ZstandardStream.
Zstandard (или Zstd) — это алгоритм сжатия от Facebook. Разработан для обеспечения коэффициента сжатия, сравнимого с алгоритмом DEFLATE, но более быстрого, особенно для декомпрессии. Он настраивается с уровнями сжатия от -7 (самый быстрый) до 22 (самый медленный по скорости сжатия, но с наилучшим коэффициентом сжатия). Zstd используется в ядре Linux, дампах памяти FreeBSD, AWS Redshift, менеджерах пакетов Fedora и ArchLinux, а также архивах игр Nintendo Switch.
Новый API
Дизайн соответствует существующему шаблону Brotli*, поэтому, если вы использовали BrotliStream или BrotliEncoder, он покажется вам знакомым.
В System.IO.Compression 4 основных новых типа:
- ZstandardStream — обёртка потока,
- ZstandardEncoder/ZstandardDecoder — кодировщик/декодировщик,
- ZstandardDictionary — для эффективного сжатия множества маленьких файлов,
- ZstandardCompressionOptions — настройки: качество, размер окна, контрольная сумма и т.п.
Простейший пример применения:
// сжатие
using var output = new MemoryStream();
using (var zstd =
new ZstandardStream(output, CompressionMode.Compress))
{
await inputStream.CopyToAsync(zstd);
}
// декомпрессия
using var zstd = new
ZstandardStream(compressedStream, CompressionMode.Decompress);
await zstd.CopyToAsync(outputStream);byte[] src = File.ReadAllBytes("data.bin");
// сжатие
int maxLen = ZstandardEncoder
.GetMaxCompressedLength(src.Length);
var compressed = new byte[maxLen];
ZstandardEncoder.TryCompress(src, compressed, out int bytesWritten);
// декомпрессия
int decompressedSize = ZstandardDecoder.GetMaxDecompressedLength(compressed.AsSpan(0, bytesWritten));
var decompressed = new byte[decompressedSize];
ZstandardDecoder.TryDecompress(compressed.AsSpan(0, bytesWritten), decompressed, out int bytesRead);var options = new ZstandardCompressionOptions
{
Quality = 6
};
using var zstd = new ZstandardStream(output, options);// Program.cs
builder.Services.AddResponseCompression(x =>
{
x.EnableForHttps = true;
x.Providers.Add<ZstandardCompressionProvider>();
});encoding: zstd. Распаковка запроса также осуществляется простым способом через IDecompressionProvider.
Сжатие по словарю
При сжатии большого количества небольших, похожих данных (ответы JSON API, сериализованные события, блоки конфигурации) общий словарь может улучшить коэффициент сжатия.
// обучаем словарь на примерах
byte[] allSamples = …; // примеры всех сжимаемых объектов
int[] lengths = …; // длина каждого примера
using ZstandardDictionary dict = ZstandardDictionary.TrainFromSamples(allSamples, lengths, maxDictionarySize: 100_000);
// Сжатие по словарю — обе стороны должны использовать один словарь
using var encoder = new ZstandardEncoder(dict);
encoder.Compress(payload, compressed, out int consumed, out int written, isFinalBlock: true);6 705
День 2669. #ЗаметкиНаПолях #Blazor
Создаём Базовый Компонент для Всех Компонентов в Blazor
При разработке Blazor-приложения может понадобиться пользовательский базовый компонент для всех остальных компонентов. Это полезно для совместного использования общих функций, таких как токены отмены, логирование или управление состоянием, во всех компонентах. Вместо добавления
@inherits YourBaseComponent в каждый файл Razor, вы можете использовать файл _Imports.razor для глобальной установки базового компонента.
Создадим файл _Imports.razor в папке, к компонентам которой нужно применить базовый компонент. Все файлы Razor в этой папке и её подпапках будут наследовать указанный базовый компонент.
@inherits YourNamespace.CustomComponentBase_Imports.razor обрабатывается перед любым компонентом Razor в том же каталоге или его подкаталогах. Все компоненты затем автоматически наследуют от CustomComponentBase без необходимости объявлять @inherits в каждом файле.
Пример: CustomComponentBase с CancellationToken
Вот пример базового компонента, который предоставляет CancellationToken всем производным компонентам. Это полезно для отмены асинхронных операций при удалении компонента:
@* CustomComponentBase.razor (Razor) *@
@implements IDisposable
@code {
private readonly CancellationTokenSource
_cts = new CancellationTokenSource();
public CancellationToken
CancellationToken => _cts.Token;
public void Dispose()
{
_cts.Cancel();
_cts.Dispose();
}
}@* MyComponent.razor (Razor) *@
@* Не нужно использовать @inherits, т.к. _Imports.razor импортируется автоматически *@
<h3>Мой компонент</h3>
@code {
protected override async Task OnInitializedAsync()
{
// Используем CancellationToken из базового компонента
await LoadDataAsync(CancellationToken);
}
private async Task LoadDataAsync(CancellationToken ct)
{
// … асинхронный код …
await Task.Delay(1000, ct);
}
}@* MyComponent.razor (Razor) *@
@inherits ComponentBase
@* Этот компонент будет использовать ComponentBase вместо CustomComponentBase *@_Imports.razor в разных папках, чтобы применять разные базовые компоненты к различным разделам приложения. Приоритет имеет ближайший файл _Imports.razor в иерархии каталогов. Например, /Components/_Imports.razor применяется ко всем компонентам в этой папке /Components/Admin/_Imports.razor применяется специально к компонентам папки Admin. Такой иерархический подход обеспечивает точный контроль над тем, какие компоненты наследуют от каких базовых классов.
Источник: https://www.meziantou.net/blazor-how-to-set-a-base-component-for-all-razor-components-using-viewstart-razo.htm6 705
День 2668. #ЧтоНовенького #NET11
Улучшения API процессов в .NET 11. Окончание
Обзор
Проблемы существующего API
Разбор новых методов
Управление жизненным циклом
Process.StartAndForget
Распространено заблуждение, что при очистке переменной процесса, процесс также завершается. Это не так, поскольку Process.Dispose только освобождает ресурсы, связанные с процессом, но не завершает его.
Чтобы упростить запуск процесса без необходимости беспокоиться о его завершении, добавлен метод Process.StartAndForget, который запускает процесс, возвращает его ID и освобождает все связанные с ним ресурсы.
int processId = Process.StartAndForget("notepad.exe");6 705
День 2667. #ЧтоНовенького #NET11
Улучшения API процессов в .NET 11. Продолжение
Обзор
Проблемы существующего API
Чтобы решить проблему, описанную в предыдущем посте, были добавлены несколько новых функций.
Process.ReadAllText и Process.ReadAllTextAsync
Одновременно обрабатывают стандартный вывод и ошибки, что помогает избежать взаимоблокировок. Они декодируют вывод, используя кодировку, указанную в ProcessStartInfo.Standard[Output/Error]Encoding (или кодировку по умолчанию, если она не указана), и возвращают результат в виде строки. Теперь код с чтением вывода и ошибок процесса стал намного проще:
ProcessStartInfo startInfo = new("dotnet", "--help")
{
RedirectStandardOutput = true,
RedirectStandardError = true
};
using Process p = new() { StartInfo = startInfo };
p.Start();
(string output, string error) = p.ReadAllText();
p.WaitForExit();ProcessTextOutput output =
Process.RunAndCaptureText("dotnet", ["--help"]);ProcessExitStatus status = Process.Run("dotnet", ["build", "-c", "Release"]);using Process p = Process.Start(…);
await foreach (var line in p.ReadAllLinesAsync())
{
if (line.StandardError)
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine(line.Content);
Console.ResetColor();
}6 705
День 2666. #ЧтоНовенького #NET11
Улучшения API процессов в .NET 11. Продолжение
Обзор
Перехват выходных данных процесса без взаимоблокировок
Почему захват выходных данных процесса может приводить к зависанию
При перенаправлении стандартного вывода (stdout) и ошибок (stderr) процесса возможны взаимоблокировки. Понимание причин этого крайне важно для понимания сути новинок. Создадим приложение, которое пытается прочитать все выходные данные и ошибки процесса.
Прежде всего, нужно перенаправить stdout и stderr, чтобы иметь возможность их прочитать. Это делается путём установки свойств RedirectStandardOutput и RedirectStandardError объекта ProcessStartInfo в true. Перед запуском процесса создаются два выделенных канала (для вывода и для ошибок). Дочерний процесс записывает данные в свои stdout и stderr, как обычно, но вместо вывода в консоль данные записываются в каналы.
ProcessStartInfo startInfo = new("dotnet", "--help")
{
RedirectStandardOutput = true,
RedirectStandardError = true
};
using Process p = new() { StartInfo = startInfo };p.Start();
p.WaitForExit();
var output = p.StandardOutput.ReadToEnd();
var error = p.StandardError.ReadToEnd();process.WaitForExit(); в конец тоже не помогает. ReadToEnd — блокирующий вызов: он читает до тех пор, пока поток не достигнет конца файла (EOF), что происходит только тогда, когда дочерний процесс закрывает свою часть канала (обычно при завершении). Поэтому в приведённом выше коде мы сначала блокируемся на stdout до завершения дочернего процесса, и только затем начинаем читать stderr. Если дочерний процесс записывает в stderr больше, чем может вместить буфер канала, он блокируется на своей записи — и мы застреваем во взаимоблокировке.
Причина в том, что мы читаем два потока последовательно, а не одновременно. Чтобы избежать этого, нужно одновременно очищать и стандартный вывод, и ошибку. До сих пор у нас было два варианта:
1. Использовать асинхронные операции чтения для StandardOutput и StandardError
p.Start();
var outTask = p.StandardOutput.ReadToEndAsync();
var errTask = process.StandardError.ReadToEndAsync();
await Task.WhenAll(outTask, errTask, p.WaitForExitAsync());
var output = await outTask;
var error = await errTask;StringBuilder stdOut = new(), stdErr = new();
p.OutputDataReceived += (sender, e) => stdOut.AppendLine(e.Data);
p.ErrorDataReceived += (sender, e) => stdErr.AppendLine(e.Data);
p.Start();
p.BeginOutputReadLine();
p.BeginErrorReadLine();
p.WaitForExit();6 705
День 2665. #ЧтоНовенького #NET11
Улучшения API процессов в .NET 11. Обзор
Класс System.Diagnostics.Process — это основной способ создания процессов и взаимодействия с ними в .NET. В .NET 11 в него внесли самое масштабное обновление за последние годы. Изменения добавляют высокоуровневые API, которые упрощают запуск процесса и перехват его вывода без взаимоблокировок, предоставляют полный контроль над наследованием дескрипторов и стандартным перенаправлением дескрипторов, вводят функции управления временем жизни, такие как KillOnParentExit, и включают в себя облегченный API на основе SafeProcessHandle, более удобный для оптимизации. В этой серии постов рассмотрим нововведения подробно.
Новые функции
1. Однострочник для выполнения процесса -
Process.RunAndCaptureText[Async]
Запускает процесс, перехватывает вывод/ошибку, ожидает завершения — всё за один вызов.
2. Выполнение без перехвата вывода - Process.Run[Async]
Запускает процесс и ожидает завершения без перехвата вывода.
3. Запустить и забыть - Process.StartAndForget
Запускает процесс, возвращает его PID и немедленно освобождает все ресурсы.
4. Перехват вывода без взаимоблокировок - Process.ReadAllText/Bytes/Lines[Async]
Читает stdout и stderr одновременно с использованием мультиплексирования, избегая взаимоблокировок буфера канала.
5. Перенаправление - ProcessStartInfo.Standard[Input/Output/Error]Handle
Перенаправляет стандартные дескрипторы на файлы, каналы, null или любой SafeFileHandle.
6. Контролируемое наследование - ProcessStartInfo.InheritedHandles
Точно указывает, какие дескрипторы наследуются дочерними процессами, предотвращая случайные утечки памяти.
7. Завершение при выходе родительского процесса - ProcessStartInfo.KillOnParentExit
Гарантирует завершение дочерних процессов при выходе родительского процесса (Windows и Linux).
8. Отсоединённые процессы - ProcessStartInfo.StartDetached
Запускает процесс, который сохраняется после выхода родительского процесса, сигнала или закрытия терминала.
9. Легковесный дескриптор процесса - SafeProcessHandle.Start/WaitForExit/Kill/Signal
Удобный для сокращения количества процессов низкоуровневый API для запуска и управления процессами без Process.
10. Подробная информация о завершении процесса - ProcessExitStatus
Сообщает код завершения, сигнал завершения (Unix) и был ли процесс завершён из-за тайм-аута/отмены.
11. Нулевой дескриптор - File.OpenNullHandle()
Открывает дескриптор, который отбрасывает операции записи и возвращает EOF при чтении.
12. Анонимные каналы - SafeFileHandle.CreateAnonymousPipe
Создаёт пару подключённых каналов с дополнительной поддержкой асинхронности.
13. Обработчики консоли - Console.OpenStandard[Input/Output/Error]Handle()
Получает базовый дескриптор операционной системы для стандартных потоков.
14. Определение типа дескриптора - SafeFileHandle.Type
Определяет, является ли дескриптор файлом, каналом, сокетом и т. д.
Далее рассмотрим новые функции подробнее.
Продолжение следует…
Источник: https://devblogs.microsoft.com/dotnet/process-api-improvements-in-dotnet-11/6 705
День 2664. #ЗаметкиНаПолях #DDD
Что Такое Инварианты? Окончание
Начало
Модель как источник истины
Три шага к цели
1. Запрет создания недействительных объектов
Курс без названия не должен существовать — делаем это невозможным:
public class Course
{
private Course(CourseId id, string title, Money price)
{
Id = id;
Title = title;
Price = price;
Status = CourseStatus.Draft;
}
public static Result<Course>
Create(string title, Money price)
{
if (string.IsNullOrWhiteSpace(title))
return CourseErrors.TitleRequired;
return new Course(CourseId.New(), title, price);
}public Result Publish(IDateTimeProvider clock)
{
if (Status != CourseStatus.Draft)
return CourseErrors.AlreadyPublished;
if (_lessons.Count == 0)
return CourseErrors.CannotPublishWithoutLessons;
Status = CourseStatus.Published;
PublishedOn = clock.UtcNow;
return Result.Success();
}public class Course
{
private readonly List<Lesson> _lessons = [];
public IReadOnlyCollection<Lesson>
Lessons => _lessons.AsReadOnly();
public Result RemoveLesson(LessonId id)
{
if (Status == CourseStatus.Published)
return CourseErrors.CannotModifyPublishedLessons;
var lesson = _lessons.FirstOrDefault(l => l.Id == id);
if (lesson is null)
return CourseErrors.LessonNotFound;
_lessons.Remove(lesson);
return Result.Success();
}
}6 705
День 2663. #ЗаметкиНаПолях #DDD
Что Такое Инварианты? Начало
Во многих «DDD-подобных» кодовых базах .NET бизнес правила разбросаны по обработчикам, валидаторам и контроллерам, и почти не затрагивают саму доменную модель. Каждая копия одного и того же правила со временем немного меняется, и валидность данного объекта начинает зависеть от того, каким путём вызывающий код к нему добрался. Вы, безусловно, можете построить работающую систему таким образом. Но есть более чистый способ, и он начинается с одной идеи.
Что такое инвариант?
Инвариант — это правило об объекте, которое должно оставаться верным до тех пор, пока объект существует.
Не только когда вы его сохраняете или когда запускается валидатор. Правило должно оставаться верным каждый раз, когда вы обращаетесь к объекту, независимо от того, как он попал в память.
Несколько примеров:
- У курса всегда есть непустое название.
- Итоговая сумма заказа всегда равна сумме стоимостей позиций в нём.
- Подписка находится ровно в одном состоянии: пробная, активная, истекшая или отменённая.
Ни в одном из этих случаев не упоминаются валидация, сохранение данных или HTTP. Это утверждения о предметной области, и они должны быть истинными независимо от способа загрузки объекта.
Где процедурный код дает сбои
Возьмём простой курс, написанный так, как это до сих пор делают большинство CRUD-подобных .NET-приложений:
public class Course
{
public string Title { get; set; }
public CourseStatus Status { get; set; }
public DateTime? PublishedOn { get; set; }
public decimal Price { get; set; }
}if (course.Title is null), не нужно вызывать валидатор и не нужно надеяться, что обработчик до вас выполнил правильную проверку.
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/what-invariants-are-and-why-a-domain-model-is-the-best-place-to-enforce-them