День 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);

Если не требуется потоковая обработка, есть API проще:

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);

Уровни качества
Zstd имеет диапазон качества от ZSTD_minCLevel() (который может быть отрицательным для сверхбыстрых режимов) до 22, по умолчанию 3. CompressionLevel.Fastest - минимальное значение, CompressionLevel.SmallestSize — 22.

var options = new ZstandardCompressionOptions
{
  Quality = 6
};

using var zstd = new ZstandardStream(output, options);

Использование в ASP.NET Core

// Program.cs
builder.Services.AddResponseCompression(x =>
{
  x.EnableForHttps = true;
  x.Providers.Add<ZstandardCompressionProvider>();
});

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);

Храните словарь в месте, доступном как производителю, так и потребителю. Рекомендуемый размер — до 100 КБ, обучение проводится на репрезентативных данных, размер которых примерно в 100 раз превышает размер сжимаемых данных.

Источник: https://steven-giesel.com/blogPost/6066abb6-640a-4225-ac33-3f4d5a1a1d16/zstandard-compression-in-net-11

День 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.md

День 2672. #Оффтоп
Построй Свой Собственный X

«Чего я не могу создать, того я не понимаю»
- Ричард Фейнман

Обнаружил интересный ресурс для тех, кто любит переизобретать велосипед. Хотя, не будем себя обманывать, все мы иногда нет-нет, да и да. Так вот, если вам когда-нибудь приходила в голову идея создать свою операционную систему, движок виртуальной машины, базу данных, докер, поисковый движок, 3D-рендерер, Git, командную строку или хотя бы Тетрис, этот ресурс для вас.

Здесь собраны десятки (если не сотни) руководств по созданию известных нам всем вещей (в самом простом варианте, естественно) на самых разных языках программирования, в том числе на C#. Смысл, конечно, не в том, чтобы помочь вам написать новый Google и сказочно разбогатеть (хотя, кто знает). Смысл в том, чтобы объяснить, как это устроено, и в процессе научить вас создавать вещи.

Единственный минус – всё на английском.

https://build-your-own-x.vercel.app/

День 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-requests

День 2674. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 10

10. pg_qualstats (Статистика Предикатов Запросов)
Что даёт: статистику, какие условия WHERE больше всего выиграют от индексов.

Зачем нужен
Создание индексов — это гадание на кофейной гуще без данных. Какие столбцы на самом деле запрашиваются чаще всего? Какие предикаты больше всего нагружают базу? pg_qualstats отслеживает использование условий WHERE во всех запросах, точно показывая, какие индексы окажут максимальное влияние.

Установка
1. Устанавливаем расширение

CREATE EXTENSION pg_qualstats;

2. Добавляем в postgresql.conf

shared_preload_libraries = 'pg_stat_statements,pg_qualstats'
pg_qualstats.enabled = on
pg_qualstats.track_constants = on

3. Перезапускаем PostgreSQL.

Использование
После работы производственной базы (часы/дни), выполняем запрос на поиск наиболее используемых предикатов:

SELECT 
  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;

Вывод: предложения в порядке значимости
1. orders(customer_id) – 450 тыс раз, фильтрует 99.9% строк
2. orders(order_date) - 234 тыс раз, фильтрует 95% строк
3. orders(status) - 123 тыс раз, фильтрует 80% строк

Когда использовать
- Большая БД с неясными потребностями в индексировании;
- Необходимы обоснованные решения по индексам;
- Кампания по оптимизации индексов.

Когда отказаться
- Небольшая БД (достаточно ручного анализа);
- Индексы уже хорошо оптимизированы;
- Не используете PostgreSQL.

Скрытая функция
Выявление неиспользуемых индексов (противоположный вариант использования). Объедините pg_qualstats с pg_stat_user_indexes, чтобы найти индексы, которые можно удалить.

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;

Вывод: индексы, занимающие место, но не используемые, которые можно удалить.

С осторожностью
Настройки по умолчанию могут вызывать накладные расходы в размере 5-10% при очень высокой частоте запросов в секунду. Решение: снижение накладных расходов путём выборки. В postgresql.conf:

# Отслеживаем 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);

Если tracking_ratio > 0.1 на частых запросах, уменьшите sample_rate.

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

День 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-10

День 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" }
};

Теперь токены, выданные этому клиенту, будут представлять собой непрозрачные дескрипторы вместо самодостаточных JWT.

Настройка API для интроспекции
Ваш API должен знать, как проверять эти непрозрачные токены. Вместо (или в дополнение к) проверке JWT настроим интроспекцию OAuth 2.0. Сначала определите ресурс API с секретом, который API будет использовать для аутентификации с конечной точкой интроспекции:

new ApiResource("banking_api")
{
  Scopes = { "accounts.read", "transfers.write" },
  ApiSecrets = { new Secret("api_secret".Sha256()) }
};

Затем в Program.cs вашего API зарегистрируйте обработчик интроспекции. Обратите внимание, что обработчик должен использовать ту же схему аутентификации, что и та, которую вы хотите использовать для интроспекции:

builder.Services.AddAuthentication("token")
 .AddOAuth2Introspection("token", opts =>
 {
   opts.Authority = "https://identity.banking.example.com";
   opts.ClientId = "banking_api";
   opts.ClientSecret = "api_secret";
 });

Если вам необходимо поддерживать как JWT, так и референтные токены (например, во время миграции), вы можете зарегистрировать обработчики обоих типов и использовать переадресацию для направления токенов к нужному обработчику:

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";
  });

Отзыв токена
Теперь ваша система поддержки (или автоматизированный конвейер обнаружения угроз) сможет немедленно отозвать токен, используя конечную точку отзыва IdentityServer, которая реализует RFC 7009:

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);

После отзыва токен удаляется из хранилища предоставленных прав IdentityServer. Следующий запрос на проверку подлинности от любого API подтвердит, что токен больше не активен.

Не забывайте: вы также можете (и должны) отозвать токен обновления пользователя, чтобы предотвратить незаметное получение клиентом нового токена доступа:

await client.RevokeTokenAsync(
 new TokenRevocationRequest
 {
   Address = "https://identity.banking.example.com/connect/revocation",
   ClientId = "banking_app",
   ClientSecret = "secret",
   Token = refreshToken
 });

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

Источник: https://duendesoftware.com/blog/20260428-the-emergency-stop-button-implementing-immediate-token-revocation-in-dotnet-10

День 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

День 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

День 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();
  }
}

В этом методе есть три побочных эффекта, скрытых за, казалось бы, единой транзакционной границей, без какой-либо координации между ними.

Если SaveChangesAsync вызывает исключение после успешного выполнения ChargeAsync, вы списали деньги клиента и потеряли заказ. Если SendOrderConfirmationAsync вызывает исключение, заказ сохраняется, и платёж проходит, но email не отправляется. А если вы попытаетесь повторить попытку, вы спишете деньги дважды. Этот вариант использования «работает», пока не ломается, а когда ломается, он, как правило, каждый раз завершается с разной ошибкой.

Три категории побочных эффектов
Прежде чем написать хотя бы одну строку кода восстановления, классифицируйте каждый побочный эффект по одной из 3 категорий:

- Транзакционные — находятся внутри транзакции вашей БД. Вставки, обновления, события домена, отправляемые в процессе.
- Внешние и обратимые — вызов API, который вы можете компенсировать. Платёж → возврат. Резервирование запасов → освобождение.
- Внешние и необратимые — отправленные email, веб-хуки, SMS-сообщения. Как только они отправлены, их не вернуть.

Категория определяет стратегию. Не существует единого правила «правильной обработки ошибок», которое охватывало бы все три.

Окончание следует…

Источник: https://www.milanjovanovic.tech/blog/when-your-use-case-half-succeeds-designing-for-partial-failure-in-dotnet

День 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();

Не всегда это возможно, и это нормально. Суть в том, чтобы убедиться, что если вы выполняете операцию подтверждения, то уже сделали всё, что обещает эта операция.

2. Выносим необратимые побочных эффекты за пределы
Здесь применяется паттерн Outbox. Вместо прямой отправки email, сгенерируйте событие домена OrderPlaced и позвольте диспетчеру исходящих сообщений обработать его после подтверждения транзакции:

// …
orders.Insert(order);
order.Raise(new OrderPlacedEvent(order.Id));
await unitOfWork.SaveChangesAsync(ct);
// …

Отправка email больше не забота этого метода. Если транзакция подтверждена, событие подтверждается вместе с ней в рамках той же операции записи. Если нет, событие никогда не покидает БД, и email никогда не отправится. Отдельный обработчик преобразует события в emailы, используя собственные повторные попытки и собственные гарантии идемпотентности.

3. Делаем внешние вызовы идемпотентными или компенсируемыми
Если вызов платежа успешен, а транзакция отменена, мы взяли лишние деньги. Точно нельзя молчаливо мириться с неудачей.

Подход А: Ключи идемпотентности
Большинство платежных систем позволяют прикрепить ключ идемпотентности к платежу. Повторная попытка с тем же ключом возвращает исходный результат. Естественный ключ - ID заказа:

var charge = await payments.ChargeAsync(
 new ChargeRequest
 {
   OrderId = order.Id,
   Amount = order.Total,
   IdempotencyKey = order.Id.ToString()
 },
 ct);

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

Подход B: Возврат через событие домена
Если повторить операцию нельзя — пользователь отказался от попытки, запрос отменён или ошибка является необратимой, деньги реальны и должны быть возвращены. Сделаем ошибку событием и вернём средства:

// …
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;
}
// …

Фоновый потребитель подписывается на событие PaymentFailedEvent и инициирует возврат средств, используя идентификатор транзакции в качестве ключа идемпотентности. Это превращает сложную межпроцессную компенсацию в обычный, наблюдаемый, повторяемый обработчик сообщений.

Паттерн Сага
Описанные выше стратегии работают, когда один вариант использования координирует небольшое количество побочных эффектов в одном сервисе. Как только работа охватывает несколько сервисов и должна сохраняться после перезапуска процесса, лучше использовать паттерн Сага.
Простое правило: если вы можете уместить логику восстановления в своей голове, достаточно хорошо разработанного варианта использования. Если нет, используйте паттерн Сага.

Источник: https://www.milanjovanovic.tech/blog/when-your-use-case-half-succeeds-designing-for-partial-failure-in-dotnet

День 2681. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 11

11. Советник в AWS Redshift
Что даёт: рекомендации по оптимизации, специфичные для Redshift.
Тип: Встроенный сервис AWS
Стоимость: Бесплатно (входит в Redshift)

Зачем нужен
Redshift предъявляет уникальные требования к оптимизации: ключи распределения, ключи сортировки, сжатие. Советник анализирует шаблоны запросов и рекомендует оптимизации.

Использование
Панель управления AWS: Redshift → Advisor recommendations
Либо CLI:

aws redshift describe-cluster-recommendations \
  --cluster-identifier my-cluster

Либо SQL:

SELECT * FROM svv_redshift_advisor_recommendations;

Примеры рекомендаций
1. Добавить сжатие
Таблица: orders
Колонка: customer_notes (VARCHAR)
Текущее: Нет
Рекомендованное: LZO
Влияние: экономия места 65%
Планируемая экономия: $450/мес
Сгенерированный SQL:

ALTER TABLE orders 
ALTER COLUMN customer_notes ENCODE LZO;

2. Ключ Сортировки
Таблица: orders
Текущий: Нет
Рекомендованный: (order_date, customer_id)
Причина: 87% запросов фильтруют/сортируют по order_date
Влияние: ускорение запросов на 40%
Планируемое улучшение: сокращение времени запросов на 2.3 часа в день
Сгенерированный SQL:

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;

3. Ключ распределения
Таблица: order_items
Текущий: DISTSTYLE EVEN
Рекомендованный: DISTKEY (order_id)
Причина: Частые объединения с orders по order_id
Влияние: Ускорение объединений в 3 раза
Сгенерированный SQL:

CREATE TABLE order_items_new (LIKE order_items)
DISTKEY (order_id);
INSERT INTO order_items_new SELECT * FROM order_items;
-- …

4. Обслуживание таблицы
Таблица: customers
Проблема: Замечено разбухание таблицы (75% данных на 2 узлах)
Действие: Требуются VACUUM и ANALYZE
Влияние: Улучшение производительности запросов
Сгенерированный SQL:

VACUUM SORT ONLY customers;
ANALYZE customers;

Когда использовать
- Используете AWS Redshift;
- Хотите оптимизацию специально для Redshift;
- Неясно, какие оптимизации лучше;
- Необходимо обосновать затраты на инфраструктуру (показать потенциал оптимизации).

Когда отказаться
- Не используете Redshift;
- Невозможность выполнить рекомендации (требуют перестроения таблиц).

Скрытая функция
Рекомендации по очереди запросов.
Рекомендация: Управление рабочей нагрузкой (WLM)
Текущая конфигурация: по умолчанию (1 очередь, все запросы имеют одинаковый приоритет).
Обнаруженные закономерности:
- Короткие запросы (<1 с): 85%.
- Средние запросы (1–60с): 10%.
- Длинные запросы (>60 с): 5%.
Рекомендуемая модификация WLM:
Очередь 1 (короткие): 40% памяти, параллелизм 15.
Фильтр: query_execution_time < 1с.
Очередь 2 (средняя): 40% памяти, параллелизм 5.
Фильтр: query_execution_time 1–60с.
Очередь 3 (длинная): 20% памяти, параллелизм 2.
Фильтр: query_execution_time > 60с.
Влияние:
- Короткие запросы не будут ждать длинных.
- Общее увеличение пропускной способности в 3 раза
- Снижение задержки p95: 80%

С осторожностью
Некоторые рекомендации требуют пересоздания таблиц. Изменение DISTKEY или SORTKEY требует перестроения таблицы. В таблице размером 1 ТБ это может занять несколько часов и заблокировать запись.
Более безопасный подход: использовать окно обслуживания. Назначаем на время с наименьшей нагрузкой. Сначала тестируем в среде разработки.

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;

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

День 2682. #МоиИнструменты #Copilot
Как Эффективнее Использовать GitHub Copilot. Начало
Для большинства разработчиков важно использовать подходящие функции Copilot для тех задач, которые уже стоят перед вами. Наибольший прогресс обычно проявляется, когда вы начинаете использовать чат для поиска ответов и агента для выполнения задач. Visual Studio, Visual Studio Code, Copilot CLI и облачный агент — каждый инструмент отлично подходит для разных типов задач. Вопрос не в том, какой из них «самый продвинутый», а в том, какой из них подходит для работы, которую я выполняю прямо сейчас?
 
Реальные примеры использования чата
Чат полезен, когда требуется объяснение, сравнение, планирование или целевая генерация кода на основе вашего реального проекта.
 
Пример 1: Понимание сервиса перед его изменением в VS
Предположим, вы открываете существующий сервис ASP.NET Core и обнаруживаете класс с пятью зависимостями, несколькими флагами функций и бизнес-правилами, скрытыми в длинном методе. Прежде чем его изменять, используйте чат, чтобы сориентироваться.
Промпт:

Объясни, за что отвечает сервис, определи ключевые зависимости и укажи, какие части относятся к бизнес-логике, а какие — к инфраструктурным задачам. Затем предложи безопасный первичный рефакторинг, который не изменит поведение.

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

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

Бонус: в VS, используйте Test Agent. В VS Code или CLI, используйте dotnet-test skill для достижения наилучших результатов. Это важный сценарий использования, поскольку нужны и результаты, и объяснение.
 
Пример 3: Планирование рефакторинга до изменения кода
Допустим, в контроллере слишком много логики, и вы хотите перенести проверку и оркестровку в сервис. Чат полезен перед редактированием.
Промпт:

Просмотри это действие контроллера и предложи рефакторинг, который перенесёт оркестровку в сервис без изменения HTTP-контракта. Покажи итоговую структуру контроллера, интерфейс сервиса и модульные тесты, которые нужно обновить.

Перед этим войдите в режим планирования, и Copilot создаст подробный план. Это хорошо работает в VS, т.к. вы уже видите соответствующие файлы и структуру решения.
 
Пример 4: Использование VS Code, когда изменение затрагивает код и конфигурацию
Распространённый сценарий в .NET — изменение API, описания OpenAPI, файла развёртывания и документации за один проход. Здесь поможет VS Code.
Промпт:

Я добавляю новый необязательный фильтр регионов к этой конечной точке. Обнови обработчик ASP.NET Core, скорректируй описание OpenAPI и найди любые конфигурации, документацию или клиентский код, которые также могут потребовать изменений.

Здесь чат начинает восприниматься не как автозаполнение, а как коллега по работе. Он может помочь вам мыслить в масштабах всего репозитория, а не только файла перед вами.
 
Пример 5: Copilot CLI для анализа ошибки сборки
Если dotnet test или dotnet build завершаются с ошибкой, CLI — естественное место для работы, поскольку ошибка уже отображается в терминале.
Промпт:

Объясни эту ошибку сборки простым языком, укажи, какой проект её вызвал, и предложи команды, которые я должен выполнить, чтобы сузить круг поиска.

Это лучше, чем копировать сообщение об ошибке в поисковую систему, потому что в CLI есть контекст вашего репозитория и цикла команд.
 
Окончание следует…
 
Источник: https://devblogs.microsoft.com/dotnet/doing-more-with-github-copilot/