Читать в телеге. Когда-то там были посты не только от меня.
Все зависимости Gradle-билда
Недавно опять получил сесурити-алерт от dependabot о том, что в проекте уязвимая зависимость, уровень опасности 100500, пофикси срочно, но где — ищи сам (спойлер: она была в итоге транзитивных зависимостях WireMock).
Чтобы получить дерево зависимостей билда Gradle, можно запустить
./gradlew dependencies
Однако, в этом отчете будут только зависимости одного проекта. И там не будет зависимостей билд-логики (плагины там всякие).
Чтобы получить почти все (потому что более чем уверен, что есть случаи, которые этим не покрыты), я использую вот такую колбасу (которая хранится в баш-профиле):
function deps(){
./gradlew --no-parallel dependencies buildEnvironment $(./gradlew -q projects | grep -Fe "--- Project " | sed -Ee "s/^.+--- Project '([^']+)'.*/\1:dependencies \1:buildEnvironment/" | sort) $([ -d buildSrc ] && echo ":buildSrc:dependencies :buildSrc:buildEnvironment" || echo "")
}
Тут запускается диагностика для вывода списка проектов и для каждого из них выводится дерево зависимостей как для самого билда, так и для его билд-логики. Предполагается сохранить вывод в файл (на больших проектах это может быть 100+ мегабайт текста), искать в нем проблемную зависимость и по дереву идти выше до конкретной зависимости верхнего уровня, конфигурации и проекта.
Если нет жестких ограничений на публичность метаданных проекта, можно запустить
./gradlew build --scan
и получить Build Scan с интерактивным отчетом. Вот пример.
И бонус — не могу не пожаловаться на качество разработки с точки зрения ИБ. Ладно еще вышеупомянутый WireMock, у которого каждая версия на текущий момент имеет какую-то незакрытую уязвимость. Но вот официальная библиотека от официальной организации OWASP для санитайзинга HTML тоже не имеет НИ ЕДИНОЙ версии без уязвимостей. И примерно никакущую реакцию на вопрос трехмесячной давности “а какая версия без уязвимостей?” Добью цитатой из README:
This code was written with security best practices in mind, has an extensive test suite, and has undergone adversarial security review.
"Паблик Морозов" для GitHub-тикета
Довольно специфичная проблема для мейнтейнера OSS-проекта: по ошибке переместил тикет из открытого репозитория GitHub в приватный, а обратить эту операцию GitHub не разрешает (даже не предупредил, зараза).
Решение довольно очевидное: сделать временный приватный репозиторий, переместить тикет туда, а потом сделать репозиторий публичным — и вуаля, уже с публичным тикетом можно делать что нужно.
Эволюция сообщений об ошибках в Rust
Крутая и наглядная статья. Не зря Rust лучше остальных компиляторов в этом плане.
Про исключения Java
Неплохой доклад про работу с исключениями, в котором:
- рассказывается про оптимизации, связанные с NPE, ArrayIndexOutOfBoundsException, ClassCastException;
- оптимизации, связанные со стектрейсом;
- приводятся примеры исключений, которых не стоит ловить;
- рассказывается об областях стека вызовов и связи локов со StackOverflowError;
Бонус — исключение ChuckNorrisException, которое нельзя поймать.
Выводы очевидны, но повторение — мать ученья.
Модернизация легаси
Классный доклад про работу с легаси и частые ошибки модернизации. Начинается с жизы, когда решили модернизироваться, надо еще “чуть-чуть потерпеть”, а в итоге заглохли на полпути и одновременно работают две системы параллельно.
TLDR:
Чтобы модернизироваться правильно:
- нужно обеспечить нормальное обучение всех причастных (vs “отправить 2 инженеров на курсики”);
- должны быть четкие зоны ответственности и возможность принимать решения (и не делать временных костылей, пока ожидаете информацию/чужое решение);
- если решили модернизироваться, то идите до конца, без всяких “вот очень важная фича, отложим эту затею чуток”; к устранению техдолга надо подходить как к долговременным вложениям, а не хотелкам инженеров;
- надо найти способы бороться с возросшей когнитивной сложностью (потому что мало того, что надо учиться новому, еще надо про старое не забывать и про их взаимодействие между собой)
И при всем при этом надо не забывать о том, что главное — это люди:)
Подготовка проекта для вайб-кодинга
Если ИИ-агент — это гиперактивный, но тупой джун, то и работать с ним надо соответствующим образом:
- Жестко декомпозировать ТЗ до микрозадач — ИИ пофиг, что он “разучится мыслить” и не будет “видеть полной картины” (он и так толком это не умеет).
- Разбить проект на модули, которые помещаются в контекст — скорее всего, это будут микросервисы в отдельных репозиториях (и пофиг, что это не самое адеватное решение).
- Снизить когнитивную нагрузку в коде (чтобы вам ее добавил ИИ, кек).
- Использовать тупой язык (т.е., не Haskell), в котором мало лишних токенов (т.е. не Java), меньше “лишних” выборов, и вообще все квадратно-гнездовое — например, Go. Кто-то так себе инфраструктуру для управления облаком навайбил.
- Все ревьюить и тестить.
Кажется, что при всем этом написание непосредственно кода инкрементального улучшения — малая доля потраченного времени.
В целом, если в вашем проекте не может быстро разобраться крепкий джун с небольшой помощью, то джун потупее (ИИ-агент) не сможет и подавно. Еще есть проблема: джун учится на своих ошибках, а агент — нет (хотя скоро наверно технологии дойдут и до этого). Ну и непонятно, откуда браться новым сеньорам, которые умеют все вышеперечисленное, если всех джунов на рынке поменяют на ИИ.
Аналогично работает и с точки зрения пользователя: если интерфейс/API сложные/непонятные, и чуть что, надо RTFM, то и у чат-ботов будут трудности с использованием вашего ПО. Лучшие продукты — это те, которые в которых сложные задачи решаются просто.
Data-driven подход к разработке продукта
Занятный доклад про подход к управлению продуктам. По сути, это ода метрикам и data-driven подходу.
Основная идея состоит в том, что надо максимизировать получение измеримых бизнес-показателей и оптимизировать под них. Продукт — не бэклог из фич, и всем пофиг сколько вы сторипоинтов закрываете в неделю, если бизнесу от этого ни горячо, ни холодно.
Фичи надо жестко A/B-тестить, обложиться алертами, разработка фичи — это контролируемый эксперимент. Протестили 100500 вариантов, если что-то не поменяло метрику — то код в помойку, остальные — на доработку. Надо регулярно думать не что добавить, а что не приносит ценности, и безжалостно удалять. Пользователи врут, надо смотреть на реальное поведение, а не на то, что говорят.
При этом утверждается, что какие-то из озвученных подходов смогут сработать даже не в единорогах с миллионами пользователей.
С одной стороны, вроде тезисы верные, разработчикам деньги платят из прибыли все-таки (ну или из чемодана инвесторов). С другой — кажется, что только ситхи все возводят в абсолют, и термин enshittification не просто так придумали. По логике автора доклада телеметрия должна быть отличной штукой:)
Не доверяйте пакетам, оставленным без присмотра
Оригинальный способ использовать GPT: засквоттить имена пакетов, которые чат-бот нагаллюционировал. Привет экосистеме JS с left-pad :)
Обновление IntelliJ
На днях обновил IntelliJ до последней версии. Уже приготовился настраивать классический интерфейс вместо нового, чтобы было “как раньше”, это уже почти стало привычкой: “опять иконки перерисовали и сделали все неудобно”.
А потом попробовал — а новый интерфейс, оказывается, … удобный! Сам с себя удивляюсь, что такое возможно.
Киллер-фичей для меня стала возможность засунуть кнопки для действий на верхнюю панель — более чем уверен, что и раньше можно было что-то подобное делать, но сейчас явно стало проще. Туда сразу попали и Diff, New Scratch File и Zoom, которые раньше через Shift+Shift находил. Плагин для запоминания горячих клавиш идет прямиком в помойку. Без багов, правда, не обошлось, что делать.
Ну а еще приятно, что в этом релизе есть маленький PR от меня.
Вайб-режиссер для GPT
В дикой природе миллион советов про то, как правильно спрашивать “ИИ”, чтобы получать правильные результаты. Если кто вдруг забыл, то GPT — это чат-бот на стероидах для генерации правдоподобного текста, а не интерфейс к энциклопедическим знаниям. Очень частый рецепт: определите роль, задайте цель, укажите ограничения и желаемый формат вывода. Иногда к этому добавляют “расскажите об аудитории”.
Честно говоря, запоминать правила для промтов — уныло. Да еще и меняются они периодически. “Ты ж AGI”, давай уже мне ответ без вот этих всех реверансов, железяка! И вообще, я аж две кнопки нажал — погугли и подумай!
Но если хочется повайбить, то простая мнемоника для запоминания (придумал не я, если что) — представить себя режиссером, который говорит актеру, что ему надо делать. А актер пусть там сымпровизирует чего, пипл схавает.