С одной стороны, недавно был релиз, и он еще используется в Mozilla, nginx. Но, например, Facebook планирует отказываться от него.

Даже до прекращения поддержки на BitBucket, Mercurial’ом пользовалось около 3% людей. Доля пользователей Mercurial была мала даже в 2010х. Если посмотреть на тренды гугла или поискать вакансии, то у Mercurial все грустно.

Так что да, Mercurial скорее мертв, чем жив. Немного жаль, ведь команды Mercurial более интуитивны, да и сам он проще и логичнее. Хотя сейчас почти всю работу в этом плане делают среды разработки, которые поддерживают в основном только git, а остальное — по остаточному принципу.

Интересный доклад про производительность и как ее правильно измерять. Доклад из введения и двух частей.

Суть первой части:

• производительность приложения довольно сильно зависит от расположения кода и данных в памяти, разница может доходить до 40%;
• почти любое изменение кода это расположение меняет;
• оно еще зависит от порядка линковки, размера переменных окружения, версий библиотек, текущей директории и т.п.
• чувак разработал инструмент, который рандомизирует расположение и позволяет понять лучше влияние изменений на производительность;
• эксперименты показали, что -O2 и -O3 статистически неразличимы.

Суть второй части:

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

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

dig txt +short maybethiscould.work

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

Но у обоих есть недостатки: COPY может выгрузить данные по запросу, но только в CSV формате. А pg_dump может выгрузить в формате sql-скрипта, но только всю таблицу целиком. Но если таблица не очень гигантская, то поможет grep:

pg_dump --table=table_name --data-only --column-inserts --dbname=postgresql://user:pass@ip:5432/dbname > dump.txt
cat dump.txt | grep some_id

Классный интерпретатор λ-выражений со встроенным обучением λ-исчислению. 42 задания, первые штук 15 — обучение синтаксису, но потом пойдет веселее. Например, в 25-26 задании можно узнать, что такое Y-комбинатор, а в 30 будет первое задание на вычисление чего-нибудь. Под конец можно будет научиться складывать числа (и это тяжелее, чем возведение в степень!).

Бонус для тех, кто дошел до конца:

(λpdri .rdmpl pi et) oY_ (λa . (FALSE ONE t)a)(ZERO dd)s!

Git — очень гибкий инструмент. Хоть по умолчанию его утилиты, такие как diff и merge, работают со всеми файлами как с текстовыми, это можно изменить. Например, можно переопределить драйвер для merge и мержить xml файлы менее болезненно. Или показывать diff для офисных файлов — один из моих студентов так диплом хранит (не приучен к латеху, увы).

Статья-указатель на оные. Вкратце, есть три группы моделей:

1. Централизованные — для решения глобальных проблем и проблем координации: стратегии, стандарты, ценности, постановка целей, метрики и приоритезация.
2. Основанные на конкретной роли — для редких случаев: менеджер глобальных проектов (программ), интегратор, контролер, разработчик стандартов.
3. Для координации команд — самая большая категория, 17 штук.

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

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

Помню, при первом знакомстве с Ubuntu 6.10 в далеком 2007 году я по незнанию выбрал просто “русскую раскладку”, а не “Windows раскладку”, и у меня неплохо так припекло: почему это для набора запятой нужно нажать Shift + 6, а на привычном месте — слэш? Кто эту дичь придумал? Так вот, ее придумали в Apple:)

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

Чтобы как-то разобраться с этим безобразием, можно использовать Karabiner-Elements. UX у него удручающий, но зато с помощью заготовленных правил можно переназначить клавиши: сделать Home и End более привычными и включить 4-5 кнопку мышки.

А вот для исправления раскладки правила не было — странно, что его еще никто не сделал. Пришлось сделать самому. Разрабатывать свое правило было немного болезненно, потому что это голый JSON с кучей копипасты, и для установки локального правила надо использовать гиперссылку вида karabiner://karabiner/assets/complex_modifications/import?url=file%3A%2F%2F%2FUsers%2Fov7a%2FDocuments%2Fremap_ru.json с ручным удалением для обновления:( А еще в русской раскладке никак нельзя набрать обратный слэш, пришлось с этим смириться. Но в итоге мой PR приняли, а само правило можно найти тут.

Узнал пару недель назад, что почти все стандартные операции обозваны паттернами:

1. Timeout: не надо ждать ответа бесконечно.
2. Deadline: вместо относительного таймаута делать абсолютный, чтобы цепочка вызовов работала адекватно. См. также про токены отмены.
3. Retry: можно тупо попробовать еще раз.
4. Circuit Breaker: вставляем прокси перед целевым сервисом, считаем ошибочные запросы. Если их много, то даем ошибку сразу, не спрашивая целевой, в течение какого-то периода.
5. Fallback: если не получили ответ, придумываем его сами.

А если копнуть глубже, то паттернов устойчивости гораздо больше.

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

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