Тут Firefox выпустил обновление, в котором “во имя приватности” добавил отправку “анонимизированных” данных на специальный сервак, чтобы потом делиться с рекламодателями. Само отвратительное, что фича включена по умолчанию, и это расстроило интернет.

Инструкция по отключению. Заодно можно и телеметрию отключить.

Есть еще репозиторий с кучей настроек приватности для ФФ — он у меня валялся в закладках около года, но руки так и не дошли настроить — очень сложно, до свидания :/

Обычного strict-режима вроде хватает, а идеал вряд ли достижим.

Ну и не могу не процитировать коммент к предыдущему посту по теме:

#неуловимыйджо

Один репозиторий может содержать несколько GitHub Actions. Примеры: 1, 2. Это удобно для группировки нескольких действий. Чтобы выбрать нужное, достаточно добавить папку:

- uses: username/repo/folder@tag

Увы, я этого не знал, и в первой итерации городил костыли, не делайте так:)

Если коммит последний, то просто удаляем его и создаем заново.

Правильный способ — с помощью интерактивного rebase. Из консоли это делать — так себе затея, но есть вариант и с помощью IntelliJ.

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

Занятная история про то, как Zig выкинул исходники на плюсах для самосборки в пользу многоступенчатого процесса, в котором фигурирует компактная виртуальная машина с WASI/WASM. При этом компилятор сей все равно понадобится.

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

Требования по воспроизводимости обычно предъявляют мейнтейнеры пакетов (например, в Debian или nix). Увы, то, что описано в статье, не совсем воспроизводимо по таким критериям, т.к. содержит бинарный код для WASM, но все равно прикольно. RISC > CISC!

Можно настроить GitHub Actions, чтобы автоматически ребейзил одну ветку поверх другой.

Звучит элементарно, но есть нюансики: действие checkout по умолчанию скачивает только 1 ветку (что логично), а для ребейза нужны какие-то правдоподобные данные о пользователе.

Мне это понадобилось, для того, чтобы шаблон минимального воспроизводимого примера (aka MWE) был в актуальном состоянии для обоих вариантов DSL.

Отличная статья про то, что надо заботиться о разрабе и не грузить его информацией.

Я порадовался, что это немного перекликается с моими тезисами из 2018, которые я нарандомил практически из головы по своим ощущениям.

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

Другой тезис, с которым я бы поспорил — слоеная архитектура. С одной стороны да, не надо городить абстракцию ради абстракции, но с другой — какое-нибудь разделение на model, services, controllers уже стало паттерном и проще смотреть на шаблонные микросервисы с понятными локациями (похожее мнение есть и в комментах). Безобразно, но единообразно!

Коротко о том, как у меня примерно было написано резюме (по всем заветам и рекомендациям).

Написано: Оптимизировал скорость сборки сайта в 5 раз, что существенно увеличило продуктивность разработки.

Что по факту: Время конечно реально уменьшилось, с примерно 30 секунд до 6. Но сделано это было за счет костыля: вместо генерации заголовка страницы каждый раз просто вставлять уже сгенерированный. Разработчик один (эт я), время потраченное на поиск решения (час в самолете) вряд ли стоит выгоды (25 секунд раз в месяц в среднем). Так-то надо уже движок менять, который вряд ли задумывался под 400+ страниц, но лень. А в отрыве от контекста звучит солидно.

Часто тесты называют первым использованием вашей программы. А вот вторым использованием программы можно назвать… документацию.

На старой работе с проектным подходом мы, как правило, описывали все основные алгоритмы. И уже тогда иногда всплывали некоторые косяки (тупо за счет смены точки зрения): документация еще раз способствует размышлениям об общей картине и о крайних случаях. А замечательная техписатель, когда писала руководство пользователя, находила нам баги:) Как выяснилось, такое работает и при разработке инструментов (и библиотек): соседняя команда нашла баг, когда писала документацию.

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

Сабж. Неплохо дополняет видосы с канала, который рекомендовал ранее.

В программировании никому нельзя доверять, особенно самому себе. Заметил недавно за собой привычку — ревьюить свой же PR, как будто мне его прислали на ревью. Подобно тому как e-mail перед отправкой перечитываешь или сообщение в бложек перед публикацией. Особенно помогает, когда над PR работал с перерывами. Можно конечно и перед каждым коммитом это делать, но тогда не всегда видна полная картина, да и CI может подкинуть свинью в виде упавшего теста или чего-то в этом духе.