Традиционная рубрика - новости 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

AI и leetcode

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

Что меняется с появлением AI?

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

2) с точки зрения сторонников данной практики ничего не меняется - такие задачки как проверяли способности к мышлению, проектированию и кодированию, так и проверяют. И я думаю, что они останутся на собесах

3) у противников данной практики основной аргумент усиливается. Если раньше можно было сказать - с вероятностью 90% мне это в реальной работе не понадобится, то сейчас цифра примерно равна 99%)

4) но возникает интересный момент. Вот решил кандидат за 1.5 часа 3 задачки. Даже 10 минут в резерве осталось. Появляется чувство: "А я хорош!)". Возникает мысль - интересно, а AI агент эти задачки решит. И агент решает их за 10 минут... И какие-то самые некрасивые мысли лезут ко мне в голову...

#ai #interview #algorithms

Предыдущий пост был немного провокационным)
Вынесу мой ответ на поставленный вопрос отдельно:

Алгоритмическое мышление - важный навык программиста. Но его проявление не исчерпываются вариантом - написать какую-то сложную сортировку за 30 минут. Сейчас проявление этого мышления уходит в сторону - приемочное тестирование кода, полученного от AI и вверх - проектирование: разбиение на микросервисы, на слои, классы, методы, разделение на код, который можно отдать AI, и код, который лучше написать самому.

#ai

И снова новости AI

В Spring AI появилась возможность работы с embeddings - https://www.baeldung.com/spring-ai-embeddings-model-api
Напомню, embeddings - векторное представление привычных нам текстовых, графических или аудио данных. Для чего нужно работать с embeddings - ведь мы можем общаться с моделью текстом, а все остальное она сделает сама?
Детали тут - https://habr.com/ru/companies/otus/articles/787116/
А если вкратце - например, с их помощью мы можем тренировать свою локальную модель. Или перейти от "программирования на русском языке" к более низкоуровневым операциям, теперь и на Java. Примеры таких действия: найти похожие слова, подставить недостающее слово.

#ai #spring #java

Надо задавать вопросы.

Есть такое понятие - "сеньорность". Синоним опыта разработки по сути, насмотренность.
Так вот, один из ее секретов - задавать правильные вопросы.

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

Потенциальные проблемы я вижу две:

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

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

#seniority

Что заменит AI?

Нашел очень хороший пример. Есть такая библиотечка - Datafaker https://www.datafaker.net/. faker - это обманщик если что) Генерирует правдоподобные тестовые данные: имена, улицы и т.д. с помощью разных провайдеров https://www.datafaker.net/documentation/providers/
Полезная штука. Сказал бы я год или два назад. А сейчас смотрим на историю версий https://www.datafaker.net/releases/2.4.2/ и видим, что в 2025 году что-то случилось. Новые версии перестали выходить.

Кейс очень похож на генерацию каркаса приложения https://t.me/javaKotlinDevOps/383, о которой я уже писал. Т.к. закодить можно счетное число вариантов генерации, а в LLM мы можем считать в неком приближении хранятся данные обо всем. Плюс она может что-то генерировать новое исходя из похожести данных. Хотя, последнее может как быть полезным, так и являться галлюцинацией)

#ai #rare_test_libs #unittests

Что возвращать при ошибке?

Какие есть варианты?
1) exception
2) false
3) Optional и аналоги
4) NullObject
5) null

Для начала я бы отбросил (ну или отложил для особых случаев) вариант с null. Он давно уже "проклят", как приводящий к NPE.

Оставшиеся варианты я предлагаю разделить на две группы - NullObject vs все остальные

Основная разница между ними - первый не требует немедленной обработки ошибок, другие - требуют. Отсутствие такого требования - это преимущество, т.к. дает нам гибкость. Если надо - проверили на ошибку сразу, не надо - позже. Но у гибкости есть обратная сторона - увеличивается сложность. Т.к. NullObject выглядит как настоящий объект - он может пролезть достаточно далеко по коду. Вплоть до сохранения в БД, где ошибка и произойдёт. Или не произойдёт, что видится ещё худшим вариантом. Итого - для отложенной обработки ошибок NullObject выглядит оптимальным даже учитывая описанные выше риски.

exception vs false vs Optional.

false плох тем, что не дает ничего вернуть из метода. Иногда это ок, но в общем случае - не ок. Ну и method chaining конечно же ломает.

exception vs Optional
Да начала exception бывают checked и unchecked. Первые с точки зрения обработки ошибок надёжнее - сложнее забыть обработать ошибку (если только использовать @sneakythrows и аналоги). Но checked exception имеют свои минусы, не даром нигде, кроме Java, они не прижились.

unchecked exception vs Optional
У exception есть один большой минус. Unchecked exception из чужого, плохо документированного кода, да к тому же возникающий редко - проблема, т.к. может дойти не до того уровня обработки ошибок, который планировался. Еще одна проблема - прерывание потока выполнения. Если этим злоупотреблять - имеем аналог go to, антипаттерн.С другой стороны exception  достаточно гибкий - можно отлавливать локально, на уровне сервиса или контроллера или на уровне фреймворка (Spring @ExceptionHandler). Код обработки ошибок может быть любым.
Плюсы Optional - его можно свести либо exception, либо к NullObject. Минусы - если захочешь тащить его выше - читаемость кода ухудшается. Т.е. Optional - это как правило короткоживущий объект. Он не совместим с JPA и с Java сериализацией. Еще важный минус - Optional не предоставляет средств для хранения деталей ошибки. Для меня минусы перевешивают плюсы. И судя по коду, который я вижу - не только для меня)

Если поставить вопрос: "Когда лучше обработать ошибку?" - то мой ответ: "Лучше сразу, это надёжнее".

Ну и традиционный итог: разработка - искусство  компромиссов)

#dev_compromises #null_safety #error_handling

Зачистка пропертей

Не люблю фразу "как я уже говорил". Ладно, кого я обманываю)
Но как я уже говорил - рефакторинг и чистка нужна не только коду, но и настройкам. https://t.me/javaKotlinDevOps/328
Проблема в том, что до настроек часто не доходят руки. По понятным причинам - код важнее.

Вот если бы проверку автоматизировать. Например, встроить в процесс сборки.

А пожалуйста https://www.baeldung.com/spring-properties-cleaner
Плагин работает со Spring Properties.

Умеет:
1) находить дубли
2) группировать по объекту настройки (по префиксу ключа настройки по сути)
3) выносить повторяющиеся настройки разных профилей в общий файл properties
4) повторяющиеся части - в отдельные настройки
5) форматировать и удалять лишние пробелы

В целом - рекомендую.

P.S. Искать неиспользуемые настройки не умеет. Но не все сразу)

#spring #configuration

Жонглирование JDK

Иногда нужно вести разработку нескольких сервисов, требующих разных версий JDK. Или нескольких релизов одного и того же сервиса. Или какое-то ПО на компьютере требует одной версии JDK, а разработка другой.
Все эти проблемы решает утилита jenv.
Неплохая статья по ней https://habr.com/ru/companies/surfstudio/articles/764442/

Прям скопирую оттуда абзац с ключевыми фичами:
1. Управление версиями Java: jenv позволяет установить и использовать несколько версий Java на одной машине.
2. Поддержка различных ОС: jenv может использоваться на macOS, Linux и Windows;
3. Управление переменными окружения Java: jenv может автоматически установить переменные окружения Java;
4. Управление настройками JVM: jenv позволяет настраивать параметры JVM для каждой версии Java, такие как размер кучи, аргументы командной строки и т. д.

Жаль, что я не знал о ней раньше. Рекомендую!

Что важно - утилита следует принципу единой ответственности, поэтому за установку JDK она не отвечает.
Но для этого есть другая утилита - sdkman
Как всегда статья https://www.baeldung.com/java-sdkman-intro
Да, JDK можно ставить любым менеджером пакетов или даже через IDEA.
Но у sdkman очень хороший выбор jdk https://sdkman.io/jdks и не только jdk https://sdkman.io/sdks
И тоже есть поддержка всех 3 основных ОС.

#java #jdk #tools

Заглушка может стать умной

Я уже писал про заглушки в Java для отладки и тестов - https://t.me/javaKotlinDevOps/344
Там чемпионом по функционалу был WireMock.
Собственно для Java разработчика он им и остается, но есть и альтернатива, пришедшая из мира Go - HoverFly https://docs.hoverfly.io/en/latest/pages/keyconcepts/modes/modes.html
Но имеющая при этом native binding для Java https://docs.hoverfly.io/en/latest/pages/bindings/java.html

Вообще если их сравнивать по основным параметрам:
1) возможность гибкой настройки симуляции и проксирования запросов (spy и mock в терминологии Mockito)
2) захват ответов (capturing)
3) гибкое сопоставление запросов и ответов (request matching)
4) гибкая шаблонизация ответов (response templating): доступ к параметрам запроса, в т.ч. xpath, jsonpath, генерация случайных данных
5) сценарный режим = использование состояния в ответах (stateful mode)
6) проверка запросов в стиле Mockito, пример: verify(exactly(5), postRequestedFor(urlEqualTo("/many")))
7) в целом DSL в стиле Mockito
8) различные источники данных для заглушек: код, json, внешний сервер
9) проксирование запросов прямое и обратное
то будет примерный паритет.

В чем же разница, и зачем я пишу этот пост?

Сначала про плюсы WireMock:
1) Java экосистема и, следовательно, все фичи доступны в Java
2) embedded режим, в котором нет лишних процессов
3) больше встроенных возможностей по симуляции ошибок
4) ориентация на разработчика

Но у HoverFly есть свои "фишки":
1) работа в forward proxy режиме из коробки. Напомню про forward proxy - это то самое окошко в браузере, где можно указать через какой прокси должен проходить весь трафик. Известная реализация - Charles proxy, популярна среди мобильных разработчиков для отладки без бэкэнда. Плюсы такого режима проявляются на тестовых стендах - прозрачный для клиента перехват трафика. WireMock так тоже умеет, но это для него не основной режим https://wiremock.org/docs/proxying/#running-as-a-browser-proxy
2) middleware - к HoverFly можно создавать и подключать свои модули, модифицирующие запросы или генерирующие ответы https://docs.hoverfly.io/en/latest/pages/keyconcepts/middleware.html К сожалению, не на Java. Казалось бы модифицировать поведение заглушки можно в своем коде? Да, но ключевой момент middleware - это простая модульная система, т.е. стандартизация и переиспользование модулей.
3) упор на захват трафика, который выражается в наличии таких интересных режимов https://docs.hoverfly.io/en/latest/pages/keyconcepts/modes/modes.html, как Diff - сравнение реального трафика с заглушкой и Modify - реализует Man in the Middle, т.е. замену трафика на ходу, но не для злоумышленика, а для тестовых целей. Возможности по подмене трафика есть и у WireMock https://wiremock.org/docs/proxying/#remove-path-prefix, но их сильно меньше.
4) наличие CLI API - https://docs.hoverfly.io/en/latest/pages/reference/hoverctl/hoverctlcommands.html

Итог - видится, что HoverFly стоит рассмотреть автоматизаторам тестирования и нагрузочным тестировщикам, и иметь в виду - Java разработчикам.

Еще интересный итог - разработчики и автотестеры используют достаточно много общих инструментов - JUnit, WireMock\HoverFly...

#rare_test_libs #mocks

Обработка ошибок - не только Java

Как справедливо заметил @ort_gorthaur в комментах к посту об обработке исключений в Java https://t.me/javaKotlinDevOps/440
в других языках есть интересные варианты для обработки исключений.

Try в Scala
https://www.baeldung.com/scala/exception-handling

def trySuccessFailure(a: Int, b: Int): Try[Int] = Try {
Calculator.sum(a,b)
}

val result = trySuccessFailure(-1,-2)
result match {
case Failure(e) => assert(e.isInstanceOf[NegativeNumberException])
case Success(_) => fail("Should fail!")
}

Целых два варианта в Kotlin:

Try
https://www.javacodegeeks.com/2017/12/kotlin-try-type-functional-exception-handling.html

fun divideFn(dividend: String, divisor: String): Try<Int> {
val num = Try { dividend.toInt() }
val denom = Try { divisor.toInt() }
return num.flatMap { n -> denom.map { d -> n / d } }
}

val result = divideFn("5t", "4")
when(result) {
is Success -> println("Got ${result.value}")
is Failure -> println("An error : ${result.e}")
}

и Result
https://www.baeldung.com/kotlin/result-class

fun divide(a: Int, b: Int): Result {
return runCatching {
a / b
}
}

val resultValid = divide(10, 2)
assertTrue(resultValid.isSuccess)
assertEquals(5, resultValid.getOrNull())

Тоже два варианта - Option и Result - в Rust
https://habr.com/ru/articles/270371/

fn extension_explicit(file_name: &str) -> Option<&str> {
match find(file_name, '.') {
None => None,
Some(i) => Some(&file_name[i+1..]),
}
}

fn double_number(number_str: &str) -> Result<i32, ParseIntError> {
match number_str.parse::<i32>() {
Ok(n) => Ok(2 * n),
Err(err) => Err(err),
}
}

Основные особенности у всех этих вариантов:
1) автоматическое оборачивание исключения в класс
2) сохранение информации об ошибке
3) сопоставление типа (class pattern matching)

Что интересно, class pattern matching появился в Java в виде JEP 406: Pattern Matching for switch, а значит можно реализовать что-то похожее. Например, вот так:
https://habr.com/ru/articles/721326/

#error_handling #null_safety #java #comparision #kotlin #scala #rust