У меня с браузерными тестами и selenium в частности весьма неоднозначные отношения: с одной стороны — автоматическое тестирование — это хорошо, с другой — много видимых пользователю косяков можно легко пропустить (т.е. руками все равно надо будет тестировать) и, по моему опыту, тесты очень хрупкие.

И вот была у меня недавно проблема с частью браузерных тестов уровня “нажми сюда и попадешь на эту страницу”: в CI работает, локально — нет: остается на той же странице. В логах пусто, никаких индикаторов о том, что происходит — нет. Некритично, но неприятно. Потратил кучу времени: может не нажимается? Нажимается, но не работает. Пробовал и так, и сяк (рандомные советы из интернетов) — не работает и все. Я мужественно забил и отложил эту проблему на пару месяцев.

Недавно, после очередного обновления хрома (в котором у нас тестируется) и селениума опять запустил тесты — и, в headless-режиме, который не подразумевает никакого интерфейса, вижу, как мелькает окошко от хрома — твой пароль небезопасен!!1. И правда, в тестах логина, которые локально не работали, использовался p@ssw0rd. Заменил его на “более сильный” (хотя надо было бы генерировать, по-хорошему), и тесты “починились”. Т.е. благодаря багу хрома я смог обнаружить проблему, о которой не сообщал selenium :/

Все в курсе, что у git раковый UX, но даже он не перестает удивлять. Вот есть в репозитории теги:

$ git tag
v1
v2

Уже на этом этапе я обычно хочу написать tags, ну да ладно. Вот я хочу посмотреть список коммитов, на которые эти теги указывают. Берем первый ответ из гугла:

$ git show-ref --tags
1baddd8efa7f0afac329e16876d94fa54febef4f refs/tags/v1
24105f5ffeb2c93c8dd6f8f10ce0d1701e67a1cd refs/tags/v2

Вроде все логично, однако если сравнить этот вывод с историей:

$ git log --pretty=format:"%H %s"
0c4bd3ad8d403463fbdd6dda50bfe7834ecd2634 second commit
1baddd8efa7f0afac329e16876d94fa54febef4f first commit

То видна проблема — хэши не совпадают. Тут я должен вспомнить, что в git есть два вида тегов: обычные и аннотированные, в которых есть сообщение, автор и т.п.:

$ git for-each-ref refs/tags --format="%(refname:short) %(objecttype)"
v1 commit
v2 tag

Ладно, но как получить то, что я хотел? Для одного тега проще всего запомнить git show $tag, а вот для всего списка нужно всего лишь

$ git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname:short)' refs/tags
1baddd8efa7f0afac329e16876d94fa54febef4f v1
0c4bd3ad8d403463fbdd6dda50bfe7834ecd2634 v2
24105f5ffeb2c93c8dd6f8f10ce0d1701e67a1cd v2.1 # oops!

Но даже этот метод (от мейнтейнера git, между прочим!) — неправильный, потому что аннотированные теги могут быть вложенными. Поэтому надо сделать

git tag | while read tag; do echo "$(git rev-parse $tag^{}) $tag"; done

Оказывается, в инструментах разработчика можно подправить JS-скрипты, загруженные на странице. По сути скачиваешь скрипт, редактируешь его на компе, перезагружаешь страницу — и используется уже он. В Chrome было давно, в Firefox появилось сравнительно недавно.

Понятно, что если приложение полностью под контролем, проще его пересобрать, а что-то мелкое можно и через консоль протестировать. Однако если код не полностью под контролем (например, он сгеренирован каким-то экзотическим языком) и/или как-то нестандартно связан с другими модулям — так может быть проще.

Мануал по постмортемам от Гугла. Немного водянисто, но суть достаточно проста: не надо искать козла отпущения, а надо сфокусироваться на том, что случилось, почему и как предотвратить подобное в будущем.

Некоторые хорошие тезисы, на мой взгляд:

• Нельзя “исправить” людей, но можно исправить систему/процессы, чтобы стимулировать правильные решения (и предотвратить человеческие ошибки).
• Должно быть видимое поощрение за улучшение процессов (хотя в оригинальном тексте это звучит как поощрение за тушение пожара, что не очень).
• Нужно шарить результаты с коллегами, чтобы они улучшали свои процессы и системы на вашем опыте (если у вас похожий стек технологий и процессы, что с большой вероятностью правда, если вы в одной компании).
• Нужно делать все вовремя, а не когда-нибудь потом и для бюрократической галочки. Ценность постмортема — не в документе, а в последствиях.

Когда не грузится сайт, я обычно машинально проверяю, работает ли у меня интернет при помощи ping 1.1.1.1. Недавно коллега упомянул, что ping не нужОн и вообще устарел как средство диагностики сети. Я что-то такое смутно подозревал конечно, но явно не осознавал. Вышел в интернет с вопросом и выяснил, что

• ICMP Echo отключен по умолчанию в большинстве нормальных облаков для защиты от DDoS ping flood, ping sweep и прочих.
• Некоторые провайдеры даже отключают ICMP Echo по тем же причинам.
• В кубере пинг тоже не будет работать, но это скорее для простоты.
• И в Software-Defined Networking (SDN) та же история.
• У большинства роутеров ICMP-траффик имеет низкий приоритет обработки и при нагрузке они могут дропать эти пакеты.
• Поскольку в ICMP можно запихать произвольную нагрузку (можно даже туннель сделать), малварь может использовать его для C&C, поэтому многие режут ICMP файрволлом.

Ping only tests for the ability to respond to pings, so that’s base OS, parts of the IP stack and the physical links - but that’s all, everything else could be down and you’d not know.

Предлагается использовать tcping с конкретным портом, а для более качественной диагностики — traceroute. Хотя кажется в моем сценарии “проверить интернет” — и так сойдет :)

Нет, не контра. На прошлой неделе на HN попал в топ “майнкрафт” на чистом CSS. Если копнуть поглубже — то это скорее грамотная подача — все блоки заранее поставлены, а пространство ограничено кубом со стороной 9. Т.е. в пределе это сводится к задаче вкладок на чистом CSS.

Вообще идея не нова — был и на хабре несколько лет назад период ужимания игры по строкам JS, который в итоге превратился в CSS. Например, была охота на уток, сайд-скроллер и типа старкрафт. Я, когда делал свою галерею на чистом CSS, откапывал даже FPS, который оказался ложью (там есть JS, а сейчас оно еще и поломалось). Вообще такого добра навалом: 1, 2, 3, 4…

Недавно опять получил сесурити-алерт от 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.

Довольно специфичная проблема для мейнтейнера OSS-проекта: по ошибке переместил тикет из открытого репозитория GitHub в приватный, а обратить эту операцию GitHub не разрешает (даже не предупредил, зараза).

Решение довольно очевидное: сделать временный приватный репозиторий, переместить тикет туда, а потом сделать репозиторий публичным — и вуаля, уже с публичным тикетом можно делать что нужно.

Крутая и наглядная статья. Не зря Rust лучше остальных компиляторов в этом плане.

Неплохой доклад про работу с исключениями, в котором:

• рассказывается про оптимизации, связанные с NPE, ArrayIndexOutOfBoundsException, ClassCastException;
• оптимизации, связанные со стектрейсом;
• приводятся примеры исключений, которых не стоит ловить;
• рассказывается об областях стека вызовов и связи локов со StackOverflowError;

Бонус — исключение ChuckNorrisException, которое нельзя поймать.

Выводы очевидны, но повторение — мать ученья.