День 2532. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Окончание
Начало
Продолжение 1
Продолжение 2

Когда инженерам нужно брать на себя ответственность
Как инженеры, мы должны брать на себя ответственность за своё дело. Нам необходимо:
- Действительно проверять код, а не просто одобрять пул-реквест, не глядя;
- Давать и получать обратную связь как профессионалы;
- Инвестировать в обучение и развитие;
- Просить о помощи, когда мы застряли;
- Отказывать ужасному коду в пул-реквестах, даже если неудобно перед коллегами;
- Устанавливать и поддерживать стандарты в команде.
Если вы одобрили пул-реквест, не прочитав его, вы несёте ответственность за этот код. Если вы написали небрежный код, потому что вам было лень, это ваша вина. Если вы совершаете одни и те же ошибки в течение пяти лет и отказываетесь учиться, проблема в вас.

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

Так как же это называть?
Вместо «технического долга» попробуйте следующие варианты:
- «Технические последствия прошлых бизнес-решений» — многословно, но точно. Это позволяет сохранить ответственность там, где ей место.
- «Затраты на обслуживание» — в каждом коде есть свои затраты. Они растут со временем. Заложите их в «бюджет».
- «Сдвиг контекста» — то, что имело смысл два года назад, сейчас не имеет смысла. Это нормально.
- «Необходимый рефакторинг» — ПО развивается. Рефакторинг — это нормально. Перестаньте относиться к нему как к наказанию.
- «Стоимость обучения» — вы не знали, что то, что вы создавали, будет успешным. Теперь знаете. Пора оптимизировать.

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

Хорошие менеджеры берут на себя ответственность за компромиссы. Они говорят: «Мы выбрали скорость вместо гибкости, и теперь нужно заново оптимизировать. Это потребует времени и ресурсов. Я распределяю и то, и другое».
Плохие менеджеры используют ретроспективный анализ в качестве оружия. Они говорят: «Вы должны были сделать это правильно с первого раза. Почему так много технического долга?»

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

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

А если вам будут возражать и будут настаивать, что это «долг», который вы «заимствовали»…
Начните проходить собеседования. Потому что вы работаете на человека, который не понимает разработку ПО и всегда будет винить вас, когда возникнут трудности.

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k

День 2533. #Оффтоп
Праздники продолжаются, поэтому снова представляю вам полуразвлекательное видео.

Мы все заняты софтом, алгоритмами, оптимизациями. Но редко задумываемся, на чем весь этот софт выполняется. Максимум - выбираем SKU виртуальной машины или контейнера.

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

В общем, любителям железячек и физики должно зайти. Приятного просмотра.

https://youtu.be/MiUHjLxm3V0

День 2535. #ЗаметкиНаПолях
Снижаем Нагрузку на CPU при Использовании GitHub Actions
Если вы используете GitHub Actions на собственных серверах, вы могли заметить, что они могут быть удивительно ресурсоемкими для ЦП, даже в режиме ожидания. При более внимательном рассмотрении становится ясно, что один раннер может загружать CPU на 100%. Это не ошибка в вашем рабочем процессе; это преднамеренное проектное решение в механизме сна раннера.

Проблема: «Занятое ожидание»
Вместо использования стандартных, эффективных функций сна, предоставляемых операционной системой, раннер GitHub Actions использует цикл «занятого ожидания» (Busy-waiting). Это означает, что он постоянно проверяет системные часы в плотном цикле, ожидая истечения заданного промежутка времени. Хотя такой подход обеспечивает совместимость в широком диапазоне сред, включая некоторые без традиционных функций сна, он крайне неэффективен для подавляющего большинства систем, таких как стандартные виртуальные машины Linux или Windows. Эта постоянная проверка поддерживает полную активность CPU, что приводит к нерациональному использованию ресурсов, повышению температуры и потенциальному снижению производительности других задач на той же машине.

Решение: интеллектуальный скрипт установки режима сна
К счастью, мы можем решить эту проблему, заменив стандартный скрипт установки режима сна на более интеллектуальную версию. Цель — использовать наиболее эффективный метод установки режима сна, доступный в системе. Вот скрипт, который отдаёт приоритет стандартным командам установки режима сна и предоставляет резервные варианты, обеспечивая как эффективность, так и совместимость.

Перейдите в папку, где установлен ваш раннер, и отредактируйте файл safe_sleep.sh. Замените его содержимое следующим:

#!/bin/bash

# Используем нативную команду 'sleep', если доступна (наиболее эффективно)
if [ -x "$(command -v sleep)" ]; then
    sleep $1
    exit 0
fi

# Пробуем 'read' с таймаутом (встроено в bash)
if [[ -n "$BASH_VERSINFO" && "${BASH_VERSINFO[0]}" -ge 4 ]]; then
    read -rt "$1" <> <(:) || :
    exit 0
fi

# Креативный вариант с 'ping'
if [ -x "$(command -v ping)" ]; then
    ping -c $1 127.0.0.1 > /dev/null
    exit 0
fi

# Оригинальное «занятое ожидание» (в крайнем случае)
SECONDS=0
while [[ $SECONDS != $1 ]]; do
    :
done

Этот скрипт сначала пытается использовать стандартную команду sleep. Если она недоступна, он пытается использовать read с таймаутом, что является встроенной функцией оболочки и всё ещё эффективнее, чем ожидание в активном режиме. В качестве запасного варианта используется ping. Только если ни один из этих вариантов недоступен, скрипт возвращается к исходному циклу «занятого ожидания».

Предупреждение:
Средства запуска GitHub Actions могут обновляться автоматически. При обновлении ваши изменения в файле safe_sleep.sh могут быть перезаписаны. Чтобы гарантировать сохранение исправления, вы можете настроить задание cron или запланированную задачу для периодического повторного применения этого изменения.

Дополнительные ресурсы
Для получения более подробной технической информации и обсуждения этой темы в сообществе вы можете обратиться к этим проблемам и пул-реквестам на GitHub:
- https://github.com/actions/runner/issues/2380
- https://github.com/actions/runner/issues/3792
- https://github.com/actions/runner/pull/3870

Источник: https://www.meziantou.net/reduce-github-actions-runner-cpu-usage.htm

День 2536. #Карьера
Топ Советов по Повышению Продуктивности. Часть 3
Часть 1
Часть 2

3. Правило 15 минут: секретное оружие против прокрастинации и бесконечных отвлекающих задач
У каждого разработчика есть два заклятых врага: задача, которую не хочется начинать, и задача, от которой невозможно оторваться.

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

Сценарий 2: Вы выясняете, почему медленно загружается страница. Нужно проверить всего несколько метрик, это займёт десять минут. Три часа спустя вы перестроили всю свою инфраструктуру мониторинга, прочитали 12 статей о производительности запросов в EF и сделали бенчмарк для сравнения трёх разных решений — но всё ещё не решили первоначальную проблему.

Правило 15 минут
1. Для задач, которых вы избегаете: пообещайте себе, что поработаете над задачей всего 15 минут. Через 15 минут вы сможете остановиться без чувства вины.
2. Для задач, в которые вы вкладываете слишком много сил: установите 15-минутный таймер, прежде чем углубляться в какую-либо тему. Когда он зазвонит, спросите себя: «Действительно ли это решает мою проблему, или я просто наслаждаюсь процессом исследования?»

Почему это работает?
Самое сложное — начать. Наш мозг запрограммирован на избегание дискомфорта, и большие, неопределённые задачи провоцируют эту реакцию избегания. Но 15 минут? Это не страшно. Любой сможет делать что угодно в течение 15 минут. Вы не обязуетесь закончить — вы обязуетесь начать.
Прелесть в том, что в большинстве случаев вы не остановитесь через 15 минут. Как только вы начнёте, инерция возьмёт верх. Вы обнаружите, что задача не так уж и сложна, как вы себе представляли. Или же вы войдете в состояние потока и совсем забудете о таймере. Правило 15 минут — это психологический лом для вашей мотивации.

Что касается отвлечений, проблема обратная. Разработчики от природы любопытны и стремятся решать проблемы. Мы видим интересное ответвление, и наш мозг активизируется: «О, я мог бы это оптимизировать! Дайте-ка я быстренько…» Проходит 4 часа, а вы ничего не сделали для достижения реальной цели.
15-минутный таймер заставляет быть предельно честным:
- Важен ли для текущей задачи рефакторинг этой функции?
- Нужно ли изучить все внутренности EF, чтобы этот запрос к БД работал оптимальнее?
Иногда ответ — да! Иногда действительно нужно копнуть глубже. Но часто ответ — нет, и правило 15 минут даёт вам право сделать прагматичный выбор, а не перфекционистский.

Практика
1. Ведите список «задач на 15 минут». Того, чего вы избегали: написание документации для модуля, исправление проблем с тестами, обновление зависимостей и т.п. Когда у вас появится время в течение дня (отмена встречи, ожидание тестов/сборки), выполните одну 15-минутную задачу.
За месяц вы выполните 20-30 таких небольших задач, которые иначе откладывались бы навсегда. Код станет лучше, «технический долг» уменьшится, появится чувство удовлетворения.

2. Когда вы ловите себя на том, что исследуете что-то отвлечённое, установите таймер и спросите себя: «Какой минимум нужно знать, чтобы двигаться дальше?» Найдите ответ на этот конкретный вопрос, задокументируйте полученные знания в комментарии или на странице вики для дальнейшего использования, а затем вернитесь к работе. Вы усвоили знания, не утонув в них.

Правило 15 минут — не про жёсткий лимит, а про целенаправленность. Оно превращает «Мне нужно поработать над этим» в «Я работаю над этим», а «Я просто изучаю» в «Я делаю осознанный выбор в отношении того, куда тратить своё время».

Источник: https://dev.to/thebitforge/top-10-productivity-hacks-every-developer-should-know-151h

День 2537. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

15. Промежуточное ПО в ASP.NET Core
«Объясните роль промежуточного ПО в приложениях ASP.NET Core. Приведите пример того, как можно реализовать пользовательское промежуточное ПО в приложении .NET, и опишите сценарий, в котором это промежуточное ПО может быть особенно полезно».

Хороший ответ
Промежуточное ПО в ASP.NET Core — это блоки кода (классы), которые собираются в конвейер приложения для обработки запросов и ответов. Каждый компонент в конвейере промежуточного ПО отвечает за вызов следующего компонента в цепочке или за прерывание цепочки, если это необходимо. Компоненты промежуточного ПО выполняются в порядке их добавления в конвейер приложения.

Промежуточное ПО может обрабатывать такие задачи, как аутентификация, обработка ошибок, обслуживание статических файлов и сложная обработка запросов. Оно также может изменять входящий запрос или исходящий ответ. Некоторые популярные компоненты промежуточного ПО уже реализованы в платформе .NET: аутентификация, авторизация, обслуживание статических файлов и т.п. Для реализации пользовательского промежуточного ПО в приложении .NET нужно определить класс промежуточного ПО с методом Invoke или InvokeAsync, который обрабатывает контекст HTTP.

Вот пример пользовательского промежуточного ПО в .NET-приложении, которое регистрирует время выполнения каждого HTTP-запроса:

using System.Diagnostics;

public class RequestTimingMiddleware
{
  private readonly RequestDelegate _next;

  public RequestTimingMiddleware(
   RequestDelegate next)
  {
    _next = next;
  }

  public async Task InvokeAsync(
   HttpContext context)
  {
    var sw = Stopwatch.StartNew();
    await _next(context);
    sw.Stop();
    var time = sw.ElapsedMilliseconds;
    context.Response.Headers.Add(
      "X-Response-Time-ms", time.ToString());
  }
}

// в Program.cs
var builder =
 WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseMiddleware<RequestTimingMiddleware>();

app.Run(async (context) =>
{
  await context.Response
   .WriteAsync("Hello Middleware!");
});

app.Run();

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

Преимущества
- Модульность: компоненты промежуточного ПО могут быть разработаны, протестированы и повторно использованы в различных приложениях.
- Гибкость: позволяет создавать конвейер обработки запросов, соответствующий потребностям приложения.
- Контроль: вы получаете контроль над запросом и можете манипулировать как объектами запроса, так и объектами ответа.
Понимая и используя промежуточное ПО, разработчики могут значительно улучшить функциональность и производительность приложений ASP.NET Core.

Часто встречающийся неверный ответ
«Чтобы добавить промежуточное ПО в .NET, можно использовать app.Use() в Program.cs и добавить лямбда-функцию с любым кодом для обработки запроса и ответа непосредственно внутрь этого метода».

Почему это неверно
- Чрезмерное упрощение использования промежуточного ПО: встроенный код в Program.cs с использованием app.Use() удобен для простых сценариев, но не подходит для сложного или многократно используемого промежуточного ПО.

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

Обычно эта ошибка возникает, когда разработчики знакомы с настройкой промежуточного ПО на базовом уровне, но не обладают глубокими знаниями лучших практик создания масштабируемых и поддерживаемых компонентов промежуточного ПО в ASP.NET Core.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

День 2538. #Оффтоп
Под конец праздников предлагаю вам развлекательное видео от канала The PrimeTime. Я уже, кажется, рекомендовал какие-то из его видео. Автор - бывший разработчик из Netflix и частенько, с юмором, комментирует статьи по разработке, новости ИТ-индустрии (вроде очередного краха Cloudflare) и рассказывает прочие истории из мира разработки.

Это его видео про… пузырьковую сортировку.

Да. Это алгоритм сортировки, которому нас учили в школе/институте (обычно даже не упоминая про его неэффективность). Причина в его невероятной простоте.

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

https://youtu.be/qGH8gKdpZMQ

День 2539. #ЗаметкиНаПолях
Создаём BinaryData из MemoryStream без Копирования
При работе с BinaryData и MemoryStream в .NET может потребоваться преобразование данных потока в экземпляр BinaryData. Типичный подход с использованием BinaryData.FromStream() предполагает копирование всего буфера, что может повлиять на производительность и увеличить объем выделяемой памяти. Однако существует более эффективный способ достижения этой цели без копирования памяти.

Проблема с BinaryData.FromStream()
Стандартный способ создания BinaryData из потока прост, но сопряжен с затратами:

var stream = new MemoryStream();
stream.Write([1, 2, 3]);
stream.Seek(0, SeekOrigin.Begin);

// Это требует копирования памяти
var data = BinaryData.FromStream(stream);

При вызове метода BinaryData.FromStream(), метод считывает поток и копирует его содержимое в новый буфер. Для больших потоков или приложений, где производительность критична, это дополнительное копирование может быть неэффективным.

Подход без копирования
Если вы работаете с MemoryStream, вы можете напрямую получить доступ к его базовому буферу и создать экземпляр BinaryData без копирования:

var stream = new MemoryStream();
stream.Write([1, 2, 3]);

// Это не требует копирования памяти
var data = new BinaryData(stream.GetBuffer().AsMemory(0, (int)stream.Position));

Этот подход использует GetBuffer() для доступа к базовому массиву байт MemoryStream, а затем оборачивает его в срез Memory<byte>, представляющий только записанную часть. Конструктор BinaryData принимает ReadOnlyMemory<byte>, поэтому преобразование происходит неявно.

Предупреждение: Изменчивость буфера: поскольку вы используете общий буфер, любые изменения исходного буфера MemoryStream могут повлиять данные в BinaryData. Убедитесь, что вы закончили запись в поток, прежде чем создавать BinaryData.

Интересно, что сама реализация BinaryData.FromStream создаёт новый экземпляр BinaryData таким же образом.

Источник: https://www.meziantou.net/zero-copy-binarydata-creation-from-memorystream-in-dotnet.htm

День 2540. #Карьера
Хотите Выступить на Конференции Разработчиков?
Это может быть полезным опытом, который не только поможет вам побороть страх публичных выступлений, но и заставит как следует разобраться в теме, и, возможно, взглянуть на неё по-новому.

Но сначала…
1. Спросите себя, зачем? Хотите продвигать свою компанию, курсы или программные продукты? Завести полезные контакты и продвигаться по карьере? Просто путешествовать и знакомиться с людьми? Определите, что для вас означает «успех».
2. Будьте реалистичны в отношении объёма работы. Если вы думаете, что можете набросать какой-нибудь код, написать доклад, и вы уже на пути к крупному мероприятию, то… нет. Так это не работает.

Этап 1: Напишите доклад
Желательно об уникальной теме. Выясните, чему аудитория хочет научиться и почему вы лучший человек, чтобы им это рассказать. Выступите с докладом перед группой коллег. Всё может пройти отлично… а может провально. В этом и смысл практики. Исправьте примеры и слайды. Дополните короткий доклад или сократите длинный. Выступите с докладом в другой группе.

Этап 2: Заявите о себе
Открытые митапы проводят как крупные компании, так и сообщество DotNetRu в разных городах несколько раз в год. Обычно это небольшие однодневные мероприятия, как правило, бесплатные (или очень дешёвые) для посещения. Это отличный способ познакомиться с другими докладчиками и людьми, участвующими в технических мероприятиях, и вы почти наверняка встретите нескольких человек из программных комитетов более крупных конференций.
Такие мероприятия — шанс привлечь к себе внимание. Используйте митап по полной: выступите со своим докладом, посмотрите другие сессии. Общайтесь с организаторами. Найдите способ поддерживать связь с людьми, с которыми вы познакомились. Присоединяйтесь к чатам, обменяйтесь контактами.

Этап 3: Подайте заявку
У вас есть пара докладов. Вы выступали с ними достаточно часто, чтобы знать, что они хороши. Можно подать заявку на более крупную конференцию. Например, DotNext принимает заявки круглый год. Многие мероприятия покрывают ваши расходы на проезд и проживание в отеле. Если нет, возможно, вы сможете убедить работодателя покрыть ваши расходы.
Поддерживайте актуальность контента либо напишите новый доклад специально для этой конференции. Хотя, новый доклад желательно также предварительно протестировать на одном из митапов.
Не отправляйте множество заявок на одну конференцию в надежде, что хотя бы одна будет принята. К авторам со множеством заявок организаторы могут отнестись с подозрением, посчитав, что на самом деле у него в реальности не готов ни один доклад.

Этап 4: Знайте, когда остановиться
Выступления — это не только весело, но и утомительно. Одни выступают везде, заводят множество друзей и создают счастливые воспоминания, а потом однажды решают, что хватит. Другие выступают, вычёркивают пункт из списка желаний и решают, что им достаточно. Третьи привыкают к размеренному распорядку из 3-4 мероприятий в год.
Поэтому заранее определите, что значит «успех». Если вы делаете это ради удовольствия, помните, что, когда это перестаёт нравиться, нужно остановиться. Если в целях продвижения или маркетинга? Отслеживайте потенциальных клиентов. Убедитесь, что это действительно привлекает внимание и приносит ожидаемый доход.

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

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

Источник: https://dylanbeattie.net/2025/12/08/so-you-want-to-speak-at-software-conferences.html

День 2541. #AI
Добавляем ИИ в Существующие REST API с Помощью MCP. Начало
Сегодня многие организации стремятся интегрировать ИИ в существующую инфраструктуру, не переписывая всё заново. Рассмотрим процесс добавления возможностей MCP в существующие REST API на .NET, что позволит обеспечить бесперебойное взаимодействие между системами ИИ и вашими бэкэнд-данными и приложениями.

Что это?
MCP (Model Context Protocol - Протокол Контекста Модели) —стандартизированный протокол с открытым кодом, представленный компанией Anthropic. Он был разработан для обеспечения взаимодействия моделей ИИ (таких как чат-боты или большие языковые модели — LLM) с внешними системами. Одна из его основных особенностей — двусторонняя связь, позволяющая ИИ не только получать данные, но и выполнять действия, такие как внесение обновлений в эти системы.

Главное преимущество MCP в том, что он связывает системы ИИ (такие как ChatGPT или Claude) и бэкэнд-системы, такие как базы данных или сторонние сервисы, создавая гибкий двусторонний поток данных. Если вы хотите добавить функциональность ИИ в приложение без полной переработки, MCP предлагает простое и эффективное решение.

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

Как MCP работает с API .NET?
В то время как REST — это широко используемая архитектура для межсервисного взаимодействия, MCP оптимизирован для взаимодействия ИИ с системами.

Сравнение
1. Целевая аудитория:
REST: В основном используется разработчиками для интеграции сервисов.
MCP: Разработан для взаимодействия моделей и агентов ИИ с бэкэнд-системами. Создан для упрощения интеграции с нетехническими пользователями и системами.

2. Передача информации:
REST: Связь обычно осуществляется по протоколу HTTP с использованием методов GET, POST, PUT, DELETE.
MCP: Может использовать стандартный ввод-вывод для локальной связи или потоковый HTTP для удалённой связи, что поддерживает обмен данными в реальном времени.

3. Доступность:
REST: Требует таких инструментов, как OpenAPI (Swagger), для документирования.
MCP: Автоматически обнаруживает доступные инструменты, ресурсы и подсказки во время выполнения, что делает его более динамичным.

4. Варианты использования:
REST: Отлично подходит для связи между серверами или между сервером и клиентом.
MCP: Лучше всего подходит для интеграции агентов ИИ с бэкэнд-системами, такими как CRM, базы данных или даже сторонние сервисы.

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

Источник: https://trailheadtechnology.com/reusing-your-existing-net-rest-apis-for-ai-with-mcp/