День 2199.
Сегодня порекомендую вам интервью, которое взял Ник Чапсас у одного из разработчиков языка C#, Мэдса Торгенсена.

Какие новинки готовит нам C#14? Что случилось с типами-расширениями? Почему в первичные конструкторы не добавили readonly параметры? Когда уже появятся дискриминируемые объединения в C#? И вообще, как команда языка определяет, какие новые функции добавлять в язык и как это делать?

А в конце беседы Мэдс рассказывает, какие функции языка он ненавидит и с радостью убрал бы.

Ко вчерашнему квизу про var. В компиляторе огромное количество логики, которая определяет правильность использования ключевых слов. И в этом конкретном случае var в начале объявления переменной будет рассматриваться как тип, если он существует. А второе слово в объявлении будет именем переменной. И такой код будет прекрасно компилироваться и работать. Более того, Мэдс рассказал, что так в отдельных командах ненавистники ключевого слова var запрещали его использование. Просто создавали пустой класс var, и тогда любое использование var в объявлении приводило к созданию экземпляра этого класса. Таким образом, приходилось отказываться от var и явно объявлять тип переменной.

https://youtu.be/T9UqIkuGnuo

День 2200. #ЗадачиНаСобеседовании
Код Ревью
Давно не было темы задач на собеседовании (если что, другие посты смотрите по тегу выше). А вот эта показалась интересной. Не буду говорить, откуда. Кто знает, тот знает. Ну и, надеюсь, не раскрою никакой тайны, вроде NDA не подписывал 😊

Итак, вам на ревью прислали вот такой код. А картинкой – это чтоб интереснее было, а то знаю я вас, сразу скопируете и в какой-нибудь жпт запихнёте))). Проверьте код и дайте фидбек. Всё, что вы сможете найти, насколько бы мелким и незначительным на фоне остального это ни казалось. Единственное замечание – мы исходим из того, что код компилируется и вообще проект успешно собирается, то есть все необходимые юзинги на месте, хоть их здесь и нет.

Удачи, жду ревью в комментариях.

День 2201. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.

1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.

Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.

Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.

2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.

Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.

Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.

Продолжение следует…

Источник: https://youtu.be/-6KHhwEMtqs

День 2202. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение
Начало

3. Фокус на процессе вместо результатов
Наша цель — поставить пользователям хорошее работающее ПО и постоянно поддерживать способность делать это. Не имеет значения, сколько историй мы поставляем в спринте, если они не представляют ценности для пользователей. Насколько хорошо наше тестовое покрытие не имеет значения, если у нас всё ещё много ошибок, которые мешают пользователям использовать ПО. Тот факт, что каждая функция имеет аккуратные комментарии, не имеет значения, если наш код все ещё трудно изменять.

Красный флаг
Команды, оцениваемые по тому, сколько стори-пойнтов они поставляют, если при этом никто не проверяет, действительно ли эти функции приносят пользу пользователям.

Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.

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

Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.

Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.

5. Моральный дух команд разработчиков
Если команды разработчиков думают, что их система плохая, они обычно правы. Те, кто производит отличное ПО, как правило, знают, что они преуспевают, поэтому если моральный дух команды низкий, это должно быть большим предупреждающим знаком того, что что-то фундаментально не так.

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

Что делать?
Повысить автономность. Мастерство и чётко обозначенная цель позволяют командам принимать ключевые решения, поощрять обучение и гарантировать, что все знают, почему работа, которую они делают, действительно важна.

6. Зависимость от героев
Если судьба проекта зависит от разработчиков-«рок звёзд», это очень серьезный предупреждающий знак.

Красный флаг
Один человек, который является единственным, кто может исправить или понять определённые области кода или определённые практики.

Что делать?
Распространять эти знания. Это можно делать это с помощью таких методов, как парное или групповое программирование, обзоры кода, митапы и т.п.

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

Источник: https://youtu.be/-6KHhwEMtqs

День 2203. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Окончание
Начало
Продолжение

7. Низкие баллы по метрикам DORA
Метрики DevOps Research and Assessment (DORA) измеряют стабильность и пропускную способность, т.е. качество ПО, которое мы производим, и эффективность, с которой мы можем создавать ПО такого качества. Если у вас низкие баллы по обоим метрикам, то вы поставляете некачественное ПО и делаете это медленно. Это почти гарантированный путь к провалу.

Красные флаги
- низкая частота развертывания,
- большие сроки выполнения,
- высокая частота отказов,
- большое время восстановления после сбоев.

Что делать?
Начать внедрять такие методы, как непрерывная интеграция, автоматизированное тестирование, частые релизы и быстрые откаты или исправления для повышения скорости и качества циклов обратной связи и раннего обнаружения проблем.

8. Достижение прогресса большими шагами
Большие многомесячные планы уменьшают ваши возможности учиться и адаптироваться. Лучшая альтернатива – рассматривать разработку как постоянный цикл экспериментов и открытий, а не пытаться найти и затем воплотить в каком-то плане то, что, по вашему мнению, является лучшими идеями. Гораздо эффективнее предположить, что ваши идеи в начале проекта неправильны, поэтому продумайте, что делать, если ваши идеи потерпят неудачу. Также создавайте системы так, чтобы их было легко изменить, чтобы вы могли исправить ошибки, когда вы их обнаружите.

Красный флаг
Обычно виден как функции, запланированные далеко на будущее и не выпущенные или не протестированные в течение месяцев или лет.

Что делать?
Работать небольшими итерациями. Выпускать чаще и получать быструю обратную связь от реальных пользователей. Если вы обнаружите, что ваша команда работает над подробными планами работы, которая будет выполнена через несколько месяцев, или функциями, которые не будут выпущены в течение недель, месяцев или даже лет, это большой предупреждающий знак. Выясните, как оптимизировать ваш процесс разработки, чтобы вы могли выпускать функциональность в любое время. Быстрая обратная связь и другие методы непрерывной доставки, позволяют работать более размеренно, развивая ПО пошагово. Это даёт больше возможностей для обучения и корректировки курса, когда мы обнаруживаем ошибку.

9. Плохая или отсутствующая обратная связь
Хорошие короткие циклы обратной связи позволяют направлять наши проекты к успеху. Если мы не знаем, работают ли наши новые функции для пользователей, то мы двигаемся вслепую.

Красные флаги
- Редкая или отсутствующая обратная связь от пользователей.
- Отсутствие автоматизированных проверок.

Что делать?
Сократить циклы обратной связи на каждом уровне. Автоматизированная сборка обратной связи от пользователей, непрерывная интеграция и частые выпуски - всё это инструменты, которые помогают нам достичь этого.

10. Разработка неправильной вещи
Это может показаться очевидной ошибкой, которую никто никогда не сделает, но на самом деле это чрезвычайно распространено. В своём исследовании Microsoft обнаружили, что 2/3 их идей дали нулевой или отрицательный выхлоп. Оценки того, как часто функции, которые мы производим как отрасль, вообще никогда не используются, варьируются от 40 до 90%. Поэтому создание неправильных вещей, по крайней мере, так же, а то и более распространено, чем создание вещей, которые люди хотят.

Красные флаги
- Отсутствие пользователей и обратной связи.
- Отсутствие отчётов об ошибках, хотя мы знаем, что наше ПО работает неверно.

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

Источник: https://youtu.be/-6KHhwEMtqs

День 2204. #ЧтоНовенького
Новинки в Visual Studio 2022
Несколько новинок было представлено в VS 2022 с начала года.

1. Настройка сообщений коммита, сгенерированных ИИ
VS уже какое-то время назад представила автоматическую генерацию сообщений коммита с помощью ИИ, описывая сделанные вами изменения. У меня нет большого опыта её использования, но несколько раз пробовал, и получается довольно неплохо (по крайней мере, по-английски). Нынешняя новинка позволяет вам легко адаптировать сообщения о коммитах в соответствии с вашим рабочим процессом и стандартами команды: указать количество и длину строк, стиль сообщения и т.п. Copilot понимает такие термины, как «тема», «тело» и «нижний колонтитул». Например (буду использовать примеры по-английски, т.к. на русском не пробовал):
Use all lowercase
Limit subject to 50 characters
Limit body to 2 sentences
Add a footer with three hash marks
Follow Conventional Commits standard

Чтобы это настроить, перейдите в Tools > Options > GitHub > Copilot (Инструменты > Параметры > GitHub > Copilot) и введите нужные параметры.

2. Настройка индикаторов свёрнутого текста
Теперь вы можете персонализировать цвет и фон индикатора свёрнутого текста в редакторе, установив пользовательские цвета для индикаторов свёрнутого и развёрнутого текста в отдельности. Эта функция доступна через меню Tools > Options > Environment > Fonts and Colors (Инструменты > Параметры > Среда > Шрифты и цвета).

Две новые записи в списке настроек редактора тестов, которые управляют цветом индикатора свернутого текста:
- Collapsed Text Indicator (Collapsed)
- Collapsed Text Indicator (Expanded)
(Индикатор свёрнутого текста (свёрнутый)
Индикатор свёрнутого текста (развёрнутый))
Цвета индикаторов и фона индикаторов можно устанавливать независимо друг от друга.

3. Сохранение шрифта при смене темы
Последнее обновление в VS 2022 позволяет переключать темы, не влияя на настройки шрифтов. Эта функция сохраняет выбранный шрифт и размер независимо от выбранной темы, в то время как цвета шрифтов продолжают адаптироваться к теме. Перейдите в Tools > Options > Environment > Manage Preview Features и найдите настройку Separate font settings from color theme selection (Отделить настройки шрифтов от выбора цветовой темы). Снятие этого флажка привяжет ваш шрифт напрямую к теме.

Источники:
- https://devblogs.microsoft.com/visualstudio/customize-your-ai-generated-git-commit-messages/
- https://devblogs.microsoft.com/visualstudio/customizing-collapsed-text-indicators/
- https://devblogs.microsoft.com/visualstudio/your-fonts-are-now-preserved-when-changing-theme/

День 2205. #Testing
Нагрузочное Тестирование с Помощью K6 в Windows. Начало
Понимание того, как ваша система реагирует на входящий сетевой трафик, имеет решающее значение для определения ее стабильности, способности соответствовать ожидаемому SLO и исправности базовой инфраструктуры и архитектуры. Рассмотрим, как использовать K6 для запуска нагрузочных тестов и локального отображения конечного результата.

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

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

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

Демо проект
Создадим простой проект .NET API. Одна конечная точка, /randombook, которая возвращает информацию о случайной книге, хранящейся в БД в памяти:

int requests = 0;
int concurrency = 0;
object _lock = new();
app.MapGet("/randombook", async (CancellationToken ct) =>
{
  Book? book = default;
  var delayMs = Random.Shared.Next(10, 10000);
  try
  {
    lock (_lock)
    {
      requests++;
      concurrency++;
      app.Logger.LogInformation(
        @"Request {Count}.
        Concurrent Executions {Executions}.
        Delay: {DelayMs}ms",
        requests, concurrency, delayMs);
    }

    using var ctx = new ApiContext();
    await Task.Delay(delayMs, ct);
    if (ct.IsCancellationRequested)
    {
      app.Logger.LogWarning("Cancelled");
      throw new OperationCanceledException();
    }
    var books = await ctx.Books.ToArrayAsync();
    book = Random.Shared
     .GetItems(books, 1).First();
  }
  catch (Exception ex)
  {
    app.Logger.LogError(ex, "Error ");
    return Results.Problem(ex.Message);
  }
  finally
  {
    lock (_lock)
    {
      concurrency--;
    }
  }

  return TypedResults.Ok(book);
});

Здесь добавлены:
- случайная задержка delayMs, эмулирующая запрос из БД;
- потокобезопасный счётчик параллельных операций concurrency;
- логирование сообщений внутри lock для избежания проблем параллелизма.
Это, конечно, не идеальное решение, но оно подойдёт для демонстрации.

Далее посмотрим, как провести нагрузочное тестирование этого API.

Продолжение следует…

Источник: https://www.code4it.dev/blog/k6-load-testing/

День 2206. #ЗаметкиНаПолях #Testing
Нагрузочное Тестирование с Помощью K6 в Windows. Продолжение
Начало

Запуск K6 в Windows
С помощью K6 вы можете запустить нагрузочные тесты, определив конечную точку для вызова, количество запросов в минуту и некоторые другие настройки.

Этот бесплатный инструмент можно установить с помощью Winget:

winget install k6 --source winget

Проверить правильность установки можно через командную строку (не Powershell):

k6 --version

Теперь можно инициализировать инструмент:

k6 new

Команда сгенерирует файл script.js, в котором надо будет настроить конфигурацию тестов. Например:

import http from "k6/http"
import { sleep } from "k6"

export const options = {
  vus: 10,
  duration: "30s",
}

export default function () {
  http.get("https://localhost:7123/randombook")
  sleep(1)
}

Здесь:
- vus: 10 - виртуальные пользователи, симулирующие параллельные входящие запросы;
- duration: "30s" – общее время теста;
- http.get("https://…") - основная функция, вызывающая конечную точку и считающая ответы, метрики, тайминг и т.п.;
- sleep(1) – время паузы между итерациями.

То есть, в течение 30 секунд k6 будет посылать до 10 параллельных запросов, потом ждать 1 секунду, и повторять. После он истечения времени теста, он даст ещё 30 секунд приложению, чтобы завершить текущие запросы.

Для запуска убедитесь, что API запущен, и выполните следующую команду:

k6 run script.js

В консоли API мы увидим логи запросов:

[15:19:51 INF] Request 1. Concurrent Executions 1. Delay: 7124ms
[15:20:02 INF] Request 2. Concurrent Executions 1. Delay: 4981ms
…
[15:20:27 INF] Request 57. Concurrent Executions 10. Delay: 7655ms

А в консоли k6 отчёт вроде представленного на рисунке выше.

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

Источник: https://www.code4it.dev/blog/k6-load-testing/

День 2207. #ЗаметкиНаПолях #Testing
Нагрузочное Тестирование с Помощью K6 в Windows. Окончание
Начало
Продолжение

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

set K6_WEB_DASHBOARD=true
set K6_WEB_DASHBOARD_EXPORT=html-report.html
k6 run script.js

В отчёте множество значений, названия которых в основном говорят сами за себя:
- data_received и data_sent - размер отправленных и полученных данных;
- продолжительность и ответы HTTP-запросов (http_req_duration, http_req_sending, http_reqs);
- информация о фазах HTTP-соединения, например http_req_tls_handshaking;
- конфигурации K6 (iterations, vus и vus_max).
Вы можете увидеть среднее значение, минимальное и максимальное значение, а также некоторые процентили для большинства значений.

Прочие настройки нагрузочного тестирования
В официальной документации K6 есть много информации, поэтому рассмотрим лишь некоторые основные настройки.

HTTP-методы
Мы использовали только метод GET, но можно использовать все доступные HTTP-методы с помощью соответствующей функции Javascript:
- get() – метод GET,
- post() - метод POST,
- put() - метод PUT,
- del() - метод DELETE.

Стадии
Вы можете определить несколько стадий тестирования, например:

export const options = {
  stages: [
    { duration: "30s", target: 20 },
    { duration: "1m30s", target: 10 },
    { duration: "20s", target: 0 },
  ],
}

Здесь определены 3 стадии:
1. 30 сек – нагрузка в 20 виртуальных пользователей,
2. 1м 30 сек – 10,
3. 20 сек – время на завершение оставшихся запросов.

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

Сценарий — это элемент JSON, в котором вы определяете аргументы, такие как продолжительность, количество пользователей (как мы рассмотрели выше), а также переменные среды, время старта и т.д. Определив сценарий, вы можете запустить тесты на той же конечной точке, но с использованием разных поведений. Например, создать один сценарий для постепенного роста пользователей, a другой - для резкого взлёта их количества.

Источник: https://www.code4it.dev/blog/k6-load-testing/

День 2208. #Книги
В подарок на шестилетие канала от издательства «Питер» пришла книга «Kubernetes для разработчиков» Уильяма Денниса.

Книга только что вышла в печать. Издательству «Питер» большое спасибо. Почитаю и оценю.

День 2209.
Сегодня порекомендую вам интервью, которое Руслан Шишмарев взял у какого-то левого мутного чувака, застрявшего на одном месте работы в жутком легаси. Но почему-то Руслан решил поспрашивать его про смену работы, собесы, карьерные пути и новые технологии)))

В общем, не буду пересказывать свои путаные мысли. Кому некуда деть полтора часа, гляньте. И не судите строго, это моё первое живое интервью (из увидевших свет, по крайней мере).

https://youtu.be/XMr6KP8U3pY

День 2210. #ЗаметкиНаПолях
Conventional Commits
Conventional Commits — это соглашение о сообщениях коммитов, которое предоставляет простой набор правил для создания явной истории коммитов.

Зачем?
- Автоматическое создание CHANGELOG.
- Автоматическое определение обновления версии на основе типов полученных коммитов.
- Сообщение сути изменений членам команды, общественности и другим заинтересованным лицам.
- Запуск процессов сборки и публикации.
- Упрощение участия людей в ваших проектах за счёт предоставления им возможности изучать более структурированную историю коммитов.

Согласно стандарту, сообщение о коммите должно быть структурировано следующим образом:

<тип>[необязательно, область]: <описание>

[необязательно, тело]

[необязательно, нижний колонтитул]

Сообщение содержит следующие структурные элементы, чтобы сообщать о намерении:
- тип fix – исправление ошибки в кодовой базе;
- тип feat - новая функция;
- другие типы: build, chore, ci, docs, style, refactor, perf, test и т.п.
- BREAKING CHANGE в нижнем колонтитуле, либо ! после типа коммита – ломающее изменение (может быть частью коммитов любого типа).
- Область действия может быть добавлена к типу коммита для предоставления дополнительной контекстной информации и заключена в скобки.

Примеры
Коммит без описания

docs: исправлены орфографические ошибки

Коммит с областью действия

feat(lang): добавлен перевод на английский

Коммит с ! (ломающее изменение) и областью действия:

feat(api)!: отправка email клиенту о доставке продукта

Коммит с телом и несколькими нижними колонтитулами:

fix: предотвратили гонку запросов

Добавлен идентификатор запроса и ссылка на последний запрос. Система отклоняет входящие ответы, отличные от последнего запроса.

Reviewed-by: ABC
Refs: #123

Спецификация
1) Коммиты должны иметь префикс типа (существительное), за которым следуют необязательные область действия и ! и обязательные двоеточие, пробел и описание.
2) Область действия может быть указана после типа. Она должна состоять из существительного в скобках, описывающего раздел кодовой базы.
3) Описание должно следовать сразу за двоеточием и пробелом после типа(области). Это краткое изложение изменений.
4) Более длинное тело коммита (дополнительная контекстная информация об изменениях кода) может быть указано ниже. Тело должно быть отделено пустой строкой.
5) Тело коммита имеет свободную форму и может состоять из любого количества абзацев, разделённых пустой строкой.
6) Один или несколько нижних колонтитулов могут быть добавлены после тела и пустой строки. Каждый должен состоять из токена слова, за которым следуют разделитель ": " или " #" и строковое значение.
- токен должен использовать дефис вместо пробелов (помогает отличить нижний колонтитула от тела). Исключение - BREAKING CHANGE;
- значение может содержать пробелы и символы новой строки.
7) Критические изменения должны быть указаны:
- в префиксе типа с помощью ! непосредственно перед двоеточием;
- в виде записи в нижнем колонтитуле с помощью текста "BREAKING CHANGE: " и описания.

Источник: https://www.conventionalcommits.org/en/v1.0.0/

День 2211. #ЧтоНовенького
Обновления HTTP-файлов в Visual Studio. Начало
Несколько новых функций были добавлены в Visual Studio 2022 17.12+ для работы с HTTP-файлами.

Переменные запроса
При работе с API часто требуется получить значение из конечной точки, а затем использовать его в последующем запросе. Это можно сделать с помощью переменных запроса. Один из наиболее распространённых сценариев: вызвать конечную точку для аутентификации в API и получить обратно токен, который можно использовать для будущих запросов. Запрос ниже относится к примеру приложения TodoApi Дэвида Фаулера. API имеет конечную точку, где вы можете создать нового пользователя, указав имя пользователя и пароль. Это конечная точка, к которой мы делаем запрос:

@username = bloguser
# войти и сохранить ответ как "login"
# @name login
POST {{TodoApi_HostAddress}}/users/token
Content-Type: application/json
{
  "username": "{{username}}",
  "password": "{{password}}"
}
###

В этом случае имя пользователя определено в HTTP-файле, а пароль хранится безопасно с использованием переменных среды (о них в следующем посте). В запрос к конечной точке /users/token мы передаём имя пользователя и пароль как часть тела HTTP-запроса. Переменная запроса обозначена сразу над запросом в виде комментария:

# @name login

После отправки этого запроса в Visual Studio вы можете получить значение из ответа или запроса. В коде ниже мы используем переменную запроса login для извлечения полученного токена и создания элемента TODO, используя авторизацию. Также мы сохраняем ответ в переменную запроса todo1:

# Создать элемент TODO
# @name todo1
POST {{TodoApi_HostAddress}}/todos
Authorization: Bearer {{login.response.body.$.token}}
Content-Type: application/json
{
  "title": "Write blog post"
}
###

Рассмотрим синтаксис подробнее:

{{login.response.body.$.token}}

<имяПеременной> – имя переменной запроса (в нашем примере - login);
response|request – извлекаем значение из ответа или из запроса;
body|headers – извлекаем значение из тела или заголовков ответа/запроса;
*|JSONPath|XPath|Header – выражение для извлечения результата:
- * - всё тело (кроме случаев извлечения из Header),
- JSONPath – путь к переменной в JSON (.$.…),
- XPath – путь к переменной в XML (./.…).
В примере выше мы извлекаем переменную token из корня JSON ответа (body.$.token).

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

Источник: https://devblogs.microsoft.com/visualstudio/http-file-updates-for-request-variables-and-more/

День 2212. #ЧтоНовенького
Обновления HTTP-файлов в Visual Studio. Окончание
Начало

Переменные среды
Чтобы задать переменным разные значения в разных средах, создайте файл http-client.env.json в том же каталоге, что и http-файл, или в одном из его родительских каталогов:

{
  "dev": {
    "HostAddress": "https://localhost:44320"
  },
  "remote": {
    "HostAddress": "https://contoso.com"
  }
}

Это файл JSON, содержащий одну или несколько именованных сред, например dev и remote. Каждая именованная среда содержит одну или несколько переменных, например HostAddress. На переменные из файла среды можно ссылаться так же, как и на другие переменные:

GET {{HostAddress}}/api/search/tool

Среду можно выбрать в заголовке окна http-файла в Visual Studio.
Если в http-файле определена переменная с тем же именем, она переопределит значения из файла переменных среды.

Среда $shared
Вы можете объявить переменную, которая будет доступна для всех сред. Для этого и предназначена новая среда $shared. Если вы создаёте среду с именем $shared, переменные будут доступны в любой среде. Если значение, также определено в именованной среде, оно переопределит значение из среды $shared:

{
  "$shared": {
    "message": "Default msg",
    "username": "httpfile-user",
    "hosturl": "http://example.com/api/sample"
  },
  "dev": {
    "hosturl": "http://localhost:5000/api/sample"
  },
  "prod": {
    "message": "Msg from prod"
  }
}

Здесь в среде dev значение hosturl будет переопределено на localhost, а в среде prod будет своё значение message.

Источники:
- https://devblogs.microsoft.com/visualstudio/http-file-updates-for-request-variables-and-more/
- https://learn.microsoft.com/en-us/aspnet/core/test/http-files?view=aspnetcore-9.0#environment-files

День 2213. #ЗаметкиНаПолях
Создаём Надёжных Клиентов API с Refit. Начало
Работа с внешними API - важная часть современной разработки ПО, но это может быть больно. Мы все боролись с настройками HttpClient, писали повторяющийся код и надеялись, что не пропустили где-то параметр или заголовок. Refit значительно упрощает нам жизнь. Он обрабатывает всю тяжёлую логику работы с HTTP, позволяя сосредоточиться на том, что важно: логике приложения.

Что это?
Refit — это типобезопасная библиотека REST для .NET. Она позволяет определить API как интерфейс, который Refit затем реализует для вас. Такой подход сокращает шаблонный код и делает вызовы API более читаемыми и поддерживаемыми. Вы описываете конечные точки API с помощью сигнатур методов и атрибутов, а Refit заботится обо всём остальном:
1. Автоматическая сериализация и десериализация.
Вам не придётся преобразовывать объекты в JSON и обратно. Refit делает это за вас.
2. Строго типизированные определения API.
Refit помогает выявлять ошибки на ранних этапах. Если вы неправильно введёте параметр или используете неправильный тип данных, вы узнаете об этом во время компиляции, а не когда ваше приложение даст сбой при работе.
3. Поддержка различных методов HTTP: GET, POST, PUT, PATCH, DELETE.
4. Манипуляции с запросами/ответами.
Вы можете легко добавлять пользовательские заголовки или обрабатывать определённые типы контента.
Кроме того, вызовы API становятся самодокументируемыми. Любой, кто читает код, сможет быстро понять, что делает каждый метод, не углубляясь в детали реализации.

Настройка и использование
Мы реализуем полный интерфейс CRUD и продемонстрируем его использование в приложении Minimal API. Сначала установим необходимые NuGet-пакеты:

Install-Package Refit
Install-Package Refit.HttpClientFactory

Теперь создадим интерфейс Refit:

using Refit;

public interface IBlogApi
{
  [Get("/posts/{id}")]
  Task<Post> GetPostAsync(int id);

  [Get("/posts")]
  Task<List<Post>> GetPostsAsync();

  [Post("/posts")]
  Task<Post> CreatePostAsync([Body] Post post);

  [Put("/posts/{id}")]
  Task<Post> UpdatePostAsync(int id, [Body] Post post);

  [Delete("/posts/{id}")]
  Task DeletePostAsync(int id);
}

public record Post(int Id, string Title, string Body, int UserId);

Мы определяем интерфейс IBlogApi с методами для CRUD-операций. Запись Post представляет сообщения в блоге.

Затем зарегистрируем Refit в DI-контейнере:

using Refit;

builder.Services
 .AddRefitClient<IBlogApi>()
 .ConfigureHttpClient(c => c.BaseAddress = 
  new Uri("https://jsonplaceholder.typicode.com"));

Наконец мы можем использовать IBlogApi в конечных точках Minimal API:

app.MapGet("/posts/{id}",
 async (int id, IBlogApi api) =>
    await api.GetPostAsync(id));

app.MapGet("/posts",
 async (IBlogApi api) =>
    await api.GetPostsAsync());

app.MapPost("/posts",
 async ([FromBody] Post post, IBlogApi api) =>
    await api.CreatePostAsync(post));

app.MapPut("/posts/{id}",
 async (int id, [FromBody] Post post, IBlogApi api) =>
    await api.UpdatePostAsync(id, post));

app.MapDelete("/posts/{id}",
 async (int id, IBlogApi api) =>
    await api.DeletePostAsync(id));

Мы создали полностью функциональный API, который взаимодействует с внешним сервисом, всего в нескольких строках кода. Никаких ручных HTTP-запросов, никакой обработки сырого JSON — Refit позаботится обо всём этом за нас.

Продолжение следует…

Источник: https://www.milanjovanovic.tech/blog/refit-in-dotnet-building-robust-api-clients-in-csharp

День 2214. #ЗаметкиНаПолях
Создаём Надёжных Клиентов API с Refit. Продолжение
Начало

Параметры запроса
При работе с API часто требуется отправлять данные как часть URL либо в маршруте, либо в строке запроса. Refit делает этот процесс простым и типобезопасным. Добавим в IBlogApi пару более сложных сценариев:

public interface IBlogApi
{
  // …

  [Get("/posts")]
  Task<List<Post>> GetPostsAsync(
   [Query] Filters filters);

  [Get("/users/{userId}/posts")]
  Task<List<Post>> GetUserPostsAsync(int userId);
}

public record Filters(int? UserId, string? Title);

Здесь:
- GetPostsAsync использует объект для представления фильтров запроса. Это подходит для конечных точек со множеством необязательных параметров. Refit автоматически преобразует этот объект в строку запроса. Использование объекта для фильтров запроса делает код типобезопасным и удобным для рефакторинга. Если нужно добавить новый фильтр запроса, просто добавьте свойство в Filters.
- GetUserPostsAsync демонстрирует передачу параметров в маршрут.

Динамические заголовки и аутентификация
Ещё одним распространённым требованием при интеграции с API является включение пользовательских заголовков или токенов аутентификации в запросы. Refit предоставляет несколько способов сделать это: от простых статических заголовков до динамической аутентификации, специфичной для запроса.

public interface IBlogApi
{
  [Headers("User-Agent: MyAwesomeApp/1.0")]
  [Get("/posts")]
  Task<List<Post>> GetPostsAsync();

  [Get("/secure-posts")]
  Task<List<Post>> GetSecurePostsAsync(
   [Header("Authorization")] string bearerToken);

  [Get("/user-posts")]
  Task<List<Post>> GetUserPostsAsync(
   [Authorize(scheme: "Bearer")] string token);
}

- можно добавить статический заголовок ко всем запросам, используя атрибут метода Headers;
- с помощью атрибута параметра Header можно передавать значение заголовка в качестве параметра;
- атрибут параметра Authorize — удобный способ добавить аутентификацию через токен.

А если нужно добавить один и тот же динамический заголовок ко всем запросам, можно использовать DelegatingHandler.

Настройки JSON-сериализации
Refit дает гибкость при выборе и настройке JSON-сериализации. По умолчанию он использует System.Text.Json, но можно легко переключиться на Newtonsoft.Json, установив NuGet-пакет Refit.Newtonsoft.Json и настроив клиента:

builder.Services.AddRefitClient<IBlogApi>(
 new RefitSettings {
  ContentSerializer = 
   new NewtonsoftJsonContentSerializer(
    new JsonSerializerSettings
    {
      ContractResolver = new CamelCasePropertyNamesContractResolver(),
      NullValueHandling = NullValueHandling.Ignore
    })
})
.ConfigureHttpClient(…);

Здесь мы настроили camelcase для имён свойств и игноририрование нулевых значений при сериализации.
System.Text.Json быстрее и использует меньше памяти, что делает его отличным выбором по умолчанию. Однако Newtonsoft.Json предлагает больше функций и может быть необходим для совместимости со старыми системами или для особых потребностей сериализации.

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

Источник: https://www.milanjovanovic.tech/blog/refit-in-dotnet-building-robust-api-clients-in-csharp

День 2215. #ЗаметкиНаПолях
Создаём Надёжных Клиентов API с Refit. Окончание
Начало
Продолжение

Обработка HTTP-ответов
Хотя Refit по умолчанию автоматически десериализует ответы в определённые вами типы, бывают случаи, когда требуется больше контроля над HTTP-ответом. Refit предоставляет два варианта для этих сценариев: HttpResponseMessage и ApiResponse<T>. Обновим IBlogApi для использования этих типов:

public interface IBlogApi
{
  [Get("/posts/{id}")]
  Task<HttpResponseMessage> GetPostRawAsync(int id);

  [Get("/posts/{id}")]
  Task<ApiResponse<Post>> 
   GetPostWithMetadataAsync(int id);

  [Post("/posts")]
  Task<ApiResponse<Post>>
   CreatePostAsync([Body] Post post);
}

Рассмотрим, как их использовать.

1. HttpResponseMessage

HttpResponseMessage resp = 
 await blogApi.GetPostRawAsync(1);

if (resp.IsSuccessStatusCode)
{
  var content = await resp.Content
   .ReadAsStringAsync();
  var post = JsonSerializer
   .Deserialize<Post>(content);
  // …
}
else
{
  Console.WriteLine($"Error: {resp.StatusCode}");
}

Этот подход даёт вам полный контроль над HTTP-ответом. Вы можете получить доступ к кодам состояния, заголовкам и необработанному контенту. Но придётся вручную заниматься десериализацией.

2. ApiResponse<T>
Специфичный для Refit тип, который оборачивает десериализованный контент и метаданные ответа:

var newPost = new Post("New Post", "Content", 1);

ApiResponse<Post> resp = await 
 blogApi.CreatePostAsync(newPost);

if (resp.IsSuccessStatusCode)
{
  var post = resp.Content;
  var location = resp.Headers.Location;
  Console.WriteLine($"ID: {post.Id}");
  Console.WriteLine($"Location: {location}");
}
else
{
  Console.WriteLine($"Error: {resp.Error.Content}");
  Console.WriteLine($"Status: {resp.StatusCode}");
}

Этот подход позволяет получить доступ к созданному ресурсу, проверить определённые заголовки, такие как Location, и легко обрабатывать ошибки.

Итого
Refit преобразует способ нашего взаимодействия с API в приложениях .NET. Преобразование API в строго типизированный интерфейс упрощает код, повышает безопасность типов и улучшает удобство обслуживания.

Основные преимущества Refit:
- упрощённые вызовы API с автоматической сериализацией и десериализацией;
- гибкая обработка параметров для сложных запросов;
- простое управление заголовками и аутентификацией;
- варианты сериализации JSON для соответствия потребностям проекта;
- детальный контроль над ответами HTTP при необходимости.

Refit устраняет шаблонный код, снижает риск ошибок и позволяет вам сосредоточиться на базовой логике приложения, а не на тонкостях HTTP-коммуникаций. Но помните, что хотя Refit упрощает взаимодействие с API, он не заменяет понимания основных принципов RESTful-коммуникации и HTTP.

Источник: https://www.milanjovanovic.tech/blog/refit-in-dotnet-building-robust-api-clients-in-csharp

День 2216. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 42. Никакие инженерные или управленческие приёмы не дадут эффекта, если вы имеете дело с неразумными людьми

Иногда можно столкнуться с тем, кто действует неразумно. Начальник, ожидающий, что сотрудник будет непрерывно работать над проектом по восемь часов пять дней в неделю. Заказчик, настаивающий на том, что может выдвигать требования от имени группы пользователей, к которой он не принадлежит. Коллега, умалчивающий о своих знаниях вместо того, чтобы делить¬ся ими с соратниками. Старший менеджер, надеющийся изменить культуру в крупной ор-ганизации, просто утвердив ряд новых инструкций.

Человек, действующий неразумно, — это не техническая, а человеческая проблема. Решить её можно несколькими способами:
— неуклонно отстаивать свою позицию в спорах;
— поддаться давлению со стороны неразумного человека и делать всё, что он говорит, даже если вы считаете это неправильным;
— делать вид, что подчиняетесь, но поступать по-другому или вообще ничего не делать.

Однако лучшая стратегия — понять, что заставляет человека действовать неразумно, а затем подумать, как реагировать. Люди могут защищать укоренившиеся привычки, часто они просто недостаточно информированы. Незнакомые приёмы, жаргон и самоуверенность разработчиков ПО могут заинтересовать клиентов, у которых мало опыта работы с командами разработчиков и не хватает технических знаний. Люди же, имеющие отрицательный прошлый опыт такой работы, могут с подозрением относиться к незнакомой информации.

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

Кто здесь неразумен?
Убедитесь, что вы сами ведете себя разумно. Бизнес-аналитики, руководители проектов или разработчики могут показаться неразумными, если не соглашаются делать всё, что от них требуют. Бизнес-аналитик, который просит, чтобы пользователь или руководитель уделяли время работе с командой разработчиков, может показаться неразумным тому, кто не ожидал, что от него потребуется такое активное участие в проекте.

Иногда люди думают, что они знают больше, чем на самом деле, и оказывают давление, требуя использовать неверный подход. Часто можно встретить разработчиков, яростно защищающих свою реализацию, даже когда им указывают на очевидные проблемы. Вообще очень немногие умеют признавать свои ошибки. Это поведение неразумно, и если под давлением от такого разработчика его решение всё же будет принято, то от последствий пострадают все.

В пользу гибкости
Категоричность — ещё одна черта, кажущаяся неразумной. Чтобы никто не выглядел неразумным, попробуйте понять цели, приоритеты, движущие силы, страхи и ограничения друг друга. Выясните, какие действия и результаты приносят плоды в обоих ваших мирах, а какие — чреваты проблемами. Заключите соглашение, чтобы все стороны знали, чего ожидать друг от друга. Мы будем лучше ладить, ценя и уважая точку зрения друг друга.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 5.