Почему? Воркфлоу возвращается LLM в итоге. Там выше скрин с UI есть. Без тула валидации нет гарантий, что LLM дойдет до заполнения всех обязательных полей. Поэтому если смотреть статистику вызова тула, то видно, что он вызывается несколько раз. Всё это обусловлено размером требуемого воркфлоу. Без валидации он тоже будет возвращаться, но LLM может "забыть" заполнить некоторые поля.
Тут есть момент, что подразумевается сравнение структурированного хранения ключ-значение. Автор приводит пример ключ-значение на XML и JSON. В итоге очевидно, что в XML больше синтаксических обвесов для этого надо. Суть сравнения именно в этом. Использовать в качестве ключа сам тег не всегда подойдет.
Так тимлид должен наоборот поощрять применения современных возможностей языка )) Чтобы разработчики развивались в технологиях и своем стеке. Лично мое мнение как тимлида )
Однако в типовом проекте Spring Boot + Spring Data JPA + PostgreSQL нужно написать коллбэки для CRaC самому. Это странно как минимум потому что в таком простом проекте нет "инородных" зависимостей для спринга.
Это уже философские вопросы пошли ) В java много идей, берите классические книжки смотрите, доки есть. Сейчас java выбирают не из-за "эргономики". Ее выбирают потому что на Java есть фреймворки типа Spring Framework с развитой экосистемой, на которых на изи можно делать серьезные работающие проекты сила средне-рыночных разработчиков. Когда CRUD REST API на WebAssembly напишите можем обсудить )
Заморозить язык не получится. Таких прецедентов еще не видел ) Можно было бы тогда на Java 8 остановить развитие и идти отдыхать. И не получили бы всяких удобных фичей языка как в последних релизах.
Ну, Java никогда не была ортогональным языком как Go, например. Всегда можно было делать что-то несколькими способами. По мне это не хорошо и неплохо, просто по такому пути развитие пошло. Это открывает возможности, но и может запутать.
А, так это та самая книга. Понял.
Здорово. Как называется, если не секрет?
Воркфлоу возвращается вот в этом месте https://github.com/Java-Boys-Hackathon-Team/vibe-json/blob/main/src/main/java/ru/javaboys/vibejson/llm/AiAgentService.java#L53
То есть на выходе я уже получаю DTO, в которой может лежать воркфлоу, если LLM задала все вопросы и заполнила всё требуемые поля.
Если у LLM есть вопросы, то это поле https://github.com/Java-Boys-Hackathon-Team/vibe-json/blob/main/src/main/java/ru/javaboys/vibejson/llm/dto/LLMResponseDto.java#L13
просто будет null.
Когда все вопросы заданы и поля заполнены будет возврат из метода, где это поле НЕ равно null.
Почему? Воркфлоу возвращается LLM в итоге. Там выше скрин с UI есть.
Без тула валидации нет гарантий, что LLM дойдет до заполнения всех обязательных полей. Поэтому если смотреть статистику вызова тула, то видно, что он вызывается несколько раз.
Всё это обусловлено размером требуемого воркфлоу. Без валидации он тоже будет возвращаться, но LLM может "забыть" заполнить некоторые поля.
Тут есть момент, что подразумевается сравнение структурированного хранения ключ-значение. Автор приводит пример ключ-значение на XML и JSON. В итоге очевидно, что в XML больше синтаксических обвесов для этого надо. Суть сравнения именно в этом. Использовать в качестве ключа сам тег не всегда подойдет.
Теперь на вайбе заживём.
Промпт: "Сделай, чтобы всем было хорошо"
Одобряем, одобряем
Так тимлид должен наоборот поощрять применения современных возможностей языка )) Чтобы разработчики развивались в технологиях и своем стеке. Лично мое мнение как тимлида )
Меня больше всего огорчил уровень адопшена CRaC в Spring Boot
https://docs.spring.io/spring-boot/reference/packaging/checkpoint-restore.html#page-title
Это действительно работает.
Однако в типовом проекте Spring Boot + Spring Data JPA + PostgreSQL нужно написать коллбэки для CRaC самому. Это странно как минимум потому что в таком простом проекте нет "инородных" зависимостей для спринга.
Круто, что так долго с java знаком
Это уже философские вопросы пошли ) В java много идей, берите классические книжки смотрите, доки есть.
Сейчас java выбирают не из-за "эргономики". Ее выбирают потому что на Java есть фреймворки типа Spring Framework с развитой экосистемой, на которых на изи можно делать серьезные работающие проекты сила средне-рыночных разработчиков. Когда CRUD REST API на WebAssembly напишите можем обсудить )
Заморозить язык не получится. Таких прецедентов еще не видел )
Можно было бы тогда на Java 8 остановить развитие и идти отдыхать. И не получили бы всяких удобных фичей языка как в последних релизах.
Есть такой момент, да. В либах дофига чего зарыто может быть. Всякие unsafe или патчинг байткода
Вот https://openjdk.org/jeps/8303099 ждём когда JEP этот додет до релиза )
Коллекции без дженериков - это уже перебор
Ну, Java никогда не была ортогональным языком как Go, например. Всегда можно было делать что-то несколькими способами. По мне это не хорошо и неплохо, просто по такому пути развитие пошло. Это открывает возможности, но и может запутать.
Главное, что так было всегда )
Коты норм )
Это интересные перспективные технологий для java-разработки
Про deprecated статус не знал кста. Но встречается-таки да. Ну и eclipse temurin естественно.