Минутка просвещения

Читать в телеге. Когда-то там были посты не только от меня.

Обучение горячим клавишам в IntelliJ

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

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

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

СсылкаКомментировать

Параллельных запуск нескольких вещей в IntelliJ

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

СсылкаКомментировать

Неполное клонирование

Во всяких 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 это пока не умеет. Всякие обходные пути можно найти в том же тикете.

СсылкаКомментировать

Valhalla для примитивов

Хороший доклад про статус проекта Valhalla, который сможет устранить проблемы, связанные с разделением на объекты и примитивы и сопутствующими оптимизациями (хранить данные на стеке).

В начале идет история примитивов, как и почему они появились, зачем нужен int, когда есть Integer, а также признаются ранние ошибки первых версий Java. Потом собственно рассказ о том, что с этим можно сделать — и тут всплывают и иммутабельность, и “прозрачные” типы, и null-безопасность, и потокобезопасность, и оптимизации в памяти всякие, и проблема частичной инициализации, и т.д. — то, что обычно рассказывают в каком-нибудь модном ФП языке. Представляю горящие пердаки некоторых джавистов, которые с пеной у рта доказывали что котлин не нужон с этой его проверкой на null и иммутабельностью.

Была веселая история про то, что в первых версиях Java примитивный long был потоконебезопасен (sic!). Эта история снова может стать актуальной для value-типов на стеке (если они больше машинного слова). Выход — делать все иммутабельно.

История про проблемы с null напоминает историю Kotlin и его платформенными типами (уж не знаю, что хуже, ссылаться на свою статью на хабре или ее репост в бложике), и типичные проблемы с null-безопасностью — а что будет с массивом значений и т.п. В итоге есть план сделать явное обозначение а-ля Integer?/Integer!.

Увы, обратная совместимость многому препятствует. Нельзя сделать все не-nullable по умолчанию, Integer! и int не получится сделать на 100% синонимами, сериализация вставляет палки в колеса. Есть риск, что Java может превратиться в плюсы с точки зрения синтаксиса (*флешбеки от того, как в C++ записываются лямбды*). Ну и с дженериками еще не все вопросы решены.

В целом выглядит как движение в сторону прогресса, правда очень медленное. Все это продирается через пик сложности — проект начался аж 2014 году. Правильная модель — ключ к успеху, но ее поиски занимают много времени. Слайд с рассмотренными концептами на 44:05 впечатляет. Если отказаться от некоторых «степеней свободы», то куча сложности просто уходит.

СсылкаКомментировать

Игры в PDF

Тетрис. У меня работает только в десктопных браузерах, хотя в комментах на HN нашли и другие приложения, в которых это пашет. Исходники.

И, конечно, Doom. Работает только в хроме. Исходники.

“Игры прикольные, ситуация страшная”:)

UPD: и животноводство! Linux.

СсылкаКомментировать

Старейшая тудушка в коде

Ну уж в этом-то году точно все легаси уберем, да?

Чтобы найти старые TODO в репозитории (и, скорее всего, ужаснуться), можно использовать вот эту колбасу

git grep -i -nE 'TODO|FIXME|FIMXE' | while IFS=: read -r file lineno line; do commit_date=$(git blame -L "$lineno,$lineno" --porcelain "$file" | awk '/^author-time/ {print $2}' | { read epoch; date -u -d @$epoch "+%Y-%m-%d %H:%M:%S" 2>/dev/null || date -u -r $epoch "+%Y-%m-%d %H:%M:%S"; }); echo "$commit_date $file:$lineno: $line"; done | tee >(sort > todos.txt)

(результат будет в todos.txt)

P.S. Особым мазохизмом было получение кроссплатформенного варианта этой команды и выдрать нормальную дату из гита, потому что по умолчанию blame выдавал не очень машиночитаемый формат.

СсылкаКомментировать

"Кроссплатформенность" bash

Годами сидя на линуксе, особо не задумываешься об версиях баша и стандартных утилит: по умолчанию ожидаешь, что cp и в Африке cp, и думать тут много не надо.

Но как только надо написать какой-нибудь не очень тривиальный однострочник, чтобы добавить его в документацию и/или репозиторий, чтобы “работало” везде, сразу возникают проблемы. Например, у какого-нибудь sed есть как минимум две версии: BSD (во фряхе и маках) и GNU (в большинстве линуксов), и они серьезно отличаются.

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

Например, GNU date -Is -ud @249499969321 — это BSD date -Iseconds -ur 249499969321, и если seconds тоже можно использовать в первом случае, то остальное уже не поменять.

Другой пример: в BSD sed “на месте” должен быть явным, -i "", а в GNU должно быть именно -i, без явной пустой строки. Обо всяких \b тоже можно забыть.

Наконец, некоторые вещи можно обнаружить только методом проб и ошибок, например, strftime в awk.

Вишенка на торте: по умолчанию на маках стоит баш версии 3.2 аж от 2007 года (пусть даже ее постоянно патчат, функционально она застыла во времени).

В качестве обходного решения на маке можно… тупо поставить GNU-версии через brew. В среднем по больнице они все равно лучше. Но если это невозможно, то очевидный вариант — обмазать скрипт if/else с проверками на систему или переписать на питон. Еще один обходной путь: вызывать два варианта команды через || с учетом того, что неподходящий вариант отвалится с ошибкой.

СсылкаКомментировать

Дублирование ссылки в Markdown

Понадобилось в во внутренней доке вынести часть ссылок в начало документа, чтобы не искать их в тексте. Оказывается, у Markdown есть механизм для ссылки на ссылку! В любом месте документа (например в конце) добавляем название

[link_name]: https://ov7a.narod.ru/index-1.html

И потом используем в квадратных скобках сколько угодно:

Это [ссылка][link_name]. И [это][link_name] та же самая ссылка.
СсылкаКомментировать