Читать в телеге. Когда-то там были посты не только от меня.
Проблемы автонастройки БД
Доклад про то, почему тяжело автоматически оптимизировать БД всякими млями-шемелями. Спойлер: проблемы в основном организационные, мощных технических деталей нет.
Сами проблемы обозначены на 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 и т.д. Случилось это из-за того, что токен использовался для локальной отладки, из кода был удален, но поскольку скрипт не перезапускался, то он остался в кэше.
Комбо зачетное: вечный токен без ограничений, утечка секретов через кэш, мусор в образе публичная репа для непубличного кода.
Будущее программирования взглядом из 1973
Прекрасный доклад 50-летней давности про будущее программирования. На основе уже имевшихся тогда концептов удалось предсказать многое: WYSIWYG, декларативный подход, повсеместность регулярок, распространение интернета, GUI, Scratch, IDE, многоядерные процессоры (забавно, что полупроводниковая микросхема была суперновинкой на момент доклада).
Но есть и несбывшееся. Например, была классная идея про то, что протокол взаимодействия должен выводиться автоматически, а не быть жестким: “нам никогда не придется иметь дела с API”. :harold: Если подушить, то что-то похожее есть, например, в TLS, но это слишком низкоуровнево. Есть еще HATEOAS, но его полтора землекопа используют…
Была надежда на интерактивное программирование, но даже сейчас это просто концепт. И очень грустно было слышать, что если даже в 60-е смогли сделать отзывчивый интерфейс, то в будущем никогда не будет лага у интерфейсов. Прости чувак, тут мы точно многое просрали…
В контексте многоядерных процессоров всплыла модель акторов, даже была отсылка к Erlang, но это тоже не взлетело. “Если через 40 лет мы все еще используем потоки и локи, то… мы полностью провалились в разработке”. :harold: Конечно, сейчас это считается низкоуровневой абстракцией, но это все еще живее всех живых (даже на собесах нет-нет и спросят про механизмы синхронизации).
Завершается доклад мыслью о том, что надо не переставать искать новые подходы и идеи в своем деле, иначе развитие остановится и будут только догмы.
"Приватность" в Firefox
Тут Firefox выпустил обновление, в котором “во имя приватности” добавил отправку “анонимизированных” данных на специальный сервак, чтобы потом делиться с рекламодателями. Само отвратительное, что фича включена по умолчанию, и это расстроило интернет.
Инструкция по отключению. Заодно можно и телеметрию отключить.
Есть еще репозиторий с кучей настроек приватности для ФФ — он у меня валялся в закладках около года, но руки так и не дошли настроить — очень сложно, до свидания :/
Обычного strict-режима вроде хватает, а идеал вряд ли достижим.
Ну и не могу не процитировать коммент к предыдущему посту по теме:
#неуловимыйджо
Несколько GitHub Actions в одной репе
Как разбить коммит на два
Если коммит последний, то просто удаляем его и создаем заново.
Правильный способ — с помощью интерактивного rebase
. Из консоли это делать — так себе затея, но есть вариант и с помощью IntelliJ.
Неправильный способ, который сработает в некоторых случаях и который “проще”: частично откатить нужный коммит (возможно отредактировав; поскольку он верхний, то это просто), сразу же откатить его, сквошнуть откат с оригиналом и потом поставить откат отката куда надо.
Bootstrapping для Zig
Занятная история про то, как Zig выкинул исходники на плюсах для самосборки в пользу многоступенчатого процесса, в котором фигурирует компактная виртуальная машина с WASI/WASM. При этом компилятор сей все равно понадобится.
Подобные выкрутасы интересны с точки зрения воспроизводимости сборки, точнее, уменьшения количества кода, нужного для этого. В статье том числе описаны стандартные подходы, которые используются в других языках.
Требования по воспроизводимости обычно предъявляют мейнтейнеры пакетов (например, в Debian или nix). Увы, то, что описано в статье, не совсем воспроизводимо по таким критериям, т.к. содержит бинарный код для WASM, но все равно прикольно. RISC > CISC!
Автоматический ребейз ветки
Можно настроить GitHub Actions, чтобы автоматически ребейзил одну ветку поверх другой.
Звучит элементарно, но есть нюансики: действие checkout
по умолчанию скачивает только 1 ветку (что логично), а для ребейза нужны какие-то правдоподобные данные о пользователе.
Мне это понадобилось, для того, чтобы шаблон минимального воспроизводимого примера (aka MWE) был в актуальном состоянии для обоих вариантов DSL.