Почему SOLID?

Почему именно SOLID считается базовыми принципами разработки? Почему именно пять? Почему именно эти пять?

Я думаю, что за основной причиной нужно идти в словарь. Solid — крепкий, твёрдый, надёжный, серьёзный. Роберт Мартин хотел, чтобы принципы легко запоминались — у него это получилось)

Приведу пару аргументов.
I — interface segregation — принцип, конечно, полезный. Но технический по сути, а главное — является частным случаем S — single responsibility.
S, O, D — могут применяться как на уровне классов, так и на уровне модулей приложения.
L — это уровень классов, накладывает на них более строгие требования, чем обеспечивают «из коробки» ООП языки.

Есть ещё полезные принципы — DRY, KISS, которые сюда не попали.

Из всего вышесказанного никак не следует, что SOLID-принципы плохие. Я о том, что их на самом деле больше.

#solid

k8s HPA бесполезен? Или нет?)

Я уже писал о возможности масштабировать поды горизонтально через компонент HPA — Horizontal Pod Autoscaler. Он собирает метрики загрузки пода (границы можно настраивать) и меняет число реплик в заданных границах.

Круто? Да. Но есть одно «но». В namespace ресурсы часто прибиты гвоздями. Один namespace = один микросервис. Микросервис имеет некие бизнес-требования по нагрузке, проходит нагрузочное тестирование и получает некоторое количество ресурсов. Хуже того — кластер, в котором находится namespace, тоже имеет жёсткое ограничение по ресурсам. Это частное, небольшое по сравнению с cloud-провайдерами облако. Лишним node взяться неоткуда. Поэтому HPA в частном облаке бесполезен. Все ресурсы уже забронированы. От того, что часть из них уберут из балансировки, ни холодно ни жарко. Только замедление при старте пода.

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

Что можно сделать в частном облаке? Например, вот так: https://youtu.be/GWJ9rDrsBdQ?si=dx-VHMlIIYKo2g4q Кейс не универсальный, но если есть свой кластер и понятно, что в нём будут жить приложения с разными пиками нагрузки — потребление ресурсов можно оптимизировать. Как развитие идеи — автоматическая генерация рекомендаций по настройке кластера.

#k8s #optimization

live coding это все-таки кодинг

Недавно писал про то, что на сессии live coding на собесе не надо сразу браться за задачу, вначале стоит позадавать вопросы и продумать путь решения задачи.

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

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

В общем не делайте так

#interview #interview_fails

code style бывает разный

Меня сложно чем-то удивить в области разработки. Но недавно, изучая разные code style, я решил посмотреть, какие бывают варианты расположения фигурной скобки. Изначально в моём понимании их два - на одной строке с управляющей конструкцией и с новой строки. Но жизнь оказалась богаче любых ожиданий:
https://en.m.wikipedia.org/wiki/Indentation_style
Девять! Девять, Карл!

Хотя в Java наиболее распространён один, пришедший из C, от Кернигана и Ричи.

Вывод будет такой. Не важно сколько разных code style существует, важно, чтобы в проекте использовался один. А это значит .editorconfig https://editorconfig.org/ и автоматическое форматирование в Actions on Save в IDEA.

#code_style #idea

Небольшая заметка к предыдущему посту.

Может возникнуть вопрос: зачем нужно сохранять настройки форматирования, он же code style,  в отдельном файле, если правильные настройки есть в IDEA по умолчанию? И изучать, пусть и поверхностно, пусть и достаточно простой формат настроек .editorconfig? Стоит ли игра свеч?

Мой ответ: да.

Во-первых, не все пользуются стандартными настройками IDEA. Во-вторых, они от версии к версии могут меняться. А единый code style — основа для комфортной и быстрой работы ревьювера. Почему важно code review — говорить не буду.

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

Второй вопрос — ведь IDEA тоже позволяет сохранять часть своих настроек, в том числе и настройки стиля кода. Как я вижу, эта опция не пользуется популярностью среди разработчиков, и я по данному вопросу с ними солидарен. Причин две: есть сомнения, что нужно сохранять именно этот набор — слишком уж много там файлов. И есть сомнения в совместимости между версиями IDEA, и особенно между её сборками (я про GigaIDE и аналоги). Не говоря уже о других IDE, типа VSCode.

P.S. И всё равно приличный объём поста получился.

#ide #codestyle #eac

Популярность ChatGPT

Недавно читал комментарии в телеге и понял, что ChatGPT, или в конкретном случае DeepSeek, уже стали мейнстримом.

Как я это понял?

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

Так вот, наши дни. В комментариях обсуждают CAP-теорему. Не слишком ли она теоретическая, стоит ли вообще обсуждать partitioning, если реальных систем, для которых partitioning (временное разделение распределённой системы на части, обмен информацией между которыми нарушен) является допустимым режимом, нет? Т. е., если P из CAP нам нужен всегда, то можно это зафиксировать и обсуждать выбор между consistency и availability.
И в комментарии пришёл человек и написал: зачем всё это обсуждать, ведь даже DeepSeek-у всё ясно. Если вероятность, что это был бот, но, к сожалению, скорее всего человек.

Вывод будет такой: да, ИИ отбирает аудиторию у блогов и поиска, но не всегда приводит к прорыву.

#ai

PHP становится Java-ой?

Недавно посмотрел видео о перспективах PHP https://vkvideo.ru/video-224967259_456239053 Я на PHP писал мало, но т.к. он широко распространён - интересно, развивается ли он и как именно. Он развивается, и я этому не удивлён. Да, есть распространённое негативное мнение про PHP и его разработчиков. Любой простой язык привлекает непрофессионалов. Но ситуация сложнее, чем кажется, на это намекает официальный code style языка https://php-psr.ru/accepted/PSR-12-extended-coding-style-guide/ Обязательность строк разделителей, фиксированное число пробелов, регистр символов - все серьёзно. Небольшое отступление - к аббревиатуре PSR из статьи выше мы ещё вернёмся.

Так вот, PHP становится похожим на Java.

Чтобы понять как именно - стоит вспомнить, чем он характеризовался изначально?

1) динамическая типизация. От неё уходят, с костылями в виде объявления типов в комментариях и проверке статическим анализатором типа checkstyle. Причина - невозможно работать со сложным проектом и динамической типизацией. Если ты конечно не хочешь "гов..кодить".

2) интерпретация вместо компиляции. Тоже уходят, есть AOT и JIT компиляторы PHP. Также фреймворки, например, IoC контейнеры, могут предварительно сохранять конфигурацию на диске. По соображениям производительности

Да, в PHP тоже есть IoC контейнеры.

3) малоизвестный факт - исходно в PHP была т.наз умирающая модель процессов. После обработки запроса клиента контекст процесса полностью очищается. Такой true stateless. Причём очищались не просто клиентские данные, а все бины IoC контейнера, т.е. вообще все. Побочные эффекты такого подхода противоположные. Положительный: PHP компоненты инициализируются очень быстро, по другому никак. Отрицательный: на утечки памяти можно забить, т.е. "гов...кодим") Так вот, от этой модели тоже уходят. Снова по соображениям производительности

В общем язык развивается, т.к. наследие огромное.

P.S. Чтобы не было пренебрежительного отношения к PHP - поговорим про стандартизацию. В PHP есть такое понятие, как middleware. Вот его неплохое описание https://laravel.com/docs/12.x/middleware
Ключевой момент - компоненты middleware переиспользуются в различных фреймворках. Как это получается? Потому что многое стандартизируется, с помощью PSR. В Java тоже есть стандарты - JPA, JDBC,  http сервлеты и фильтры, но видится, что их меньше. Когда-то этим занимался проект Java EE, не смог, умер и воскрес, а за это время возникло несколько экосистем - Spring, Quarkus, Micronaut... И это я Kotlin не беру) Почему я назвал их экосистемами - каждая старается привязать к своим компонентам. Так что как ни странно - PHP выглядит более стандартизированным)

#java #PHP #lang

Пару заметок про SonarQube

Изучая тему статического анализа кода зашел на сайт SonarQube и отметил для себя две новые фичи.

1) SonarQube может полноценно работать локально, в IDE, без сервера. Работа с сервером называется сonnected mode https://docs.sonarsource.com/sonarqube-for-ide/intellij/team-features/connected-mode/ Соответственно, есть еще и not connected mode, он же локальный режим.
Отличаются они списком поддерживаемых языков и правил https://docs.sonarsource.com/sonarqube-for-ide/intellij/using/rules/ Java и Kotlin поддерживаются в локальном режиме. Для connected режима фичей, естественно, больше. В частности добавляются проверки, связанные с безопасностью. То ли с сервера подтягивается динамический список уязвимостей, то ли безопасность = enterprise, а значит пусть платят) Плюс появляется возможность централизованного управления Quality Profile и Quality Gate, статистика, историчность сканирования и работа с false positive багами. Что важно - SonarQube Server есть в Open Source варианте

2) В сonnected режиме доступна фича AI CodeFix https://docs.sonarsource.com/sonarqube-for-ide/intellij/using/ai-capabilities Это фиксы, предлагаемые плагином SonarQube в IDEA. Работают для примерно 120 из 700 существующих проверок в Java. Kotlin пока не поддерживается, но думаю скоро добавят. Из очевидного - фича доступна только в платной версии. Если подумать - фича прямо напрашивалась. Сам ее пока не пробовал, и поэтому возникает два вопроса:
а) всегда ли будет компилироваться код после применения фикса?
б) по AI фиксы нужны только там, где детерминированная логика не работает. А зачем он, например, вот тут https://rules.sonarsource.com/java/RSPEC-1612/ ?

#ai #idea #static_analysis

MCP - новая модная аббревиатура

У меня уже был пост про MCP в Spring AI. Но теория теорией, но для чего эта штука нужна - MCP - не до конца была понятно даже мне.
Но вот хороший и актуальный пример: https://t.me/yegor256news/1625

P.S. Автора кстати рекомендую, если кто до сих пор вдруг его не знает)

#ai #mcp

Пару очевидных? заметок про AI чат-ботов

Стал больше пользоваться AI — Perplexity, Deepseek, GigaCode — и захотелось суммировать новые впечатления.

1) Очень важно найти более-менее умного AI-помощника. Тогда возможен качественный рост эффективности. Что имею в виду? Если AI явно косячит, отношение к нему остаётся настороженным, а использование — точечным. Помощь есть, но прямого рывка эффективности не будет. В целом, и по Stack Overflow можно достаточно быстро искать ответы. Но если ответы адекватные, рассуждения логичные и подкреплены ссылками, AI может стать твоим личным джуном, которому можно отдать часть работы. Причём даже джуном джуна)

2) Обратная сторона медали — AI врёт, что называется, в глаза. Таков принцип его работы: не хватает знаний — создай ответ из чего-то похожего. Но это одна часть проблемы. Вторая — невозможно понять, где в ответе точные знания, а где — предположения. Третья часть проблемы: на неверных предположениях модель строит дальнейшие ответы.Если, конечно, ей сразу не сказать, что не так. Тут в теории должны работать промпты типа: «ничего не придумывай», но кажется, не всегда работают. Буду копать дальше.

3) Рассуждающие модели, а этот режим, думаю, появится у всех в обозримом будущем, сильно помогают в вопросе доверия к модели. Но см. пункт 2: если плохо знаешь предметную область и не заметишь вовремя ошибку в ответе — получим вывод на основе ложных предпосылок. И в итоге может быть очень больно.

4) Я как-то написал саркастический пост про то, что ИИ позиционируют для проведения исследований. Так вот, уточнение: если исследование на стыке известного и нового — как раз тут может быть максимальный выигрыш от ИИ. И раскопать тему можно в разы быстрее, так как большую часть работы по подбору ссылок и составлению резюме делает модель, и вовремя остановить галлюцинации можно. Более того, кажется, что тот же Deepseek специально делали для исследований: таблички, диаграммы…

P.S.Когда в ответе Deepseek, а точнее, в его рассуждениях, я в десятый раз вижу фразу: «Видно, что пользователь хорошо разбирается в теме», — возникают подозрения. Уж не хочет ли модель втереться в доверие? Восстание Скайнета не за горами?)))


#ai

skip level в ИТ

О чем речь? Не о том, как из джуна стать сеньором, не уверен, что это возможно) А об обращении к вышестоящему руководителю.
Причем кейсы могут быть разные, т.к. часто есть две иерархии - продуктовая\проектная и ИТ-ная. PO и ИТ лид. Прожект и тимлид.

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

1) системная проблема в проекте или команде. Тогда "жаловаться" можно и нужно, если проблема будет решена - плюсы в карму и не только в карму)

2) проблема личного развития. Тут есть важная развилка. Она решается следующим вопросом: что я сделал для своего развития?

а) если ответ: я хочу заниматься Х и получить за это У, но злой продакт меня не понимает, пойду к ИТ лиду, чтобы он заставил продакта меня развивать - то это напоминает поведение трехлетнего ребенка. Мама не дала конфетку, пойду к папе. Что делать с ребенком - ничего, ребенок же. Что делать с ИТ-шником - это очень серьезный звоночек на то, что нам с ним не по пути.

б) если же ответ: я сделал уже вот это, учусь, готов учиться еще больше, но все без толку ... - это уже тема для предметного разговора. И опять же плюс в карму.

#it_career

Как внедрить AI?

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

1) достаточность набора данных. Много данных - хорошая статистика, точные ответы. Мало данных - точность ответов падает, галлюцинации растут. Вторая проблема маленького объема данных - если данных мало, то возможно алгоритм все же детерминированный, а значит проблема решается кучей if без всякого AI. Ну хорошо, кучей if, разделенных на несколько методов\классов по принципу SRE) Хотя и тут для AI остается ниша распознавания человеческой речи и маппинга запроса на API.

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

Но конечно же, хоронить на AI в финансах не надо, надо искать)

#ai

Таска или баг - в чем разница?

Недавно прочитал интересную мысль у Егора Бугаенко - https://www.yegor256.com/2025/05/25/bug-driven-development.html
И как всегда, она не только интересная, но и провокационная)

Суть - давайте откажемся от типов задач, и все, в т.ч. и таски сделаем багами. Мотивация - баги в любом случае нужно править, а таски - ну такое. Таску можно поморозить в бэклоге на несколько месяцев, а потом выкинуть под соусом: уже неактуально.
Да, вопрос можно ли такое сделать конкретно в вашей организации - оставляю за скобками. Раз нельзя, то нельзя)

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

Но с другой стороны - мотивированная команда здесь первична. Если команда не хочет брать таску - она отобьет ее в любом виде. CR, таска, баг. Т.е. улучшить Lead Time и навести порядок в бэклоге это не поможет. Если команде удобнее работать только с багами - ок. Но продвигать такую практику как решение проблем - сомнительно, не ок)

#task_management #agile

Сколько языков можно запустить на JVM?

Скорее всего, кроме собственно Java большинство вспомнит Kotlin и Scala. Еще возможно Groovy - хотя Groovy, созданный как язык общего назначения, сейчас стал нишевым языком для реализации DSL: Gradle, Jenkins как самые известные примеры.
Но JVM - это не только слой абстракции на операционной системой, позволяющий не думать о поддержке разных процессорных архитектур, операционных систем, оптимизациях, сборке мусора, профилировании и многом другом. Благодаря всему вышеперечисленному JVM дает возможность всем желающим (ладно, не всем, а умеющим и желающим)))) придумать свой язык программирования. Или перенести существующий на JVM.
Вот список https://en.wikipedia.org/wiki/List_of_JVM_languages
Да, я подозреваю половина из этих языков уже мертва. Но найти там можно почти все: Python, Go, PHP, Ruby, JS и даже таких старичков как Cobol, Delphi, Visual Basic и Lisp.

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

P.S. Virtual machine по большому счету реализовали 2 крупные компании: Sun\Oracle и Microsoft. Причем .NET реализация - CLR - выглядит проще JVM, в частности JIT - Just in Time - компиляция там происходит при старте программы, а не по мере накопления статистики использования кода в runtime. Но у .NET тоже неплохой список поддерживаемых языков https://ru.wikipedia.org/wiki/Список_.NET-языков

P.P.S. Вначале хотел написать, что портировать С, C++ или Rust на виртуальную машину смысла нет, но потом вспомнил про .NET))) Хотя Managed C++ явно отличается от обычного C++ в плане работы с памятью, но он есть.

#lang

Можно ли писать код без багов?

Сразу после прочтения этого поста: https://korshakov.com/posts/no-bugs захотелось написать свой пост на пост)
Потом появился неплохой комментарий https://t.me/rybakalexey/190 и кажется - что тут добавить?
Прошло время, и я понял, что именно)

Вкратце содержимое предыдущих серий:
1) писать без багов, ладно с минимальным количеством багов, можно
2) для этого нужно начать заставлять себя постоянно улучшать код до тех пор, пока это не станет привычкой
3) первое время это замедлит разработку, потом скорость вернется в норму

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

Я бы хотел добавить немного практики - на что можно обратить внимание.

0) нулевой пункт - потому что очевидный. Следование практиками чистого кода. Ключевой момент - понятные наименования и читаемость. Нет читаемости - нет понимания, как код работает, легче допустить ошибку при модификации.

0.5) еще один нулевой пункт - модульные тесты. Тесты - это основная страховка при рефакторинге и серьезных изменениях в архитектуре. Без тестов проект сразу становится legacy.

1) TDD. Какая связь с багами? Через тесты, конечно. Если тесты пишутся после кода - всегда есть риск, что из-за сдвинувшихся сроков на тебя надавят и заставят отдать фичу на тестирование как есть. А это баги и вообще говоря еще больший сдвиг сроков. Но объяснить это менеджеру сложно. Если же тесты пишутся до кода - гнать в ПРОМ фичу без части функционала никто не будет. Хотя может быть и стоило рассмотреть именно такой вариант)

2) Управление техдолгом. Он возникает, когда вот прямо сейчас сделать все красиво не получается - https://t.me/javaKotlinDevOps/312
Ключевая мысль - техдолг нужно оцифровывать. Как TODO, как таски, как TODO превращенные роботом в таски - не важно. Главное, что техдолг записан, после чего потерять его станет сложнее. Улучшится прозрачность, появится артефакт для обсуждения с командой и планирования исправления техдолга. Голова разработчика - хорошо, но нет) Опять же: есть бизнес, у него есть новые фичи, меняются люди - в итоге благие намерения ими и остались, техдолг забыт, архитектура и код медленно превращается в "большой ком грязи".

3) Интеграционные тесты разработки (не путать с тестами тестировщиков!). Суть простая - модульные тесты не дают ответа на вопрос: "Работает ли приложение в целом?" Потому что они модульные, они тестируют какой-то небольшой кусочек, а не "костюм в сборе". Поэтому хотя бы парочка таких тестов нужна, чтобы отловить потенциальные баги раньше. Не слишком много, иначе время отладки затянется.

4) Качественное ручное и автоматическое код-ревью. Некачественное - это замечания типа добавь комментарий к конструктору в SonarQube или скоростное код-ревью за 5 секунд от коллеги. Ни первая, ни вторая практика не найдут всех ошибок. Может даже и половины не найдут. Но какие-то найдут, и это в итоге сделает код лучше. Поэтому профиль SonarQube или другого анализатора нужно настраивать "под себя", все найденные им баги править. О ручном код-ревью договариваться с коллегами, PO или ИТ лидом чтобы на это выделялось время. Ну и соблюдать рекомендации по pull requests https://t.me/javaKotlinDevOps/148

5) внимание к вопросам сопровождения, понимание их болей. Идеально конечно было бы you build it - you run it, но не везде это возможно. Сопровождение - по крайней мере там, где я это видел - работа достаточно стрессовая. Поэтому система должна быть максимально простой в плане сопровождения. Это значит: инструкция по внедрению, понятные и актуальные наименования, необходимый минимум настроек, логи без мусора, метрики и трейсы, наличие рубильников ("feature toggle"), rate limiters, быстрое время старта пода. Иначе - баги и инциденты ПРОМа.

6) время на уборку мусора. GC тут не поможет, речь о мусоре в проекте. Это могут быть настройки https://t.me/javaKotlinDevOps/328, это может быть неиспользуемый функционал или просто лишние библиотеки. Про это часто, даже откровенно говоря почти всегда, забывают

Пока все, думаю еще со временем накину)

#no_bugs

Писать код без багов - продолжение

Важное дополнение по интеграционным тестам, спасибо Женя!
Интеграционный тест разработки - это с большой вероятностью аналог некого тест-кейса тестировщика. Поэтому если возникают вопросы: "Какие интеграционные тесты нужны?" - можно спросить у тестировщика. А в некоторых компаниях такая практика включена в релизный цикл - тестировщик контролирует набор интеграционных тестов разработки. Они могут при этом называться системными (СТ), но названия разных видов тестов - это отдельная больная тема)

7) заглушки для отладки. Казалось бы - что тут можно улучшить, заглушки и заглушки. Важный момент - они должны вести себя аналогично реальной системе. Например, в плане фильтрации данных.

8) НТ - нагрузочное тестирование. Если разработчик не интересуется этим вопросом, ведь есть специально обученные люди - команда НТ - то риски следующие. Во-первых НТ может показать, что архитектура системы неверная, и показать слишком поздно. Во-вторых, для НТ-шников ваш сервис - черный ящик. Не понимая внутренностей системы что они могут порекомендовать? Увеличить квоты по CPU и памяти в k8s. Индексы в БД добавить. Это рабочий вариант, но также эти и путь к неоптимальной системе. Результаты НТ нужно разбирать вместе. Причем все, а не только когда сервис не тянет нагрузку из бизнес-требований. А в идеале - проводить свои мини-НТ заранее с помощью того же JMeter.

Пока все)

P.S. Может показать, что я забыл самое главное - проектирование. Но про него хорошо написал автор исходного поста - https://korshakov.com/posts/no-bugs

#no_bugs

Традиционная рубрика - новости AI)

Github таки выкатил AI джуна https://github.blog/changelog/2025-05-19-github-copilot-coding-agent-in-public-preview
За 40 баксов в месяц можно просто назначить тикет на Copilot, после чего провести ревью полученного Pull Request. Выглядит экономия на ЗП джуна в 20+ раз. И даже работает https://t.me/yegor256news/1648
Всем джунам приготовится)))

Я писал в одном из предыдущих постов - режим размышления и веб-поиск становится мейнстримом. Проверил - да, в том или ином виде они появились у всех AI ассистентов, которые попали в мое первое сравнение https://gitverse.ru/javadev/ai-tools-comparision/content/master/README.md. Разве что у GigaChat не нашел поиска, а у GigaCode - ни поиска, ни режима размышлений( Из особенностей - у Gemini и Microsoft Copilot поиск доступен не в AI ассистенте, а собственно в поиске - Google и Bing.

Из интересного - Gemini\Google стал наиболее сильно банить пользователей из России, смотрит на данные аккаунта Google, одного VPN не хватает. Даже переключение на США не помогает. Ну и ладно, не очень то и хотелось)

Новый тренд - специализированные креативные режимы. Подготовить презентацию, нарисовать картинку....

И еще один интересный момент. В свое время Роберт Мартин поднял очень важный вопрос - читаемости и сопровождаемости кода - в своей книге Чистый код. Да, я видел критику конкретных примеров кода из книги, но идеи оттуда IMHO всегда будут актуальны. Так вот - если присмотреться к генерируемому AI коду - многие принципы он выполняет. Названия понятные, Single Responsibility старается соблюдать. Тренировали модели я подозреваю на открытых проектах GitHub. И видимо фильтровали проекты, т.к. на GitHub традиционно выкладываются проекты всех входящих в ИТ)

#ai #ai_digest

(Не) храните большие бинарные файлы в git

Есть такое общеизвестное правило - никогда не храните большие бинарные файлы в git. Почему?
Причин несколько:

1) большие файлы как правило бинарные, а при работе с бинарными файлами мы теряем значительную часто возможностей git - просмотр diff-ов, да процесс code review в целом

2) git начинает тормозить при разрастании репозитория, а учитывая, что хранится вся история изменений - с большими файлами выйти на этот предел (десятки и сотни Gb, вот тут есть пример от Microsoft https://t.me/javaKotlinDevOps/272) уже значительно проще.

И если с первой причиной что-то сделать сложно, то для второй решение есть. И называется оно Git LFS https://git-lfs.com/

Для начала небольшая справка. При git clone скачивается следующая информация:

1) метаданные
а) настройки git
б) список существующих веток и тэгов

2) история коммитов по всем веткам (.git)

3) актуальные версии файлов в текущей ветке

Суть решения:

1) большие файлы хранятся отдельно от текстовых, с текстовыми файлами хранятся только ссылки на них. Переиспользуем возможности файловой системы Linux

2) при клонировании репозитория большие файлы копируются только для текущей ветки, что ускоряет загрузку

Главный вопрос - когда это все может понадобится? Видится такой вариант - хранить контент вместе с исходниками. Вообще контент лучше хранить в CMS, но, например, если есть тесная связь контента с релизом, то может иметь смысл хранить их рядом. Что точно не стоит хранить в git - так это jar-ники.

Еще важный момент - для того, что Git LFS заработал, нужно:
1) проинсталлировать его на сервере
2) включить на репозитории
3) добавить в репозиторий по маске список файлов, которые надо считать большими.
4) существующие файлы в LFS не попадают, их нужно добавить заново или мигрировать

В целом LFS работает прозрачно, но команды git lfs clone и git lfs pull оптимизированы для работы с LFS и загружают данные быстрее.

Проект open source и поддерживаемый, был создан усилиями заинтересованных лиц - GitHub, Bitbucket.

#git