Сайтик с немного рандомным и местами экзотическим набором утилит, связанных с криптографией: перестановочный шифр из Камасутры, разложение числа на множители, SHA256 (который почему-то в шифрах), штрихкод и т.п. Есть неплохая анимация AES с описанием. Может подойти тем, кто мало знает про криптографию: представлено много “простейших” шифров.

В продолжение темы про маршутизатор для браузеров.

Вот допустим я хочу из браузера открывать ссылки во внешнем приложении. Как это сделать? Нужно расширение. Но есть проблемка: нельзя просто так взять и запустить какое-то там приложение из браузера. Даже по команде 300 раз одобренного расширения. Нужно использовать обмен сообщениями, и специальное приложение-клиент, которое принимает эти самые сообщения в простом формате (бинарная длина + само сообщение) через стандартный поток данных. Регистрация всего этого — гемор, вдобавок, для Firefox и Chrome есть отличия.

Есть обходной путь: использовать протоколы типа tg:// или zoommtg://, которые открывают ссылку в другом приложении. Например, если на маке набрать в Chrome firefox:https://example.com, то откроется Firefox с указанным адресом. Chrome так уже не умеет, но не очень-то и хотелось: можно зарегистрировать протокол для своей утилитки.

Как зарегистрировать протокол в Linux? Добавить немного метаданных в ярлык и добавить 2 команды. Увы, браузеры отслеживают этот список отдельно, и чтобы ссылка работала еще и в браузере, надо хоть раз по ней внутри браузера кликнуть (иначе будет перенаправление в поиск). Ну еще и утилиту надо обновить парой строчек, чтобы отрезала “лишний” префикс.

Как зарегистрировать протокол на маке? Тоже добавить пару строчек метаданных в ярлык и… страдать, потому что передача ссылки опять идет через Apple Events, а не через аргументы командной строки.

Да-да, там код Рида-Соломона для исправления ошибок. Но это чисто данные. А что есть кроме них? Версия QR, тип данных и т.п.? Вот про это есть страничка. Она чуть-чуть интерактивная, т.к. можно использовать любой QR-код, чтобы разобрать его содержимое.

Довольно неплохая статья про организацию асинхронного общения.

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

На мой взгляд, культура компании очень сильно на это влияет. У многих большие трудности с тем, чтобы сделать повестку встречи и понять, что вообще от встречи требуется. Заметки по итогам встречи (да и вообще какие-то артефакты) оставляют единицы. Готовиться ко встрече, на которую тебя пригласили? “Да ну, зачем” или “я очень занят, мне некогда”. Плюс встреча это практически набор голосовух со всеми минусами. В итоге встреча превращается в какое-то коллективное бессознательное: собрались, поговорили, а вот зачем, с каким итогом и что вообще обсуждали ­— пес его знает.

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

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

В гугл-доках можно включить распознавание (автозамену) Markdown. Забавно, что это в русской версии указано как “автоматически распознавать разметку”, как будто других видов разметок нет. Поддержка довольно урезанная:

• Всякие преобразования текста (жирно, курсивом, моноширинно и т.п.) поддерживаются.
• Блоки кода с ``` — только в платной версии (потому что блоки кода в принципе только в ней и доступны). Но они не очень полезны в любом случае (и там только 4 языка: C++, Java, JS и Python).
• Заголовки работают.
• Ссылки [ty](http://id.or) не работают, так что только выделение + Ctrl+K в помощь. Картинки тоже не работают.
• Цитаты > не работают.
• Списки — вроде как да, но у меня иногда багает.
• Разделители --- — не поддерживаются, но с другой стороны в документах они и не нужны особо.
• Таблицы — мимо.
• Сраные смайлики — выпрыгивают после :. К счастью, можно это отключить там же, где и Markdown включается.
• Подстрочный или надстрочный текст — тоже не работает (поставьте LaTeX уже наконец).

Еще можно поставлять всякой дичи при автодополнении @, например, даты, людей, эмодзи для голосования (sic!) и т.п.

Интересно, есть ли где-то хоть сколько-нибудь адекватно систематизированное планирование? У меня по этому поводу в основном не очень позитивный опыт.

Чаще всего встречался подход “делаем, потому что надо” и HiPPO (Highest Paid Person Opinion). Это кстати не такой уж и плохой вариант, если ответственное лицо адекватное, да и меньше времени требует. Есть чуть более формальные вариации (например, MoSCoW, Kano model), но это примерно то же самое в итоге.

Но мы же сейчас в бигдате, надо data-driven! (И телеметрия!) Тут легко обмазаться метриками в комбинации с экспертными оценками и “предсказывать”, как эти метрики улучшатся при добавлении фичи. И из всего этого получить для каждой фичи какое-нибудь число, например, линейной комбинацией нескольких параметров (так еще некоторые студенты в дипломе делают, чтобы обосновать превосходство своего решения). Коэффициенты обычно рожаются “экспертной оценкой” и соответствуют текущей стратегии. Есть несколько стандартных шаблонов для этого — например, RICE с кучей вариаций. У такой формализации есть преимущество, что можно “поиграться” с коэффициентами при смене стратегии, и тяжелее ошибиться в раздробленных экспертных оценках, но все равно экспертность никуда не делась.

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

Возвращаемся к простым экспертным оценкам…

Очень хорошая детализация протокола TLS прямо до байтов. Есть такое же для QUIC и DTLS (который используется, например, в WebRTC).

Чтобы публиковать посты в канал, я почти сразу написал скриптик, чтобы решить проблемы с markdown (например, до сих пор в телеге markdown не поддерживает ссылки). Скрипт использовал Telethon, который подключается с использованием моего аккаунта.

Перед новым годом телеграм решил мне выдать бан — разлогинил со всех устройств и долго (больше часа) не давал попасть в аккаунт. Хотя я делал сколько, 10 запросов в неделю? К счастью, помогла переустановка клиента. Было достаточно стрессово: с некоторыми людьми прямая связь только в телеге.

Ладно, давайте попробуем сделать все “правильно”: создаем бота, добавляем его в админы канала, используем python-telegram-bot… и обнаруживаем, что в API ботов нет возможности делать отложенные сообщения -_-.

У Telethon есть аналоги — Pyrogram и MadelineProto. На беглый взгляд при их использовании будет та же проблема с банами. Один раз попал в черный список — и привет:)

Я дошел даже до того, чтобы посмотреть на альтернативные клиенты для веба — A и K. В одном та же проблема с разметкой, а вот второй вроде смог распарсить ссылку, но блоки с кодом поломал: было смещение на 1 символ. Код открыт — отлично, можно сделать PR с исправлением и делать отложки вручную! Вот только в исходниках ноль тестов на парсинг разметки… Ладно, видимо не вариант.

Попробовал пару “советов” по Telethon — перебор диалогов, sleep понаставить, какие-то хаки с system_version — не помогло. В итоге решил-таки попробовать pyrogram (терять особо нечего) — и все заработало :/ Парсит markdown он хуже (у него вообще своя версия), но хотя бы работает.

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

Доклад от создателя Go. Несмотря на то, что докладу уже больше 11 лет, он достаточно простой и фундаментальный, чтобы не потерять актуальности.

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

Отдельный кек — если вы находитесь на странице Concurrency и перейдете на русский перевод, то попадете… на страницу Параллелизм. Справедливости ради, там есть раздел про различие.

Полезный инструмент, чтобы отлаживать GitHub Actions. Скачивает пол-интернета, но работает довольно шустро.

Очевидный бонус — позволяет быстрее проверить работу действий, без засорения репозитория коммитами. Чтобы триггернуть событие, достаточно всего лишь

act -j action_job

или чего-то вроде

act issue -s GITHUB_TOKEN=... -j action_job -e event.json

Еще можно отлаживать action, которое в процессе разработки (правда надо убедиться, что оно есть в каком-то коммите и “загрузить” его):

...
  steps
  - uses: actions/checkout@v4
  - uses: ./my-action