Ровно год назад писал пост про синхронизацию через OpenAPI.
Тот подход был основан на Swagger. С тех пор в .NET появился встроенный функционал для генерации спецификаций OpenAPI. Держите короткий гайд:
1. Создаём новый проект:
mkdir -p backend
cd backend
dotnet new webapi
По умолчанию файл проекта backend.csproj уже использует нужный пакет Microsoft.AspNetCore.OpenApi.
<PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="10.0.7" />
Можно запустить приложение и перейти по адресу https://localhost:{port}/openapi/v1.json, чтобы убедиться, что всё работает.
2. Следующий шаг – автоматическая генерация спецификации в виде файла.
Для этого нужно установить ещё один пакет:
dotnet add package Microsoft.Extensions.ApiDescription.Server
И включить генерацию при сборке, добавив в backend.csproj вот этот блок:
<PropertyGroup">
<OpenApiGenerateDocuments>true</OpenApiGenerateDocuments>
<OpenApiGenerateDocumentsOnBuild>true</OpenApiGenerateDocumentsOnBuild>
<OpenApiDocumentsDirectory>$(MSBuildProjectDirectory)</OpenApiDocumentsDirectory>
</PropertyGroup>
Теперь, если выполнить команду dotnet build, файл спецификации автоматически создастся в директории с проектом. В нашем случае – это файл backend.json.
3. Дальнейшие шаги, связанные с фронтом, остались без изменений – используем пакет swagger-typescript-api:
pnpx swagger-typescript-api generate --path ./backend.json -o ./generated -n WebApi.ts
Сгенерированные типы TypeScript будут лежать в ./generated/WebApi.ts.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2
Лайфхак: экономим токены в GitHub Copilot
Если вы, как и я, пользуетесь VS Code в связке с Copilot, то вот вам несколько лайфхаков для экономии токенов/кредитов:
1. Я использую только GPT-5.6 Luna потому что это одна из самых дешёвых моделей, которая пишет добротный код. Но агент VS Code может использовать другие модели для исследования, вызова сабагентов, вызова инструментов (tools), автокомплита и так далее.
Можно сделать так, чтобы агент VS Code использовал только нужную вам модель, указав её название в settings.json.
2. Вызовы некоторых инструментов могут сопровождаться длинным выводом. В прошлом году я писал об этом пост. В VS Code сейчас появились настройки, которые позволяют сжимать вывод CLI-утилит или вывод инструментов:
#программирование@yet_another_dev
Если вы, как и я, пользуетесь VS Code в связке с Copilot, то вот вам несколько лайфхаков для экономии токенов/кредитов:
1. Я использую только GPT-5.6 Luna потому что это одна из самых дешёвых моделей, которая пишет добротный код. Но агент VS Code может использовать другие модели для исследования, вызова сабагентов, вызова инструментов (tools), автокомплита и так далее.
Можно сделать так, чтобы агент VS Code использовал только нужную вам модель, указав её название в settings.json.
{
"chat.defaultModel": "GPT-5.6 Luna (Copilot)",
"chat.exploreAgent.defaultModel": "GPT-5.6 Luna (copilot)",
"chat.planAgent.defaultModel": "GPT-5.6 Luna (copilot)",
"github.copilot.chat.askAgent.model": "GPT-5.6 Luna (Copilot)",
"github.copilot.chat.exploreAgent.model": "GPT-5.6 Luna (Copilot)",
"github.copilot.chat.implementAgent.model": "GPT-5.6 Luna (Copilot)",
"github.copilot.selectedCompletionModel": "GPT-5.6 Luna (Copilot)",
"inlineChat.defaultModel": "GPT-5.6 Luna (copilot)",
}2. Вызовы некоторых инструментов могут сопровождаться длинным выводом. В прошлом году я писал об этом пост. В VS Code сейчас появились настройки, которые позволяют сжимать вывод CLI-утилит или вывод инструментов:
{
"chat.tools.compressOutput.enabled": true,
"chat.tools.terminal.outputCompaction": true,
"chat.tools.terminal.outputDeltas": true,
}#программирование@yet_another_dev
👍8
Ну наконец-то. Маркировка ИИ-контента от Яндекс Музыки.
Будет интересно сравнить результаты работы Slopless с разметкой Яндекса.
Источник.
#нейромузыка@yet_another_dev
Будет интересно сравнить результаты работы Slopless с разметкой Яндекса.
Источник.
#нейромузыка@yet_another_dev
🔥9❤1
В Microsoft переписали рантайм GitHub Copilot с TypeScript на Rust при помощи агентов.
Подсмотрели, как Anthropic переписали рантайм Bun с Zig на Rust и решили аналогичным образом прорекламировать свой ИИ.
Ждём, когда Яндекс перепишет какой-нибудь свой рантайм при помощи Алисы.
#программирование@yet_another_dev
Подсмотрели, как Anthropic переписали рантайм Bun с Zig на Rust и решили аналогичным образом прорекламировать свой ИИ.
Ждём, когда Яндекс перепишет какой-нибудь свой рантайм при помощи Алисы.
#программирование@yet_another_dev
👍2🤣2
yet another dev
В Microsoft переписали рантайм GitHub Copilot с TypeScript на Rust при помощи агентов. Подсмотрели, как Anthropic переписали рантайм Bun с Zig на Rust и решили аналогичным образом прорекламировать свой ИИ. Ждём, когда Яндекс перепишет какой-нибудь свой рантайм…
Что интересного в этой статье:
1. Потрачено $120К, а агенты суммарно отработали около 3-х недель. Вся работа фактически заняла на 14.5 недель. Очевидно, что пока не получается просто поручить задачу агентам и пойти лежать на диване. Приходится проверять работу, вносить корректировки и так далее.
2. Переписываемый проект должен быть покрыт E2E тестами вдоль и поперек. У Copilot было много таких тестов, но даже это не помогло от регрессии.
Microsoft выкатывали pre-release версии в продакшн, чтобы протестировать на реальных пользователях и дополнительно исправляли обнаруженные баги.
3. «Чатжипити, перепиши мне проект на Rust» всё ещё не работает.
Разработчикам необходимо было отлично понимать архитектуру проекта для грамотного планирования миграции.
Кроме того, разработчикам иногда приходилось детально и на довольно низком уровне описывать желаемый результат из-за того, что агенты делали не то, что требуется.
Короче, программировать пока ещё надо уметь.
#программирование@yet_another_dev
1. Потрачено $120К, а агенты суммарно отработали около 3-х недель. Вся работа фактически заняла на 14.5 недель. Очевидно, что пока не получается просто поручить задачу агентам и пойти лежать на диване. Приходится проверять работу, вносить корректировки и так далее.
2. Переписываемый проект должен быть покрыт E2E тестами вдоль и поперек. У Copilot было много таких тестов, но даже это не помогло от регрессии.
Microsoft выкатывали pre-release версии в продакшн, чтобы протестировать на реальных пользователях и дополнительно исправляли обнаруженные баги.
3. «Чатжипити, перепиши мне проект на Rust» всё ещё не работает.
Разработчикам необходимо было отлично понимать архитектуру проекта для грамотного планирования миграции.
Кроме того, разработчикам иногда приходилось детально и на довольно низком уровне описывать желаемый результат из-за того, что агенты делали не то, что требуется.
Короче, программировать пока ещё надо уметь.
#программирование@yet_another_dev
👍7
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13😁3🤷♂2🤡2💯2🤷♀1
Мы пришли в 7:50 и очередь уже была 🥲
Пообщались с другими людьми. Многие приехали из других городов Сербии. Кто-то с 6:30 уже был тут. Это вызывает только уважение.
Очередь мы прошли быстро. К 12, возможно, она увеличится.
Пообщались с другими людьми. Многие приехали из других городов Сербии. Кто-то с 6:30 уже был тут. Это вызывает только уважение.
Очередь мы прошли быстро. К 12, возможно, она увеличится.
👍10🔥2
Опубликовал вчера ролик в одной запрещённой в России соцсети про то, как сходил на выборы.
Видео максимально беззубое. Я не упоминал названия партий, не давал им оценку, не рассказывал как голосовал. Просто рассказал что пошёл на избирательный участок, показал людей.
Видео взлетело на 43К просмотров. Алгоритмы там всё-таки хорошо работают.
И без срача в комментах не обошлось, конечно же. Отобрал для вас самое интересное на скринах. :)
Собственно, как я и говорил, обыватель в любом случае крайний.
Но большая часть комментариев (140+) была поддерживающая, что не может не радовать. Жаль, что это не помогло.
Видео максимально беззубое. Я не упоминал названия партий, не давал им оценку, не рассказывал как голосовал. Просто рассказал что пошёл на избирательный участок, показал людей.
Видео взлетело на 43К просмотров. Алгоритмы там всё-таки хорошо работают.
И без срача в комментах не обошлось, конечно же. Отобрал для вас самое интересное на скринах. :)
Собственно, как я и говорил, обыватель в любом случае крайний.
Но большая часть комментариев (140+) была поддерживающая, что не может не радовать. Жаль, что это не помогло.
❤8😁7🤡2
Как я фиксил ошибки SonarQube и Roslyn при помощи ИИ-агентов
Несколько дней назад я провёл эксперимент с одним из наших легаси проектов. Это внутренний сервис, который был написан 3 года назад. С тех пор к нему никто не прикасался. В продакшене выполнялись только обновления райнтайма.
Это относительно небольшой проект с 11 тыс. строк кода. При этом в нём было более 500 ошибок (issue) от SonarQube и Roslyn.
Чего я хотел добиться
SonarQube – это инструмент, который мы используем для статического анализа код. Мы также стараемся поддерживать “чистоту” в репозиториях, чтобы не накапливался технический долг. Но конкретно этот проект был разработан давно, ещё до того, как мы интегрировали SonarQube в наши CI-CD-пайплайны. Поэтому в нём накопилось много проблем.
Большинство проблем были безобидными. Например, название приватного поля не соответствует правилам, или приватное поле без ключевого слова readonly, или внутренний метод без доступа к внутренним параметрам, который можно объявить статическим, и так далее.
То есть большинство проблем можно легко исправить вручную, но, тем не менее, на это требуется время, а сама задача скучная и монотонная.
Harness и LLM
Я использовал GitHub Copilot потому, что мой работодатель предоставляет подписку. Думаю, аналогичный подход можно реализовать и с помощью любого другого агента.
В качестве LLM я выбрал GPT-6 Luna. Это одна из самых дешёвых моделей в GitHub Copilot. Параметры модели были по умолчанию: размер контекстного окна в 272K токенов и средний уровень ризонинга.
Про итоговую стоимость рассказано в конце.
Кастомный агент
Я потратил какое-то время на написание промпта для агента и помимо базовых инструментов VS Code и GitHub Copilot, я выдал агенту доступ к SonarQube MCP и Microsoft Learn MCP для чтения их документации.
Финальная версия агента работала в две фазы.
Фаза 1. Подготовка
Агент собирает все доступные проблемы SonarQube для текущего репозитория и ветки. SonarQube MCP возвращает результаты постранично. Поэтому агент должен преобразовать эти результаты в единый JSON-файл с полным списком проблем.
Чтобы уменьшить размер файла, я оставил только необходимую информацию:
- GUID проблемы;
- код проблемы;
- путь к файлу;
- номер строки в файле;
- краткое описание.
Фаза 2. Цикл
1. Агент читает JSON-файл и ищет первую нерешённую проблему.
2. Затем он ищет информацию о проблеме в документации через SonarQube MCP или Microsoft Learn MCP, чтобы найти наиболее подходящий способ исправления.
3. После того вся необходимая информация собрана, он исправляет проблему, помечает соответствующий элемент в JSON-файле как FIXED и делает commit с результатами. После этого цикл повторяется.
Оценка трудозатрат
SonarQube оценивал необходимые трудозатраты в 3 рабочих дня и 3 часа. Но 289 проблем не имели оценки времени – SonarQube просто указывал для них 0 min, что, на мой взгляд, неправильно.
Даже самая маленькая проблема вроде «пометить поле как readonly» требует одной-двух минут на исправление: открыть портал SonarQube, найти проблему, найти файл и нужное место в файле, понять контекст и наконец внести исправление.
В общей сложности я оценил, что для исправления всех 500+ проблем человеку бы понадобилось около 1 рабочей недели, с учётом того, что разработчику нужны перерывы на кофе, туалет и обед.
Результаты
Я запустил агента 1 октября 2026 года в 10:28 (четверг). Последняя проблема была исправлена 2 октября 2026 года в 15:24 (пятница). Но агент не работал всё это время непрерывно – несколько раз его работа прерывалась.
Один раз возникла временная проблема с сетью. Пришлось запускать агента вручную.
Я также остановил агента в конце рабочего дня в четверг. Мне пришлось это сделать, потому что по пятницам я работаю из дома и мне нужно было забрать ноутбук домой.
Когда я приехал домой, то снова запустил цикл, и работа продолжалась до 2:00 ночи, после чего агент остановился, потому что не смог запустить субагента для поиска следующей проблемы. Утром пришлось снова запускать агента вручную.
Позже проблема с вызовом субагента возникла ещё несколько раз. Я попытался сделать промпт более надёжным, добавив конкретные инструкции о том, как вызывать сабагента корректно, но это не особо помогло.
С периодическими ручными вмешательствами агент продолжал работать и в 15:24 закончил работу.
В результате получился MR из 554 коммитов. Было изменено 171 файлов. Мы потратили 1402 кредитов, что примерно эквивалентно $14.
Я проверил большую часть изменений и не заметил никаких проблем. Пайплайн зелёный. Можно считать, что ИИ хорошо подходит для таких подоизменений в коде.
#программирование@yet_another_dev
Несколько дней назад я провёл эксперимент с одним из наших легаси проектов. Это внутренний сервис, который был написан 3 года назад. С тех пор к нему никто не прикасался. В продакшене выполнялись только обновления райнтайма.
Это относительно небольшой проект с 11 тыс. строк кода. При этом в нём было более 500 ошибок (issue) от SonarQube и Roslyn.
Чего я хотел добиться
SonarQube – это инструмент, который мы используем для статического анализа код. Мы также стараемся поддерживать “чистоту” в репозиториях, чтобы не накапливался технический долг. Но конкретно этот проект был разработан давно, ещё до того, как мы интегрировали SonarQube в наши CI-CD-пайплайны. Поэтому в нём накопилось много проблем.
Большинство проблем были безобидными. Например, название приватного поля не соответствует правилам, или приватное поле без ключевого слова readonly, или внутренний метод без доступа к внутренним параметрам, который можно объявить статическим, и так далее.
То есть большинство проблем можно легко исправить вручную, но, тем не менее, на это требуется время, а сама задача скучная и монотонная.
Harness и LLM
Я использовал GitHub Copilot потому, что мой работодатель предоставляет подписку. Думаю, аналогичный подход можно реализовать и с помощью любого другого агента.
В качестве LLM я выбрал GPT-6 Luna. Это одна из самых дешёвых моделей в GitHub Copilot. Параметры модели были по умолчанию: размер контекстного окна в 272K токенов и средний уровень ризонинга.
Про итоговую стоимость рассказано в конце.
Кастомный агент
Я потратил какое-то время на написание промпта для агента и помимо базовых инструментов VS Code и GitHub Copilot, я выдал агенту доступ к SonarQube MCP и Microsoft Learn MCP для чтения их документации.
Финальная версия агента работала в две фазы.
Фаза 1. Подготовка
Агент собирает все доступные проблемы SonarQube для текущего репозитория и ветки. SonarQube MCP возвращает результаты постранично. Поэтому агент должен преобразовать эти результаты в единый JSON-файл с полным списком проблем.
Чтобы уменьшить размер файла, я оставил только необходимую информацию:
- GUID проблемы;
- код проблемы;
- путь к файлу;
- номер строки в файле;
- краткое описание.
Фаза 2. Цикл
1. Агент читает JSON-файл и ищет первую нерешённую проблему.
2. Затем он ищет информацию о проблеме в документации через SonarQube MCP или Microsoft Learn MCP, чтобы найти наиболее подходящий способ исправления.
3. После того вся необходимая информация собрана, он исправляет проблему, помечает соответствующий элемент в JSON-файле как FIXED и делает commit с результатами. После этого цикл повторяется.
Оценка трудозатрат
SonarQube оценивал необходимые трудозатраты в 3 рабочих дня и 3 часа. Но 289 проблем не имели оценки времени – SonarQube просто указывал для них 0 min, что, на мой взгляд, неправильно.
Даже самая маленькая проблема вроде «пометить поле как readonly» требует одной-двух минут на исправление: открыть портал SonarQube, найти проблему, найти файл и нужное место в файле, понять контекст и наконец внести исправление.
В общей сложности я оценил, что для исправления всех 500+ проблем человеку бы понадобилось около 1 рабочей недели, с учётом того, что разработчику нужны перерывы на кофе, туалет и обед.
Результаты
Я запустил агента 1 октября 2026 года в 10:28 (четверг). Последняя проблема была исправлена 2 октября 2026 года в 15:24 (пятница). Но агент не работал всё это время непрерывно – несколько раз его работа прерывалась.
Один раз возникла временная проблема с сетью. Пришлось запускать агента вручную.
Я также остановил агента в конце рабочего дня в четверг. Мне пришлось это сделать, потому что по пятницам я работаю из дома и мне нужно было забрать ноутбук домой.
Когда я приехал домой, то снова запустил цикл, и работа продолжалась до 2:00 ночи, после чего агент остановился, потому что не смог запустить субагента для поиска следующей проблемы. Утром пришлось снова запускать агента вручную.
Позже проблема с вызовом субагента возникла ещё несколько раз. Я попытался сделать промпт более надёжным, добавив конкретные инструкции о том, как вызывать сабагента корректно, но это не особо помогло.
С периодическими ручными вмешательствами агент продолжал работать и в 15:24 закончил работу.
В результате получился MR из 554 коммитов. Было изменено 171 файлов. Мы потратили 1402 кредитов, что примерно эквивалентно $14.
Я проверил большую часть изменений и не заметил никаких проблем. Пайплайн зелёный. Можно считать, что ИИ хорошо подходит для таких подоизменений в коде.
#программирование@yet_another_dev
👍6
Так-с, важный вопрос. Каким облачным хранилищем вы пользуетесь? Я в 22 году переехал в Яндекс Диск из-за того, что не мог оплачивать Google Drive. Чувствую, что пришло время переезжать в другое место.
😁3❤2🔥1💯1
yet another dev
Так-с, важный вопрос. Каким облачным хранилищем вы пользуетесь? Я в 22 году переехал в Яндекс Диск из-за того, что не мог оплачивать Google Drive. Чувствую, что пришло время переезжать в другое место.
Мы выбрали Google Drive. У них более менее адекватный ценник и, в целом, знакомая экосистема. Хочу мигрировать данные асап. А серваком можно заняться позднее.
Я ещё рассматривал Proton, но у них плохая интеграция с rclone, да и ценник почти в 2 раза выше, чем у Google.
Подписка на Google One 2 Тб стоит $100 в год. Хранилище можно пошарить с членами семьи. В итоге, выходит где-то 2-3 раза дороже, чем Яндекс Диск.
Данные мигрирую при помощи rclone. Интеграция с Яндексом у него прекрасная. А вот с Google пришлось повозиться – доступ к Drive только через API, который включается через Google Cloud Console, а ещё там надо настраивать креды и т.д.
Кстати, важный момент о котором я не знал. В мобильном приложении Яндекс Диска есть функция автозагрузки фото и видео. И они могут загружаться в так называемое "безлимитное хранилище".
Прикол в том, что это безлимитное хранилище существует отдельно от Яндекс Диска и поэтому rclone его не видит.
Я вчера потратил несколько часов перенося вручную фотографии по 500 штук (лимит Яндекса) из безлимитного хранилища на Диск. Какого-то удобного инструмента для этого в приложении и веб-версии конечно же не предусмотрено.
Я ещё рассматривал Proton, но у них плохая интеграция с rclone, да и ценник почти в 2 раза выше, чем у Google.
Подписка на Google One 2 Тб стоит $100 в год. Хранилище можно пошарить с членами семьи. В итоге, выходит где-то 2-3 раза дороже, чем Яндекс Диск.
Данные мигрирую при помощи rclone. Интеграция с Яндексом у него прекрасная. А вот с Google пришлось повозиться – доступ к Drive только через API, который включается через Google Cloud Console, а ещё там надо настраивать креды и т.д.
Кстати, важный момент о котором я не знал. В мобильном приложении Яндекс Диска есть функция автозагрузки фото и видео. И они могут загружаться в так называемое "безлимитное хранилище".
Прикол в том, что это безлимитное хранилище существует отдельно от Яндекс Диска и поэтому rclone его не видит.
Я вчера потратил несколько часов перенося вручную фотографии по 500 штук (лимит Яндекса) из безлимитного хранилища на Диск. Какого-то удобного инструмента для этого в приложении и веб-версии конечно же не предусмотрено.