@igrekde Эх, если бы каждый бизнес мог построить платформу... Многие еще на этой задаче обламываются, так и не дойдя до тысяч экспериментов. Так что думаю и "погонщики агентов" будут востребованы и platform engineers, каждому своя ниша
Before AI coding agents, I'd constantly have 2 or 3 side-projects that I would struggle to finish
AI completely changed the game
Now I have 15-20 unfinished side-projects
Для собеседующих:
Как быстро проверить что у девелопера все норм с soft skills? Словами через промт :)
Даешь AI-агента и пусть заставит его реализовать задачу.
Условие: код руками трогать и писать в промте нельзя.
Для сеньоров: не более N промтов
Для лидов: + нельзя материться
@andrey_sitnik@grok@mighty_seal_lol@dotfox_x@macbet_k@Devgru@SocketSecurity Multiocular интересно, но скорее как визуализация.
Если обновляюсь, то:
0. Если Spring, то предпочту обновления из BOM - они тестируют сами
1. Читаю Changelog
2. Смотрю в maven repo есть ли известные CVE (там из транзитивных также)
Решение осознанное, а не "само собой" по range
@andrey_sitnik@grok@mighty_seal_lol@dotfox_x@macbet_k@Devgru@SocketSecurity Maven Central:
* SHA - проверяет что артефакт не изменён после публикации
* PGP - значит этот файл подписал тот кто владеет namespace (и прошел верификацию в OSSRH)
И это не галочка - без них релиз не примут с 2004 года. В npm provenance до сих пор опциональна.
@andrey_sitnik@grok@mighty_seal_lol@dotfox_x@macbet_k@Devgru@SocketSecurity Итого, range ускоряет патчи, но ценой ежедневного контроля билдов. Это точно проще, чем fixed версии и обновлять осознанно? Мониторить CVE надо и в java/npm.
Плюс в 2025 (с релиза lock-files 9 лет) ты пишешь утилиту чтобы удобно делать diff (видимо их нет особо). Показательно?
@andrey_sitnik@grok@mighty_seal_lol@dotfox_x@macbet_k@Devgru@SocketSecurity И ладно бы один раз: 2016 left-pad, 2018 event-stream. Сегодня — уязвимости каждый день.
Range взяли из Linux сразу, а lock прикрутили постфактум. Теперь каждый день смотри в билд и следи за diff.
И тут джависты в 2025: может проще fixed versions, как мы с 2004?
@andrey_sitnik@grok@mighty_seal_lol@dotfox_x@macbet_k@Devgru@SocketSecurity В Maven Central с 2004 пакеты immutable. Перезаливать нельзя с начала, удалять тоже (кроме corner cases). В linux тоже самое с 90-х
npm появился в 2010. Удалять запретили в 2016 после left-pad.
Итого, 6 лет чтобы сделать как в Linux, Maven т.д. Хотя что мешало сразу? Вот и 🚩
@grok@andrey_sitnik@mighty_seal_lol@dotfox_x@macbet_k@Devgru@SocketSecurity Тут конечно про leftpad (там как раз отсутствие immutability стрельнуло), lock-file - это больше про event-stream (уже 2018, это позже).
Суть при этом прежняя: мало доверия к экосистеме, где происходит подобное (сначала юзают, а потом осознают риски).
@andrey_sitnik@mighty_seal_lol@dotfox_x@macbet_k@Devgru@SocketSecurity То есть не сначала делают инфраструктуру под range-версии, а потом юзают их по умолчанию.
А реагируют уже пост-фактум, когда всё взорвалось.
Разве это не говорит об общем отношении к качеству и культуре в экосистеме?
@mighty_seal_lol@andrey_sitnik@dotfox_x@macbet_k@Devgru@SocketSecurity Red flag здесь не сам инструмент, а культура.
В npm (2010) range versions by default, и дружно забили на reproducibility и security, пока не грянули left-pad (2016) и event-stream. Lock-файл (2017) и прочее появились уже после.
Да, для java разрабов эта культура и есть red flag
@andrey_sitnik@dotfox_x@mighty_seal_lol@macbet_k@Devgru@SocketSecurity Поэтому все ещё валидный вопрос: не слишком ли большая цена за риски чтобы "юзать range ^1.2.3 как в linux", при этом не иметь возможности протестировать все зависимые билды?
Понятно, что риск невелик, но когда он сыграл - мало не покажется.
@andrey_sitnik@dotfox_x@mighty_seal_lol@macbet_k@Devgru@SocketSecurity В Linux диапазоны работают, потому что дистрибутив пересобирает и тестирует всё дерево пакетов. Обновил openssl → проверили firefox, curl, etc.
В npm скопировали ^1.2.3, но централизованное тестирование - нет. Спойлер: его там и быть не может.
В Java понимают - это антипаттерн