Доклад — базовая база про организацию кода, чтобы он был тестируемым, поддерживаемым, рожь ржилась, пшеница колосилась и т.п. Несмотря на ФП-уклон, суть идеи подойдет к любой парадигме. Солидные сеньоры все из доклада наверняка знают и применяют, но джунам полезно будет. В конце есть еще небольшая секция про управление зависимостями.

Захотелось потешить свое эго и вывести красиво список своих 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 новых выученных комбинаций.

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

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

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