Сабж. В основном все советы годные и по делу.

Кто писал для JVM, встречался с Unsupported class file major version XX. Обычно это означает, что текущая версия java слишком низкая. Но какая версия нужна, например, для 55? Можно использовать табличные значения, но запомнить табличку или ссылку на нее — нетривиально. Проще воспользоваться формулой:

java_version + 44 = class_file_version

Если надо обновить свою фичу-ветку под новую базу, то это проще всего сделать с помощью

git fetch
git rebase <main-branch> --update-refs

Особенно это полезно, когда есть ветки от веток: update-refs рекурсивно обновляет все зависимые. На второстепенных ветках это приходится еще делать из-за того, что GitHub так себе отображает пулл-реквесты не от мастера.

The Culture Map — довольно известная книга про то, как отличается рабочая культура разных стран. Пересказов в интернете полно, например 1 или 2, все можно свести к 8 шкалам.

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

Примеры, основанные на нациях, скорее вредны. Да, может и есть особенности культуры, которые более часто встречаются в той или иной стране, но многие могут ошибочно воспринять, что именно так и будут вести себя ВСЕ люди оттуда. Даже с учетом того, что у меня не такой уж большой круг коллег со всех работ, и большинство, разумеется, из России, я видел много примеров характеров со совершенно разными оценками по этим 8 шкалам. И иногда со своими старшими родственниками мы общаемся в принципиально разных “культурах”.

Вообще эти шкалы — это как с “типами” людей, со всеми их недостатками. Однако про книжку знать скорее стоит, ее (пересказ) можно использовать как один из источников вдохновения для осмысления инженерной культуры в команде.

Довольно подробная статья, в которой про это рассказано.

Доклад про то, почему тяжело автоматически оптимизировать БД всякими млями-шемелями. Спойлер: проблемы в основном организационные, мощных технических деталей нет.

Сами проблемы обозначены на 13 минуте (до этого идет слишком затянутое введение) и на 41-ой. Вкратце:

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

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

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

Еще докладчик посетовал, что автонастройка RDS от AWS толком ничего полезного не делает.

В конце было хоть что-то связанное с МЛ — оказывается, если спросить совета у ChatGPT по настройке БД, то он мало чего путного посоветует (как неожиданно).

Если надо издать какой-то звук после выполнения (или при ошибке) какой-нибудь команды (чтобы во время выполнения заниматься другими делами), то можно:

• воспользоваться командой paplay с каким-нибудь звуковым файлом из /usr/share/sounds,
• “сказать” очень машинным голосом что-то через espeak,
• послать уведомление с помощью notify-send.

На маке это будут соответственно:

• afplay /System/Library/Sounds/Submarine.aiff,
• say lerolerolerolerolero,
• и ужасный osascript -e 'display notification "how hard it can be"'.

В продолжении темы про визуальное/интерактивное программирование — неплохая статья про полезность визуального представления кода.

Вкратце — никому особо не нужны графические свистелки-перделки для написания кода: текст достаточно выразителен, куча инструментов уже готово, рутину убирает IDE. Однако очень полезны всякие штуки, чтобы показывать верхнеуровневые вещи: связь модулей/сервисов между собой, расположение кода в памяти, последовательность обмена сообщениями и т.п. Перекликается с докладом про интерактивное программирование.

От себя добавлю, что в каком-то роде BPMN в связке с чем-то вроде Camunda можно считать визуальным программированием: нарисованная схема бизнес-процесса соответствует тому, как он исполняется и способствует прозрачности. Однако при этом детали реализации будут все равно написаны с помощью “обычного” программирования. Аналогично можно сказать и про конечные автоматы — я не знаком с хорошими готовыми библиотеками, но было несколько раз, когда состояние системы легко было описать конечным автоматом, но по коду это было тяжело отследить (и никакой картинки с состояниями и переходами разумеется не было).

А касательно интерактивного программирования — тут лидируют Excel и питоновские ноутбуки, где обновления будут практически мгновенными; ну и на фронте можно большую часть вещей делать в WYSIWYG режиме (особенно если включен live-reload).

Занятный инцидент случился на днях: питонячий кэш (.pyc-файл) с неактуальным байт-кодом попал в докер-образ. При этом он содержал токен от GitHub с полным доступом ко всей основной инфраструктуре Python: языку, CPython, PyPI, PSF и т.д. Случилось это из-за того, что токен использовался для локальной отладки, из кода был удален, но поскольку скрипт не перезапускался, то он остался в кэше.

Комбо зачетное: вечный токен без ограничений, утечка секретов через кэш, мусор в образе публичная репа для непубличного кода.

Прекрасный доклад 50-летней давности про будущее программирования. На основе уже имевшихся тогда концептов удалось предсказать многое: WYSIWYG, декларативный подход, повсеместность регулярок, распространение интернета, GUI, Scratch, IDE, многоядерные процессоры (забавно, что полупроводниковая микросхема была суперновинкой на момент доклада).

Но есть и несбывшееся. Например, была классная идея про то, что протокол взаимодействия должен выводиться автоматически, а не быть жестким: “нам никогда не придется иметь дела с API”. :harold: Если подушить, то что-то похожее есть, например, в TLS, но это слишком низкоуровнево. Есть еще HATEOAS, но его полтора землекопа используют…

Была надежда на интерактивное программирование, но даже сейчас это просто концепт. И очень грустно было слышать, что если даже в 60-е смогли сделать отзывчивый интерфейс, то в будущем никогда не будет лага у интерфейсов. Прости чувак, тут мы точно многое просрали…

В контексте многоядерных процессоров всплыла модель акторов, даже была отсылка к Erlang, но это тоже не взлетело. “Если через 40 лет мы все еще используем потоки и локи, то… мы полностью провалились в разработке”. :harold: Конечно, сейчас это считается низкоуровневой абстракцией, но это все еще живее всех живых (даже на собесах нет-нет и спросят про механизмы синхронизации).

Завершается доклад мыслью о том, что надо не переставать искать новые подходы и идеи в своем деле, иначе развитие остановится и будут только догмы.