Захотелось потешить свое эго и вывести красиво список своих PR.

Попробовал несколько готовых страничек, но они все были унылы в той или иной степени (я конечно все понимаю, но смотреть сгенерированный сториз — ну, такое).

В итоге сделал свою. Причем включил максимальный уровень лени и сделал это чистым promt-инженерингом: все написал ChatGPT за 7 коротких промптов, я ни строчки в коде не тронул.

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

В продолжение поста про кроссплатформенность bash: даже если вы проверили скрипт каким-нибудь shellcheck на совместимость с POSIX, это не значит, что он будет работать на всех POSIX-совместимых платформах. Это даже не значит, что работать на всех современных POSIX-совместимых платформах, потому что есть какая-нибудь z/OS для мейнфреймов, которая вышла 1,5 года назад, и которую кто-то даже использует.

Очевидно, что у POSIX есть несколько версий стандартов, причем последняя — аж от 2024 года! Изменения не очень впечатляющие — всякие API для C11, флаги к командам, которые и так уже были, удаление устаревших API и т.п. Т.е. это скорее фиксация текущих распространенных практик, чем изобретение чего-то принципиально нового.

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

Но не все так просто. Есть и более адекватные причины ограничивать размер пароля:

• DoS (тратим много лишнего CPU на хэширование пароля из миллиона символов и/или ваш сервер не может обработать запрос больше мегабайта).
• Атака на переполнение буфера (в ваш массив на 256 байт, которого хватит всем, запихнули 257 символов).
• У алгоритма хэширования могут быть ограничения. Знали ли вы, что у bcrypt есть ограничение на длину и что это реальная проблема даже в современных реализациях?

Еще могут упомянуть интеграцию с легаси-системами, но это по сути то же самое, что хранить пароль в открытом виде и/или переиспользовать его. Уж лучше использовать какой-то алгоритм деривации для подобного.

Но чаще всего ограничение сверху это чья-то ошибка, потому что обычно это не 50-100 символов, которые могут быть адекватными, а 16-20. Больше дебильных правил можно найти тут.

P.S. Если спросить ChatGPT про то, зачем ограничивать длину пароля, никакого намека на ограничения алгоритма он вам не даст.

В топ-3 статей Хабра за январь — статья, написанная ChatGPT. Где-то наверху рейтинга за ту же неделю — статья-жалоба, как все стало плохо. Примерно через 2 часа, как я пролистал первую, выходит еще одна — Хабр мертв, где анализируется еще одна статья из недельного топа, написанная нейронкой.

В прочем, ничего нового. Подобные статьи о том, как все стало плохо, выходят регулярно. Мертвый интернет все-таки, что вы хотели.

Раньше трава была зеленее и все такое. Помню, как в универе читал почти каждый день главную страницу, и это было весьма интересно. Потом заматерел и читал жестко отфильтрованную ленту подписок, старался ничего не упускать ничего. Потом скатился к топу за неделю. Был какой-то момент перерыв года на два, потом снова начал читать. Но уже хватает терпения максимум страниц на 5, и открываю из этой сотни статей штуки 3 от силы, чтобы прочитать дальше заголовка абзаца полтора.

Если с какого-то HackerNews я достаточно регулярно публикую что-то в #утюг, то с Хабра в 2021 году репостнул штуки 3, в 2022 пара статей пришлась в тему/подкинули идею, в 2023 была топ-статья про ICMP-туннель, а в 2024 — вообще ничего.

Кажется, пора бы уже на научные статьи переходить, пробовал года полтора назад поиграться с фильтрами на arXiv, но слишком много результатов, которые непонятно как фильтровать, да и хочется все-таки более практически применимого материала. Так и и не понял, где смотреть хорошие статьи :(

После эксперимента с OpenRewrite планировал посмотреть что-то более надежное, а именно Txl. В целом, я остался доволен экспериментом.

Чтобы получить общее впечатление, я не изобретал велосипед и тупо выполнял задания из Txl Challenge. Примечательно, что там предлагается общаться по почте с одним из “Оракулов”, чтобы получить помощь (делать я этого, конечно, не стал).

Язык не очень сложный — все основы можно почерпнуть из презентации. Однако документация в целом не супер — это набор PDF. Искру добавляет неироничное использование шрифта Comic Sans.

Установка оказалась простой. Ошибки не очень дружелюбные, но при этом цикл обратной связи достаточно короткий.

Киллер-фича по сравнению с OpenRewrite, на мой взгляд, — это валидация выхода: вместо просто “текста” на выходе получается тоже АСД. Т.е. замена либо применится и это будет корректный код, либо будет пропущена. Увы, за это приходится расплачиваться тем, что надо иметь хорошую грамматику для целевого языка и задабривать компилятор: например, if -> if преобразовать просто, а if -> switch уже тяжело, потому что типы другие.

На 3 задании долго тупил как раз из-за непоняток, как правильно преобразовывать типы, и в итоге пришлось подсмотреть готовые решения на GitHub. Еще у меня почему-то не работал [list X], да и в целом любые преобразования кроме 1 к 1 давались тяжело. При этом преобразования 1 к 1 выглядят чуть ли не как куски кода из оригинала (“возьми такое и замени на сякое”).

У технологии, на мой взгляд, 2 основных минуса. Во-первых, откуда-то надо добыть грамматику. Для какой-нибудь Java это легко, для чего-то типа Kotlin — до свидания. Во-вторых, как я понял, нет никакого способа предоставить контекст. С какими-нибудь функциями расширения Kotlin — удачи понять, откуда метод и что там сейчас в качестве this. Т.е. совсем произвольный код не очень понятно как преобразовывать с учетом того, что могут быть подключены библиотеки.

При всем при этом группа ученых смогла написать скрипт для перевода Java на C#. Правда только с версии 1.1 и это заняло 8 месяцев.

Еще отмечу, что первая версия Txl появилась аж в 1985 году. В целом, мне кажется, что фундамент вполне хороший и если бы инструмент немного набрал бы популярности в нужное время, то описанные проблемы могли бы быть решены.

Мне лень учить горячие клавиши для многих приложений, и IntelliJ не исключение. Давным давно я запомнил штук 10 от силы, а для остального кликаю мышкой (ну или ищу через два шифта). Тем более что все возможные комбинации запомнить нереально имхо, да и не стоит оно того. Короче, максимально неправильный разработчик.

Случайно наткнулся на плагин, который “учит” комбинациям клавиш для конкретно ваших частых операций. И за 2 недели использования он что-то конечно предложил, но я вижу ровно ноль пользы от запоминания комбинации, когда вот кнопка на интерфейсе, даже ни в какое подменю не надо заходить. Короче, 0 новых выученных комбинаций.

Увы и ах, опять придется тратить время на то, чтобы что-то делать не супербыстро. Есть риск, что появятся мысли.

Сабж. Про разницу масштабов я надеюсь все в курсе, но тут интересна еще динамика их изменения. Ну и что абстракции не бесплатны, не стоит забывать.

Редко когда это нужно, но может пригодится — можно запустить что-то в параллели или последовательно для отладки — клиент + сервер или приложение + удаленный дебаггер. Но, например, для запуска нескольких тестов лучше сделать отдельную задачу в билд-скриптах.

Во всяких CI и/или тестовых окружениях обычно не нужна вся история коммитов, а достаточно выгрузить состояние репозитория на момент определенного (чаще всего последнего) коммита. Чтобы сэкономить время и снизить вероятность ошибки сети, если она нестабильна, можно вместо тупого clone сделать неполный:

git clone --depth=1 <remote-url>
# или
git clone --depth=1 <remote-url> --branch <branch_name> --single-branch <folder_name>

Больше опций можно посмотреть в статье от GitHub, а сравнение скорости для некоторых репозиториев — тут (до 25х быстрее).

Еще возникает иногда желание склонировать только коммиты из ветки (например, для того, чтобы проверить каждый из них на вшивость), но, увы, это сложнее. Даже стандартный checkout от GitHub это пока не умеет. Всякие обходные пути можно найти в том же тикете.