Как известно, sed обрабатывает вход построчно. Если надо заменить многострочный паттерн, то можно воспользоваться флагом -z, который указывает, что конец строки теперь нуль-терминатор \0, а не обычный \n. Например,

echo -e "line1\n\nline2\n\n\nline3" | sed -z 's/\n\n*/\n/g'

выведет

line1
line2
line3

Но работает это только для GNU sed. Маковский такое не поддерживает, и подключить там многострочную обработку — это какая-то магия (которую я даже не буду пытаться запоминать и пробовать).

Занятный видос.

Давненько заметил за телегой не очень строгое следование расписанию: если запланировал пост на 10:00, то он опубликуется обычно в 10:02-10:05, и со временем проблема становилась заметнее: можно посмотреть по истории постов канала. Вполне очевидно, почему так происходит: алгоритм отложек не идеален и все больше людей пользуется фичей. “Вас тут много, а я одна!”. И лайфхак для решения проблемы очень простой — поставить в расписании 9:59 (по цене 9.99).

Он пригодится и в других контекстах. Ни для кого не секрет, что люди по умолчанию выбирают круглые даты и числа. И программисты — не исключение. Поэтому всякие работы по расписанию (например, очистка БД от мусора в ночное время) лучше ставить не тупо на полночь, а на на случайный час со случайными минутами — чтобы была меньше вероятность запуститься с чем-то одновременно. Конечно, в идеальном мире должен быть хороший планировщик, но кого мы обманываем с этими микросервисами?

Хороший доклад про то, что такое культура разработки, чем она полезна и с некоторыми идеями, как ее улучшить. Выгодно выделяется хоть какой-то конкретикой на фоне стандартного буллшита про повышение надоев и за все хорошее, который видел в большинстве статей на тему.

Из интересного:

• У компании есть (бывает) видение (куда идем), миссия (зачем) и культура: “что мы себе позволяем по пути”.
• Важный аспект культуры — управление ожиданиями.
• У культуры обычно есть авторы, которым это интересно и которые радеют за все это.
• Талмуд разводить не надо, но лучше зафиксировать основные ценности для упрощения принятия решений письменно.
• Есть ссылки на 4 готовых описаний культуры от разных компаний.

Как внедрять:

1. Написать документ;
2. Обсудить с инженерами, распространять через агентов влияния;
3. Поощрять за хорошее и карать за плохое;
4. Расставаться с несогласными (sic!);
5. Регулярно пересматривать, чтобы было не как у мартышек.

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

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

Вообще по ощущениям если много людей не укладывается в культуру, то лишний в ней — ты. И это ошибка найма :/

Интересная статья про оптимизации и про потенциальное развитие C++. Начинается с довольно меткого указания на отличия между программированием раньше и сейчас: раньше программы в основном покупались 1 раз и использовали ресурсы компьютера пользователя, поэтому важно было выпускать ПО без багов (потому что тяжело исправить) и с кучей фич (чтобы продать); сейчас же почти все крутится в облаке и компания платит за ресурсы (а новый релиз выпустить относительно просто). Соответственно, многие новые “убийцы” плюсов все еще пытаются решить старую проблему с безбажностью, вместо того, чтобы выжимать максимум производительности.

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

Рассматриваются три интересных подхода: SPIRAL (хитрые эвристики), Numba (более высокоуровневый подход), ForwardCom (простейший набор команд + радикальные идеи об общем низкоуровневном наборе команд для всех CPU).

“Как-нибудь” продукт и шелл-скрипт соберет. А вот если надо “чтобы само” да еще и быстро — то тут начинается веселье:

1. Надо скачать зависимости, разрешить конфликты (а это может быть большой граф), подключить их правильно (банально — фреймворк для тестов не должен протекать в продакшн-код) и т.п.
2. Сборка должна быть быстрой, поэтому не надо каждый раз все собирать с нуля, а по максимуму переиспользовать предыдущие результаты — это инкрементальная компиляция (возможно со всякой черной магией, чтобы понять, были ли изменения бинарно совместимыми или нет) и/или корректный вызов компилятора, который, знаете ли, тоже тот еще комбайн. Это не очень тривиальная задача. А еще нужен кэш сборки (возможно удаленный).
3. Как следствие, процесс сборки (а так же его части, та же компиляция) делится на мелкие кусочки (чем мельче куски, тем больше потенциально закэшируется), которые зависят друг от друга — получается граф выполнения задач. Причем там могут быть циклы (у какого-нибудь линковщика, например) — со всеми вытекающими приколами.
4. Чтобы было еще быстрее, можно же параллельно выполнять независимые задачи.
5. Кэшировать можно не только результаты сборки, но инструкции для нее. И тоже гранулярно.
6. На мелкие кусочки можно делить не только процесс сборки, но и сами исходники — зачем вам каждый раз перекомпилировать форк библиотеки со своим фиксом, когда можно его изолировать от остального кода?
7. Если вы разработчик библиотеки, то надо еще тестировать под миллион окружений, и не всем охота это делать в CI.
8. А еще код на качество стоило бы как-нибудь проверить, желательно сразу при сборке.
9. Если у вас завелся пользователь Windows, то уже просто shell-скрипт не напишешь, нужно что-то кроссплатформенное для всякой фигни типа копирования файлов или выполнения HTTP-запроса.
10. Получается, что теперь нужна еще возможно писать какую-то кастомную логику и/или давать возможность расширять функциональность плагинами.
11. Даже если стараться, то теперь у вас есть DSL, который с очень большой вероятностью Тьюринг-полный.
12. Так что желательно, чтобы это все нормально интегрировалось с IDE.
13. Все перечисленное выше еще должно быть плюс-минус воспроизводимым, чтобы везде был одинаковый результат.
14. И животноводство! Какой только фигни не хотят “чтобы заодно” делал сборщик.

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

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

Сабж. Регулярно обновляется. Можно еще поразиться количеству некриптографических хэшей в дикой природе.

Операционной системой в браузере с учетом существования WASM тяжело удивить — тысячи их! И Linux, и Windows, и FreeBSD, и Kolibri, и QNX… 1, 2, 3. А уж эмуляторов MS DOS, в которых можно еще и в старые игрушки поиграть (верните мне мне мой 1996-й) — вообще миллион.

Недавно еще наткнулся на ОС, которая написана специально под браузер. В том числе в ней обнаружился полнофункциональный клон MS Paint — вернул себе свой 2000-й :)

Неплохая статья про IPv6 и основные заблуждения о нем.