Еще интересный вопрос - может ли быть техлид один на несколько команд? Если да - какой максимальное число команд с точки зрения эффективности. Навскидку зависит от уровня стандартизации разработки в компании и сложности сервисов
Что касается зачем нужен новый класс - для стандартизации ответов об ошибках в API. В большинстве случае стандартного класса хватит, а это упростит проектирование и обработку ошибок API.
Книжка может быть полезной. Например, если у человека разработка - не основной вид деятельности. Он, например, ученый или менеджер. Но боюсь кто-то захочет войти в IT именно таким способом.
Соглашусь, статью стоит дать почитать другим членам команды, чтобы понять, чем занимается тестировщик) Ну или тестировщику-джуну в процессе онбординга. Для собеса - слишком большой объем теории.
Но разве это прямой конкурент RAG? RAG же хранит не контекст, а домен-специфичные данные
Вообще не понятно о чем статья. Почему k8s стал лидером - нет ответа. Безопасность - что-то говорится, но поверхностно
Не знаю, кто станет победителем - но Spring уже взял в оборот MCP https://docs.spring.io/spring-ai/reference/api/model-context-protocol.html
Подозреваю, что если им не завести тикет - вряд ли
Интересно, чем дело кончится
Мне кажется стоит завести issue. Заодно можно узнать - думают ли они в этом направлении
Интересно, неужели никто не запрашивал у них эту доработку за все время?
Классная статья. И из нее следует, что разработчики Spring не думают о разработчиках плагинов)
А почему подумали про Сбер? Денег много?) AI развивает? Хотя AI ещё как минимум Яндекс и VK
Да)
Нет, спасибо за наводку. Я в основном пользуюсь ML в режиме чата, AutoCompletion кажется пока сыроват. Но доберусь и до этой темы
Потестирую его, спасибо. Что интересно - он вроде бы основан на предыдущей (второй) версии модели LLama, но зато заточен под разработку.
Еще интересный вопрос - может ли быть техлид один на несколько команд? Если да - какой максимальное число команд с точки зрения эффективности. Навскидку зависит от уровня стандартизации разработки в компании и сложности сервисов
Ссылки в статье поправил, спасибо!
Что касается зачем нужен новый класс - для стандартизации ответов об ошибках в API. В большинстве случае стандартного класса хватит, а это упростит проектирование и обработку ошибок API.
Век живи, век учись. Даже не предполагал существования такого функционала в Java)
Логично. Живого человека еще нужно найти...
Вывод - все собесы с включенной камерой. И следить за пингом - как долго отвечает, куда смотрит
Книжка может быть полезной. Например, если у человека разработка - не основной вид деятельности. Он, например, ученый или менеджер. Но боюсь кто-то захочет войти в IT именно таким способом.
Соглашусь, статью стоит дать почитать другим членам команды, чтобы понять, чем занимается тестировщик) Ну или тестировщику-джуну в процессе онбординга. Для собеса - слишком большой объем теории.
Я правильно понимаю, что в Вашем случае T-shape был вынужденный? Если да, то этот кейс я не учёл. Спасибо.
А по факту - да, печально. И как я подозреваю со специалистами на рынке проблема
Да, именно так) Ведь к stacktrace часто обращаются неявно, например, при логировании.