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 штук (лимит Яндекса) из безлимитного хранилища на Диск. Какого-то удобного инструмента для этого в приложении и веб-версии конечно же не предусмотрено.
Мне удалось скопировать в Google Drive практически все данные с Яндекс Диска. Осталось только 3 файла, которые всё ещё недоступны.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
🫡4😱3👀3👍2