Ещё один интересный момент про кэши: кэши - этот не только про скорость. Ещё два плюса:

1) более простой API, по крайней мере по сравнению с традиционным реляционными БД. noSQL решения играют на том же поле. Условно getByKey() сильно проще, чем SELECT a,b,c FROM x INNER JOIN ... Сложность выборки данных прячется в сервисе, заполняющем кэш

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

И сразу один жирный минус: усложнение системы, дублирование данных, синхронизация, допустимость устаревших данных...

#rdbms #caching

Транзакционность в Kafka.

Транзакцию легко реализовать в рамках БД. Еще есть распреденные транзакции: старый недобрый JTA - долго и дорого, паттерн Сага с eventually consistentcy - работает, при этом требует проработки архитектуры системы в целом.

А что Kafka?
Казалось бы - append only запись и чтение, какие транзакции? Транзакции внутри Kafka - запись на N брокеров, Zookeeper и возврат ответа в producer - выносим за скобки, не было бы тут транзакционности - кто бы ей пользовался)

Но транзакции могут быть на уровне бизнес-логики. Например, мы можем перекладывать сообщения из одного топика в другой попутно выполняя над ними преобразования. Запись - понятно, а чтение из Kafka - это тоже запись, точнее сдвиг текущей позиции для данного consumer в топике.
Так что с транзакциям внутри Kafka (внутри- это принципиально)? Они есть. С ACID, все как положено.
Детали тут https://www.confluent.io/blog/transactions-apache-kafka/
Интересно, что запись в топике появится сразу. Но это запись «почтальона Печкина», consumer вам ее не покажет, потому что у вас документов нету, тьфу, не то, потому что транзакция не зафиксирована) Регулируется это служебными заголовками. Данный лайфхак улучшает время чтения данных из транзакции, по сути это предварительное кэширование.

Полноценно функционал доступен начиная с версии 3.6. Последняя на данный момент 3.9

#kafka #transactions #streaming

Всем привет!

Окей, транзакции в Kafka и в БД по отдельности у нас есть. А можно объединить их в одной транзакции?
Во-первых у нас есть паттерн Сага.
А во-вторых - YDB (от Яндекса).
Вообще интересно развивалась данная СУБД. Вначале это было быстрое и горизонтально масштабируемое облачное noSQL хранилище с полноценными транзакциями. Потом разработчикам не понравилось, как работает Kafka в многопользовательском режиме, и они добавили в YDB топики. Ещё один плюс - не надо отдельно разворачивать Kafka. И наконец «финалочка» - появилась поддержка транзакций топики+таблицы. Паттерн Transaction outbox - давай, до свидания)
Вообще людям, которые могут себе позволить облако Яндекса по финансовым и идеологическим соображениям, не завязанных на существующий технологический стек - им можно только позавидовать)
Ложка дёгтя - транзакции в YDB пока работают медленнее Kafka. И медленнее, чем хотелось бы команде Яндекса. Команда работает над этим)

#rdbms #transactions #kafka #streaming

Как мне напомнили в комментариях - история развивается по спирали.
Очереди (очереди не равно топики Kafka) есть в Oracle https://docs.oracle.com/en/database/oracle/oracle-database/19/adque/aq-introduction.html
И они поддерживают общие транзакции с таблицами.
Также у Oracle есть шлюз для связывания внутренних и внешних очередей https://docs.oracle.com/en/database/oracle/oracle-database/21/adque/messaging_gateway.html

Аналогично для MSSQL https://learn.microsoft.com/ru-ru/sql/database-engine/service-broker/benefits-of-programming-with-service-broker?view=sql-server-ver16

Спасибо @AViIgnatov

#rdbms #mq #transactions

Ещё один интересный доклад - про самую производительную утилиту для НТ - и это wrk2. Позволяет на типовой машине 8 ядер и 12 Гб (надеюсь правильно запомнил конфигурацию, но плюс минус так) подымать 10 000+ параллельных соединений в несколько потоков. Плюс минимизировать эффект от временной недоступности тестируемой системы - т.наз. Coordinated Omission - как числом потоков, так и математической корректировкой результата теста и дальнейшей последовательности вызовов. Надеюсь, заинтриговал) Минус - утилита заброшена автором с 2016 года, но этот минус поправили, см https://t.me/rybakalexey/98
По ссылке - блог автора доклада. Плюс сам доклад https://t.me/rybakalexey/170

#нт #tools

Ещё интересный доклад - про нетривиальное использование трейсинга (tracing).

Начнём с того, что далеко не у всех он настроен. Окей, настроили. Теперь нам проще разбирать проблемы на ПРОМ в микросервисной архитектуре.

Все?

Нет) А если взять трейсы за некий период, отсемплировать их уменьшив объём и сложить их в графовую БД? Получим реверс-инжиниринг архитектуры. Причём это будет не «мертвая» архитектура, по кем-то когда-то написанной аналитике, а настоящая. Да, не 100% точная, из-за мертвых интеграций и поломанного трейсинга, но все же. Что с ней можно сделать? Контролировать... архитектуру. Например:
- Общая схема вызовов
- Циклические ссылки
- Длина цепочек вызовов
- Лишние с точки зрения разделения на бизнес-домены связи
- Критичность сервисов - сервисы, которые чаще всего используются другими сервисами
- Однотипные вызовы, которые можно объединить в batch запрос
- Вызовы в цикле
- Анализ использования практики Graceful degradation

Сама идея - практически бесплатный для бизнес-команд инструмент анализа архитектуры - отлично IMHO.

P.S. для этих же целей в теории можно использовать данные из Service Mesh, только добавляется ещё один снижающий точность фактор - не все компоненты находятся в облаке (и не все компоненты в облаке используют Service Mesh)

P.P.S. Конечно идея идеально подходит для компаний а-ля Яндекс и Авито (собственно в Авито ее и внедрили) - там, где нет жёсткого контроля интеграций на уровне согласования аналитики. Но IMHO в любом случае можно использовать как контрольный механизм, ещё одну «сеть»

#arch #tracing

Highload прошел, но интересные доклады еще остались)

"AppHost: как Яндекс организует взаимодействие сотен микросервисов"

Честно - не ожидал такого хода от Яндекса.
В чем суть?

У Яндекса микросервисная архитектура, большое количество микросервисов и жесткие требования по времени ответа пользователю. При этом очень сложно контролировать всю цепочку вызовов микросервисов по конкретной фиче, чтобы оптимизировать время ответа. Убрать лишние вызовы или найти самый долгий для его оптимизации. Один из вариантов решения проблемы есть в предыдущем моем посте (реверс-инжиниринг по трейсам), но ребят данный вариант не устроил из-за его не 100% точности.

Они тоже сделали граф вызовов для каждого бизнес-процесса. Но граф этот задается владельцем процесса явно в текстовом виде. Ремарка - как найти владельца для бизнес-процесса из десятка микросервисов - отдельный вопрос. Возвращаясь к сути, из того что я увидел: в конфигурации задаются сервисы - поставщики данных, их зависимости, таймауты, протоколы и схемы обмена данными. И это не просто часть аналитики, более того - как я понимаю в Яндексе нет требований по наличию аналитики. Это исполняемая спецификация: каждый запрос вначале попадает на новый микросервис - собственно AppHost из названия доклада - который загружает граф и выполняет его. Вызывая нужные микросервисы, предварительно проверяя необходимость и возможность его вызова. В итоге получаем топологию микросервисов в виде звезды, где AppHost в центре.

Сразу же возникает вопрос по надежности решения.
Ответы:
а) AppHost - stateless сервис, горизонтально масштабируемый, более того его инсталляции разделены по разным бизнес-доментам. Плюс есть всякие лайфхаки - например, при сбое по умолчанию пользовательский запрос отправляется на повторное выполнение, но при наличии специфических ошибок (ошибок, ломающих логику AppHost) повтор отключается
б) всегда есть критически важные сервисы, от которых зависят все или почти все остальные. Аутентификация, авторизация, прокси - как минимум. И ничего - они тоже дорабатываются, новые версии выкатываются. Здесь главное не сделать такой оркестратор слишком сложным.

Да, возвращаясь к принципу: все новое - это хорошо забытое старое. Во-первых это мне напоминает паттерн Сага в виде оркестратора. Во-вторых - старый недобрый ESB - Enterprise Service Bus - на новом витке развития. Напомню, его ключевое отличие от Kafka - брокер ESB содержит бизнес-логику и занимается маппингом данных, а брокер Kafka - в основном обеспечивает отказоустойчивость.

Ну и отдельно - вот принцип Architecture As Code в действии. Этап вливания конфигурации с графом сервисов - хорошая точка для контроля архитектуры. В целом идея мне нравится, ключевой момент тут - сознательное ограничение сложности оркестратора. Тогда получим увеличение надежности системы в целом. Но повторюсь - не ожидал, что эта идея возникнет у Яндекса.

#arch #aac #saga #esb

На Highload услышал упоминание про timeout propagation и вспомнил, что давно хотел эту тему поднять.
В чем суть - где-то настроен timeout, и для того, чтобы upstream сервисы знали про него - мы передаём его в заголовках, также как и traceId. Наилучшее место для создания этих заголовков - входной шлюз. Или API Gateway - именно так сделали в Avito. Передать таймуат можно двумя способами - как длительность, X-Timeout = 5s или как время - X-Deadline: 06.12.2024 14:55:45. Второй вариант проще обрабатывать на upstream серверах, т.к. не нужно вычислять сколько из первоначального таймаута осталось, но требуется синхронизация времени на всех серверах.

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

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

#reliability #timeout

Всем привет!

Уже писал про импортозамещение в ПО:

1) IDE https://t.me/javaKotlinDevOps/353
2) Spring plugins https://t.me/javaKotlinDevOps/358

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

Так вот, на Highload-е нашёл 2 аналога GitLab/GitHub:

1) GitVerse от Сбера. Как и GigaIDE находится в процессе разработки, в частности аналог Git Actions планируют допилить в ближайших релизах, сейчас для настройки требуется много ручных действий. Две основные фишки: интеграция с GigaCode и облачная IDE на основе VS Code, доступная в рамках бета-тестирования. Для облачной IDE нужен аккаунт и настройка в облаке Сбера - cloud.ru. И к сожалению не поддерживается Java - зато есть Python, Go, С#. Интерфейс аскетичный, но подсветка синтаксиса, AutoComplete, работа с тестами, отладка и консоль есть. Пока все бесплатно, конечно временно) Еще фишка - доступно AI ревью кода https://gitverse.ru/docs/collaborative-work/code-review/#ai-ревью И в целом ревью неплохое - я скормил ему кусок кода "с запахами", и AI нашел там 6 багов из 18. Минус: все работает медленно - думаю сказывается бесплатность и статус беты.

2) GitFlic от Астра (которая Linux). В нём есть Ci/CD, реестр артефактов, статический анализ кода (названный почему-то SAST), REST API и интеграция с Telegram и JIRA. И платная версия, позволяющая добавлять более 5 человек в private репозиторий плюс расширенную поддержку https://gitflic.ru/price Пока нет полноценно баг-трекера, обещают сделать. Еще плюс - тут я быстро нашел как разрешить force push, в отличие от GitVerse)

GitFlic на данный момент выглядит законченным продуктом, но у GitVerse есть свои плюсы - см. выше. Плюс тесная интеграция с облачным провайдером cloud.ru

#импортозамещение #git

В нескольких недавно выпущенных русскоязычных книгах замечаю отдельное упоминание о научном редакторе, являющимся практикующим ИТ инженером. Аллилуйя!) Google translate и студентов лингвистических вузов маловато для качественного перевода) Надеюсь, это станет стандартом

#books

Всем привет!

Читаю сейчас книжку Open Telemetry, первая глава, вступление о том, зачем все это нужно.
Обычно во вступлении не так много ценной информации, но бывают исключения)

Нашел сравнение Open Telemetry с DevOps. Казалось бы, что может быть у них общего? Кроме того, что DevOps инженеры настраивают Open Telemetry систему совместно с разработчиками и сопровождением.

Ответ - идеология.

Для начала - что такое DevOps?
Набор инструментов - да. Но в первую очередь идея о том, что для быстрого деплоя приложения на ПРОМ важно сотрудничество Dev и Ops, а также забытых в этой формуле Test и Sec)

Аналогично, OpenTelemetry - это не просто стандарт сбора, передачи и хранения логов, метрик и трейсов. Это идея о том, что для разбора, а в идеале предсказания проблемы нужно единое представление перечисленных ранее данных. Назовем все эти данные телеметрией.
Т.е. ключевая идея - сами по себе логи, метрики и трейсы конечно же полезны. Но вместе их ценность сильно возрастает. И, естественно, в телеметрии должны быть признаки для матчинга этих данных между собой.

Читаю дальше)

Ввожу новый тэг -
#telemetry

Всем привет!

Есть много способов получить данные из БД с помощью JPA:
1) JPQL
2) JPQL Native Query
3) HQL
4) Spring Data JPA Repository
5) Criteria API
6) QueryDSL
...

Предположим, нам нужно вернуть набор строк. Задать параметры запроса можно по-разному, а итог будет один - List или другая коллекция (Collection) с набором данных. Верно? Не совсем)
Если посмотреть на список возвращаемых Spring Data JPA данных https://docs.spring.io/spring-data/jpa/reference/repositories/query-return-types-reference.html#appendix.query.return.types то там можно увидеть много чего интересного. В т.ч. Stream.
А вот пример его использования: https://vladmihalcea.com/spring-data-jpa-stream/
Аналогично можно вернуть Stream и из обычного JPA - см. метод getResultStream, вот пример: https://thorben-janssen.com/jpa-2-2s-new-stream-method-and-how-you-should-not-use-it/

Зачем это может быть нужно?

Во-первых это просто красиво... Шучу. Если вы используете Stream в бизнес-логике - то кажется логичным использовать их и при обращении к БД.
А во-вторых: главная особенность стриминга - равномерная выборка данных. И в каждый момент данных в обработке будет одна запись.
Рассмотрим кейс, когда нужно обработать на клиенте миллион записей.

Ремарка: если у вас такой кейс - подумайте, нет ли проблем в архитектуре. Данные лучше обрабатывать на сервере СУБД. Если все же проблем нет - продолжим)

Так вот, какие у нас варианты:
1) вытащить на клиент миллион записей. Запрос к БД будет один, она выдержит, но с неплохой вероятностью можно убить клиент через Out of Memory.
2) организовать пагинацию, например, вот так: https://www.baeldung.com/spring-data-jpa-iterate-large-result-sets. Данных на клиенте в моменте не много, по размеру страницы, но запросов к БД ... тысяча.
3) использовать стримы. Запрос к БД один, данных на клиенте немного. Не обязательно одна запись, но в любом случае немного, детали ниже.

К слову, стриминг по БД с JPA аналогичен перемещению курсора по ResultSet в JDBC. С накладными расходами и плюшкам, которые дает сессия JPA, конечно.

И про объем данных на клиенте. Казалось бы - вытаскиваем записи поштучно. Но если не указать fetch size - объём предварительной выборки - для некоторых СУБД Hibernate вытащит на клиента все данные за раз, и мы вернемся к варианту 1 (((

#jpa #java_streams #rdbms

Всем привет!

Я снова вернулся)

И предновогодний пост будет снова про AI и Java.

Для начала про LLM. Чтобы LLM дала осмысленный ответ - ей нужен правильный промт и побольше контекста. Не даром в новых версиях моделей объем контекста растет - возьмем тот же Gemini с 1 млн токенов.
Но с точки зрения разработки - важен не только объем, но автоматизация работы с контекстом, т.е. некая бизнес-логики. Например, если мы делаем свой агент и у нас несколько источников точных данных, которые мы хотим скормить модели. И эта бизнес-логика скорее всего будет похожая у разных агентов...
LLM - область достаточно молодая, стандарты в ней зарождаются прямо сейчас. Встречайте MCP https://spec.modelcontextprotocol.io/specification/ - сайт стандарта - и https://habr.com/ru/articles/862312/ - интро на русском.
Он стандартизирует в первую очередь транспортное API - клиент и сервер - для работы с источниками точных данных и LLM. Содержит ряд готовых серверов для работы с файловыми данными, СУБД, веб-поиском.

Как это все относится к Java? А вот как: есть Spring AI, уже писал про него https://t.me/javaKotlinDevOps/241 Он дает универсальное API для обращения к различным LLM. Сейчас туда добавили - в статусе experimental - Spring AI MCP https://docs.spring.io/spring-ai/reference/api/model-context-protocol.html
Причем добавили достаточно быстро, хотя до Python конечно же далеко. Вообще поддержка Python, я полагаю, появилась вместе со стандрартом)

P.S. Да, вспоминая Kotlin в названии канала - если посмотреть примеры Spring AI - получите, распишитесь: https://github.com/spring-projects/spring-ai-examples/blob/main/kotlin/

#llm #spring

Всем привет!

Прочитал статью про работу с секретами в Java: https://habr.com/ru/companies/sberbank/articles/870116/
Лично я из статьи подметил три интересных момента:

1) Сейчас много говорят о безопасной разработке. Книги, доклады на конференциях… Что имеем на практике? Вот есть понятная рекомендация — хранить пароли не в String, а в char[]. Так как String — это объект, и его содержимое будет в heap dump до очередной уборки мусора. А уборка мусора проходит в несколько этапов, и принудительно вызвать её мы не можем. А char[] мы можем очистить сразу после использования. Так вот — в статье у нас есть embedded Tomcat, Jersey HTTP client и Hikari pool. Три широко распространённых компонента, требующих секретов при работе. Сколько из них поддерживают передачу секретов в char[]? Увы, только Jersey client. И это уровень фреймворков и библиотек, на бизнес-уровне всё будет ещё хуже.

2) Перегружаемые настройки Spring Cloud, работающие через @RefreshScope и описанные мною ранее, подходят, увы, не всегда. Основная проблема — передача секрета в компоненты, инициализируемые сложно, однократно при старте или некорректно обрабатывающие событие обновления секретов — например, сбрасывающие активные клиентские сессии.

3) Кроме @RefreshScope изобрели ещё два “велосипеда", причём оба в Spring Boot: SSL bundles и Spring Cloud Vault. Первый предназначен для работы с хранилищами сертификатов, второй — для работы с HashiCorp Vault. Оба поддерживают обновление секретов на лету. Все три инструмента взаимодополняют друг друга, хотя и не покрывают 100% кейсов.

#security #spring

Всем привет!

Разбираясь с HashiCorp Vault, понял, что многие, как минимум я, недооценивают его. Что такое Vault? В первую очередь — безопасное хранилище секретов. Аутентификация и авторизация, хранение всех данных в зашифрованном виде. Причём до ввода мастер-пароля администратором само приложение не имеет к ним доступа. Это всё понятно.

Но есть ещё киллер-фича: автогенерация секретов. Архитектура Vault оперирует понятием движка (engine) для работы с различными секретами. Рассмотрим, как ротация сделана для разных движков.

Движок для работы с сертификатами — PKI engine — умеет перегенерировать сертификаты с истекающим сроком. Вот документация: https://www.hashicorp.com/blog/certificate-management-with-vault

Database engine умеет создавать «одноразовых» пользователей в СУБД с помощью фичи под названием dynamic secrets: https://www.hashicorp.com/blog/why-we-need-dynamic-secrets. «Одноразовых» — то есть с ограниченным временем жизни, на один типовой сеанс работы с БД. Причём API Vault позволяет продлить время жизни пользователя для синхронизации с временем сессии. Не уверен, что любая БД выдержит такой режим работы, но видится, что эта функция сильно увеличивает безопасность работы с БД. Может возникнуть вопрос — как Vault их создаёт. ANSI SQL — это хорошо, но диалекты отличаются, да и в конкретной компании могут быть свои правила. Тут всё просто — SQL-запрос для создания пользователя и выдача ему необходимых прав создаются администратором Vault. Естественно, нужно задать логин и пароль администратора СУБД, под которым будут выполняться эти запросы. Но кажется, Vault вполне можно считать безопасным местом для их хранения. Больше деталей здесь: https://www.baeldung.com/vault, а в части интеграции со Spring Vault — здесь: https://www.baeldung.com/spring-cloud-vault.

Также есть возможность ротировать пароли доменных пользователей, используя Active Directory engine — см. https://developer.hashicorp.com/vault/docs/secrets/ad.
И обычные пароли: https://www.hashicorp.com/resources/painless-password-rotation-hashicorp-vault. Странно, что для последнего нужен внешний плагин, но такая возможность есть.

Итого: автоматическая ротация секретов и распространение их с помощью Vault Agent (в виде сайдкаров или JAR-библиотек) выглядят крутой фичей в плане безопасности и упрощения работы администраторов. Наверняка на этом пути будут подводные камни, но путь однозначно верный.

#security #vault #spring

Всем привет!

Нашел хорошую статью и проект, показывающий как должны работать компоненты телеметрии (OpenTelemetry) в связке:
Статья: https://habr.com/ru/companies/otus/articles/761334/
Проект: https://github.com/marcingrzejszczak/observability-boot-blog-post

Слава Docker, развернуть все это у себя на машине можно в пару кликов) Что настоятельно рекомендую сделать.

На что хотелось бы обратить внимание:
1) на одном дашборде собраны трейсы, метрики и логи
2) из лога по атрибуту traceId можно провалится в трейсы и наоборот
3) на панели метрик нужно присмотреться к "ромбикам" - это т.наз. exemplars - метаданные метрики, включающие связку метрики и трейса. И естественно из метрики тоже можно провалиться в trace.
4) еще удобная фича - на большом мониторе можно раскрыть рядом окно трейсинга и логов. Я не про 2 окна ОС, а это встроенная фишка Grafana
5) достаточно удобный формат работы с телеметрией в коде: открываем контекст OpenTelemetry, что приводит к тому, что автоматически формируются идентификаторы трейсов и добавляются ко всем метрикам и логам внутри контекста. Открыть контекст можно как императивно - вызовом метода, так и декларативно - аннотацией.

Ну и ложка дегтя - если брать последний коммит из репозитория выше, то там перешли на OpenTelemetry протокол для метрик, в котором exemplars не поддерживаются. Чтобы увидеть все в сборе надо откатиться на несколько коммитов, но при этом зафиксировать версию образа Grafana Tempo (сервер для трейсинга), т.к. последние его версии похоже не поддерживают Zipkin протокол, на котором работают exemplar) Похоже, стандарт становится зрелым прямо сейчас.

#telemetry

Всем привет!

Возвращаюсь к теме хранения секретов — вот ещё неплохая статья https://habr.com/ru/articles/872128/
показывающая, что если вы «доросли» до вопроса управления секретами, вариантов немного.
Если вы находитесь в коммерческом облаке — Google, AWS, Azure, и скорее всего Яндекс, VK, Сбер — там будет встроенное хранилище секретов, и логично его использовать. Иначе — все дороги ведут в Vault.
Если рассмотреть альтернативы из статьи:
1) Docker Swarm умирает, проигрывая Kubernetes.
2) BuildKit — технология в себе, закрытая в плане сообщества и документации.

#security #vault

Всем привет!

Я не открою Америку, если скажу,  что ИТ-шников не хватает, а поток людей, «входящих в ИТ», растёт. Процесс начался не сегодня. Один из основных стимулов — уровень зарплаты. И у этого процесса есть следствия.

Какой традиционный портрет ИТ-шника? Человек, которому с детства нравятся компьютеры, возможность их настроить, что-то запрограммировать. Готовый сидеть до ночи, решая задачу. Перфекционист, готовый бесконечно улучшать код до идеала. Это не хорошо и не плохо, это типичный ИТ-шник.

Влияет ли на этот образ массовый найм людей, пришедших за высокой зарплатой? Очевидно, да. Ремарка: я не говорю, что все «вошедшие в ИТ» пришли за длинным рублём. Но очевидно, что массовый найм приводит к росту доли таких людей.
О ком я говорю? Это люди, которые работают строго с 9 до 6. Даже если проект «горит». Не хотят выходить за пределы своих обязанностей, причём обязанностей, как они их поняли. Возможно, не любят или ненавидят свою работу.
К чему это приводит?

Потенциально, к поломке текущих процессов. Agile подразумевает сильное вовлечение в создаваемый продукт, постоянное совершенствование и взаимопомощь в команде. Многие IT-шные фишки — «две пиццы для команды», печеньки — возникли как способ поддержать вовлечённость. Да и в конце концов, высокие зарплаты возникли не только из-за дефицита кадров, но и из-за того, что в IT принято вкалывать, а это стоит денег.

Что с этим делать?

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

Для остальных я вижу один вариант: отсев на собеседованиях и испытательном сроке по soft skills. То есть и эксперт на собеседовании, и ментор должны плотно работать с новичком. На собеседованиях с этим могут помочь HR-ы. Понятно, могут помочь, а могут и не помочь) Хотя кажется, должны.

P.S. Ещё есть надежда на ChatGPT)

#it #найм

Всем привет!

Ну что, AI уже заменил джунов
https://habr.com/ru/news/876162/
?
А если серьёзно - это третий шаг в эволюции LLM:
1) запрос-ответ по данным модели
2) обогащение ответа модели актуальным результатами поиска (AI search, например, Perplexity или SearchGPT) или результатами из локальной базы знаний (RAG)
3) AI agent - не просто отдаёт отчёт, но и делает что-то полезное, но рутинное. В IDE, локальной сети или в интернете. По запросу или в фоновом режиме.

Что ж, движение в верном направлении.
Вот пример агента не из мира разработки https://t.me/disruptors_official/2177
Главное, чтобы качество Junie было на уровне, на данный момент AI - не самая сильная сторона JetBrains.

P.S. GigaCode, к слову, идёт туда же. Один из лидеров - Cursor AI. Позволяет восьмилетним детям писать код))) https://vc.ru/services/1456812-vosmiletnie-deti-teper-mogut-sozdavat-prilozheniya-s-pomoshyu-iskusstvennogo-intellekta-obzor-ii-instrumenta-dlya-programmirovaniya-cursor

P.P.S. Вопрос. Если заменить всех джунов - откуда возьмутся миддлы и сеньоры?)

#llm

Всем привет!

В последнее время все чаще вижу, как LLM в IDE используют для генерации каркаса приложения. Казалось бы - это же задача генератора, а не LLM. Какого-нибудь Spring Initializr (https://start.spring.io/) Почему он этого не делает, а ограничивается по сути только pom-ников или *.gradle?

Потому что это отдельный сервис, требующий поддержки. Который со временем - по мере развития библиотеки, фреймворка или платформы, для которой он предназначен - будет обрастать все более сложной логикой. Обновился фреймворк - нужно обновлять генератор. Появился смежный компонент - будут запросы на добавление интеграции с ним. И при этом генератор все равно будет ограничен в возможностях. Возьмем тот же Amplicode - контроллеры, обработчики ошибок и тесты для Spring приложения он генерировать умеет, что-то еще - нет. Со временем возможностей для генерации будет больше, но 100% кейсов не будет покрыто.

А LLM в теории может сгенерировать что угодно, главное "скормить" ей побольше типового кода. Ключевое слово здесь - типового. Т.е. какую-то сложную логику тоже можно сгенерировать в LLM, но если размер диалога будет в 10 раз больше сгенерированного кода, а время - сравнимо, есть ли в этом смысл? Да, модель нужно будет периодически "подкармливать", но видится, что эту процедуру можно автоматизировать взяв за исходные данные открытый код из того же github.

Есть еще нюанс. LLM - это аналог MP3 128 kBit Joint Stereo ))) Сжатие с потерями. Это если что моя оценка вида "пальцем в небо", очень может быть степень сжатия больше. Распаковка - генерация кода - тоже приведет к потерям. Как проверить, что потерь нет - компиляция, тесты, а главное - предварительная оценка того, насколько типовой код нужен. В итоге для простых задач мы получаем универсальный генератор. И это круто!

P.S. Может показаться, что я наехал на Spring Initializr. Нет, штука полезная. Фактически Spring задали стандарт на рынке - все конкуренты Spring сделали свои инициализаторы: https://code.quarkus.io/ и https://start.microprofile.io/ И в Enterprise я видел попытки сделать свои инициализаторы разной степени успешности.

#llm #ai #code_generation

Всем привет!

Учитывая бурный рост AI - в части возможностей и точности ответов - возникает вопрос: что будет с профессией программиста в частности и ИТ-шника в общем?
Пару мыслей по этому поводу.

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

Что изменится?

2) Для начала - должна вырасти производительность. Пример: объяснить почему при наличии AI простая формочка делается несколько дней будет сложно. Хочешь - не хочешь, фичей придется выдавать больше. Можно привести аналогию со станками и конвейером - и то, и другое позволило в разы увеличить объем производства. А если брать более близкий нам пример - появление персонального компьютера, на который не надо записываться в очередь и скармливать ему перфокарты - также сильно увеличило производительность программиста. Получаем реально существующий NZT - ускоритель для мозга или bycicle of mind - за напоминание спасибо @AViIgnatov!

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

4) интересный вопрос насчет T-Shape vs узкий специалист. С одной стороны узкого специалиста сложнее заменить, особенно, если его фреймворк не очень распространен. С другой стороны рутина отдается на откуп LLM, поэтому от менеджеров будет ожидание горизонтального роста на смежные специализации. Что можно сказать точно - разработчик узкого профиля, умеющий в аналитику, тесты и не боящийся ПРОМа - точно незаменим)

5) Самый интересный момент - что будет с джунами? Т.к. теперь джун должен уметь не только писать промты, но и проверять качество кода. Это либо повышенные требования к ВУЗу\курсам, или растянутая по времени стажировка, во время которой джун должен "обогнать" LLM. Хорошая новость: если вы - джун время прокачаться до сеньора еще есть)

#it #llm