Все публикации подряд на Хабре [expanded by feedex.net]

А вы всегда пьёте коньяк на завтрак или только по выходным? Часть 2

sonyarybak — Tue, 11 Aug 2026 05:31:06 +0000

sonyarybak2 минуты назад

Простой

7 мин

Привет всем, я – Соня Рыбак, IT HRD. Продолжаю свою подборку крутых понятий и терминов, которые первый раз узнала работая в айти. Они полезны не только для работы, но и для жизни. Добавляйте в комменты свои. Ссылка на часть 1.

Эти термины я регулярно собираю в рубрике «Коньяк по утрам» в своём Telegram-канале HR for tech. Итак, погнали.

1. Ложная дихотомия

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

2. Hero culture

Корп среда, которая держится на подвигах отдельных ребят, готовых работать по 60 часов в неделю и спасать все в последний момент. Личное самопожертвование это круто.

Признаки такой культуры: регулярные авралы, незаменимость людей, отсутствие процессов. Вася все знает помнит придет починит, поощрение выгорания, смотрите Федя работает в отпуске или на больничном, молодец!

Лечится надежностью. Если для успеха нужен герой чаще это хреновые процессы. Netflix специально строил систему так, чтобы падение сервисов было рабочим сценарием, а не катастрофой.

3. Эффект Линди
Чем дольше живет технология, тем дольше она еще проживет. SQL существует почти 50 лет. С огромной вероятностью будет жить еще 50. Старые технологии часто безопаснее новых.

4. Преимущество второго игрока
Статистика шахмат говорит о преимуществе первого хода. Белые выигрывают чуть чаще, чем черные, 52-56 процентов.

Но в бизнесе не обязательно быть первым. Иногда выгоднее быть вторым. Google не был первой поисковой системой. Были AltaVista, Yahoo, Lycos. Но Google посмотрел на их ошибки и сделал лучше. То же с iPhone. Смартфоны уже были. Apple сделал первый нормальный.

Компания-гигант может позволить стартапу первым потестить новую нишу, если идея выстрелила, гигант заходит на рынок со своими ресурсами, фиксит недочеты пионера и захватывает долю рынка.

5. Эвристика доступности
Ментальная ловушка. Мы оцениваем вероятность события, насколько легко примеры этого события приходят в голову. Если можно быстро что-то вспомнить, мозг делает вывод: легко вспомнилось, значит, это правда.

Я дико боюсь летать на самолетах, больше чем ездить на машине. Репортажи об авиакатастрофах из сми пугают, они легко всплывают в памяти, страшно. Ошибочно кажется что это часто. Хотя по статистике это самый безопасный транспорт.

6. Bus factor
Проектная метрика. Сколько участников команды должны исчезнуть, грубо, попасть под автобус, чтобы проект остановился из-за нехватки знаний.

Bus factor = 1: критическая ситуация, проект зависит от одного эксперта. Его уход, болезнь, увольнение, отпуск, парализует проект. Чем выше число, тем лучше. Значит, что знания распределены между многими людьми, и уход одного человека не станет катастрофой.

7. Гемба (Gemba)
Термин из Toyota. Реальное место, где происходит работа и создается ценность. Руководители должны понимать ситуацию из первых рук, а не из отчетов.

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

8. It works on my machine
У меня на компьютере все работает. Мем в разработке, когда код успешно выполняется у программиста, но ломается в тестовой или в проде. Симптом плохой настройки процессов и разницы в окружениях.

9. Single source of truth
Один источник истины. Принцип организации данных, вся информация или вид данных хранится в одном месте. Не копировать данные в разные таблицы, а все системы обращаются к одному источнику.

Нет споров чья таблица правильнее, данные актуальны, быстрее принимаем решения. Git как единственное место актуального кода. Figma, когда изменение цвета кнопки в одном мастер-компоненте меняет его во всех макетах.

10. Петли положительной обратной связи

Процесс, в котором результат действия усиливает само это действие.

Банковская паника: люди боятся, что банк закроется → массово снимают деньги → у банка реально заканчиваются деньги → паника усиливается.

Социология: богатые богатеют, бедные беднеют. Успех дает доступ к ресурсам, которые позволяют достигать еще большего успеха.

11. Fake it til you make it

Веди себя так, будто уже можешь — пока реально не сможешь. В мягких навыках работает хорошо. Главное, не фейкать, например, в хирургии.

12. Вопрос важнее ответа

Метод Сократа: он не давал готовых ответов, а задавал вопросы и через них люди сами приходили к истине. Если задаешь плохой вопрос, получаешь быстрый, но бесполезный ответ.

‘Как нам увеличить выручку?’ Звучит умно, но ни к чему не ведет.
‘Где мы теряем деньги прямо сейчас?’ — уже действие.

13. Not invented here (NIH syndrome)

Культура, когда команда отвергает чужие идеи, продукты потому, что они созданы не ими. Мы сделаем лучше. Сделаем свой message broker, не будем брать Kafka. У нас свой путь, нам не нужны чужие фреймворки OKR.

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

14. Move fast, break things

Двигайся быстро, даже если по пути что-то сломаешь. Девиз раннего Facebook. Скорость важнее совершенства.

Ты выпускаешь сырой продукт, сразу получаешь обратную связь от реальных пользователей и исправляешь ошибки на ходу. Позже Цукерберг сменил лозунг на более зрелый: Move fast with stable infrastructure.

15. Shadow IT

Теневое IT, когда компания официально работает в Teams, но команда переписывается в Telegram, хранит файлы в личном Google Drive и ведет задачи в Notion без ведома IT депа.

Риски: утечка данных, проблемы с безопасностью, зоопарк из сервисов. Индикатор того, что сотрудникам неудобно работать с официальными инструментами.

16. Tribal knowledge (племенное знание)

Знания в голове у Валеры. Критически важная информация известна только определенным людям, нигде не зафиксирована. Валера ушел, все встало.

17. Bikeshedding

Закон Паркинсона о тривиальности. Тратим уйму времени на обсуждение фигни, вместо сложного и важного. Чем проще тема — тем больше людей в нее приходят → тем дольше спор.

На совещании по строительству атомной электростанции вопрос безопасности реактора обсуждают 5 минут. Зато 3 часа спорят, в какой цвет покрасить сарай для велосипедов (bike shed).

18. Луддиты

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

Сейчас это когда любую новую технологию встречают не давайте разберемся а в режиме ‘запретить, отключить, сжечь’.

AI, автоматизация, новые инструменты, плохо, раньше Excel был духовнее. И уберите это сатанинское колесо от моего отдела.

19. GSD

Get Shit Done. Стиль работы, где человек просто берет и делает.

Из стартапной среды, где ценят не управленческий туман, а людей, которые реально делают.

20. Pomodoro

Техника тайм-менеджмента, делишь задачу на короткие отрезки, 25 минут работаешь только над одной задачей, потом 5 минут отдыхаешь.

После 4 таких подходов делаешь длинный перерыв на 15–20 минут.

Придумал студент Франческо Чирилло. Он занимался с кухонным таймером в форме помидора, отсюда и название.

Не пытайтесь героически сесть и сделать все сразу, а спокойно делайте задачу короткими кусками. Без чатов, почты и душевных метаний.

21. Сбитый летчик

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

Часто используют, когда обсуждают бывших звезд рынка.

22. Окно Овертона

То, что вчера казалось немыслимым, со временем начинают спокойно обсуждать, потом принимать, а потом считать нормой.

Автор Джозеф Овертон, президент Центра Политики.

Отношение к однополым бракам в США, от табу к законному. Или сначала работа по вечерам это бардак, потом ты гибкий, потом синьерный, и вот ты отвечаешь в чатах в 22:43, как так и надо.

23. Реверс-инжиниринг

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

Смотришь на команду, которая нанимает крутых, и раскручиваешь назад. Как у них описаны роли, кто интервьюирует, как устроена оценка, где отсеивают.

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

24. Темные паттерны

Приемы в интерфейсах и процессах, которые подводят тебя к выгодному для компании, но не всегда честному выбору.

Легко подписаться и хрен как отписаться. Большая яркая кнопка ‘да’, а маленькая серая ‘нет, я хочу страдать дальше’.

25. Перекладывать JSON

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

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

26. Переставлять кровати в борделе

Крылатая фраза про эффективный менеджмент. Бесполезная имитация бурной деятельности (ИБД).

Когда меняют структуру, названия отделов, роли, но не трогают настоящую проблему.
Был отдел подбора, стал talent acquisition hub.
Были долгие согласования, остались долгие согласования.

Когда бордель перестает приносить прибыль, нужно менять персонал, а не переставлять кровати.

27. Если надо объяснять, то не надо объяснять

Хороший жизненный маркер свой-чужой..

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

Принцип общего контекста. Единый понятийный аппарат. Фразу часто приписывают поэтессе Зинаиде Гиппиус.

28. Культура без поиска виновных (Blameless culture)

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

Это не значит, что ответственности нет. Она есть. Просто фокус не на публичной порке, а на улучшении системы.

Если за ошибку сразу наказывают, люди быстро учатся не говорить правду. А без правды процессы не чинятся.

29. Закон Мерфи (Закон подлости)

Шуточный эмпирический принцип.

Если что-то может пойти не так, оно обязательно пойдет не так, причем в самый неподходящий момент. Если код может упасть во время демо — он упадет именно в этот момент. Бутерброд всегда падает маслом вниз.

30. Happy path

Основной успешный сценарий.

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

Кандидат получил письмо, перешел по ссылке, выбрал слот, пришел на интервью, интервьюер оставил фидбек, рекрутер сделал следующий шаг.

Happy path нужен, чтобы описать нормальное рабочее флоу.

31. Ад зависимостей (Dependency hell)

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

Или HR ждет финансы, финансы ждут юристов, юристы ждут руководителя, руководитель ждет СЕО, СЕО в самолете.

32. Кипятить океан

Пытаться собрать мнения всех миллиона пользователей перед запуском одной кнопки. Давайте опросим фокус-группу из 50 человек

33. Технооптимисты и технопессимисты

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

Соня Рыбак — HRD, пишу про найм, карьеру и продуктовый HR для инженерных команд. Мой телеграм-канал HR for tech: @rybaksofya.

Хабр Курсы для менеджеров

Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!

Мир, рассчитанный на рост, заканчивается

Alex-sulimov — Tue, 11 Aug 2026 05:30:06 +0000

Alex-sulimov3 минуты назад

Простой

6 мин

Мнение

Некоторые графики объясняют происходящее лучше, чем десяток книг с прогнозами. Вот, например.

Структура коэффициента демографической нагрузки. Европа, 1950–2023. Число иждивенцев на 100 человек в возрасте 15–64 лет, с разбивкой на молодых (0–14) и пожилых (65+). Источник - https://t.me/sterngang

Это структура демографической нагрузки в Европе с 1950 года. В 1950-м на сто человек трудоспособного возраста приходился 41 ребёнок и 12 пожилых. В 2023-м - 24 ребёнка и 31 пожилой. Сама нагрузка почти не сдвинулась: 53 иждивенца тогда, 55 сейчас. Перевернулась её структура.

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

Наша цивилизация расчитана под постоянный приток людей

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

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

А людей становится меньше.

При этом дело не в сокращении населения как таковом. Если людей стало на 10% меньше, а производительность выросла на 30%, общество спокойно может стать богаче. Критично другое - это соотношение поколений. Когда на место ста уходящих работников приходит не сто новых, а семьдесят, меняется сама механика экономики.

Человек становится дефицитом

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

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

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

Стареет не только производство, но и спрос

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

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

Капитал стареет вместе с людьми

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

Это объясняет часть межпоколенческого конфликта лучше, чем разговоры о «неправильной молодёжи». Если жильё относительно доходов заметно подорожало, отказ от ранней покупки квартиры не обязательно инфантильность, а иногда рациональная реакция на изменившиеся условия. То же и с карьерой: если люди дольше остаются профессионально активными, руководящие позиции освобождаются медленнее, и карьерная лестница превращается в карьерную очередь. Нежелание молодого специалиста десятилетиями ждать следующей ступени это возможно, не про «культуру поколения», а про то, что система стала двигаться медленнее.

Старение придёт и в политику

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

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

Самым ценным ресурсом становится продуктивная жизнь

Важно! Старение не равно упадку.

Ключевой вопрос это не сколько человеку лет, а сколько лет он остаётся здоровым, обучаемым и экономически активным. Здоровый семидесятилетний инженер и семидесятилетний человек, которому нужен постоянный уход - для экономики две разные ситуации. Поэтому здравоохранение неожиданно становится частью базовой инфраструктуры производительности, а не только статьёй социальных расходов.

То же и с образованием. Если профессиональная жизнь длится пятьдесят лет, то модель «получил профессию в двадцать и работаешь до пенсии» ломается. А заместить всех новым молодым поколением не выйдет: его просто недостаточно. Значит, переучивать людей в сорок, пятьдесят и шестьдесят перестаёт быть благим пожеланием и становится экономической необходимостью.

Бизнесу придётся сменить формулу роста

В XX веке рост бизнеса почти автоматически означал рост штата: больше клиентов значит больше операций, и значит больше сотрудников. При дорогом и дефицитном человеческом труде выигрывает другая модель - больше клиентов при почти неизменном числе людей. Поэтому ИИ, автоматизация, стандартизация процессов, ДМС и управление знаниями перестают быть просто способами приподнять маржу. Они становятся способом масштабироваться в принципе.

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

От роста людей — к росту производительности

Всё это не приговор: мир может, но не обязан стать беднее. Он переходит к другой модели.

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

В этой логике преимущество бизнеса это умение делать больше меньшим числом людей. Преимущество государства это дольше сохранять человека здоровым и продуктивным. Задача образования - переучивать человека многократно за жизнь. Роль технологий это экономить человеческий труд там, где людей физически не хватает. Под этим углом ИИ, роботизация, война за специалистов, миграция, рост расходов на медицину, пенсионные реформы и кризис доступности жилья перестают выглядеть независимыми сюжетами: все они разворачиваются на фоне одного медленного изменения.

Стоит уточнить, что именно дорожает.

Дефицитом становится не человек вообще, а определённая часть того, что он делает. Всё, что поддаётся регламенту и воспроизводится по запросу, машина рано или поздно подхватит и хорошо, что подхватит: рук на это всё равно не хватит.

Но есть работа другого рода - удерживать проект, которого ещё нет, годами; верить в свои решения; возвращаться и возрождать начатое, если ты видишь в этом потенциал. Нести смысл через время: репутацию, доверие, институцию - то, что не пишется по запросу, а вынашивается. И чем дефицитнее человеческое время, тем яснее, что беречь его стоит именно для этого.

Мы прекрасно умеем жить в мире, где каждое следующее поколение многочисленнее предыдущего. И почти не понимаем, как должны работать экономика, компании и государство, когда всё наоборот.

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

Поэтому главный вопрос ближайших десятилетий, возможно, звучит не «сколько людей останется на Земле». А так: как устроить мир, в котором человек становится дефицитом?

Хабр Курсы для менеджеров

Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!

BLIS: недостающую среднюю ступеньку построили тридцать лет назад

nonpareil_coder — Tue, 11 Aug 2026 04:36:55 +0000

nonpareil_coder56 минут назад

8 мин

Туториал

Часть 3 цикла о программировании Apple Scalable Matrix Extension (SME2). Часть 2 обнаружила, что у лестницы обучения SME отсутствует середина: руководство на один тайл внизу, нечитаемые промышленные ядра наверху — и ничего между ними, там, где строится настоящий GEMM. Эта часть — о фреймворке, который уже занимает эту ступеньку, и о том, почему перенос на новейший матричный движок оказался упражнением «заполните пропуски».

Оглавление-договор. В этой части мы начнём с тупика, в который приводит голый цикл FMOPA; затем покажем, какую часть GEMM BLIS уже построил за нас; после этого разберём пять циклов BLIS и место микроядра внутри них. Финал главы должен сделать дальнейший план конкретным: что именно нужно добавить для Apple SME, а что уже относится к готовой «мебели» фреймворка.

Расскажу о лучшем часе, потраченном на весь этот проект, — часе, который я провёл, не написав ни строчки кода.

У меня работал цикл с FMOPA — четырёхстрочное ядро из части 1, накапливающее внешние произведения в ZA. Оно перемножало две матрицы. В качестве BLAS оно было при этом совершенно бесполезно: ни альфы и беты, ни возможности прибавить результат к существующей матрице C, ни обработки транспонирования, один тип данных — и производительность, падавшая с обрыва, едва матрицы вырастали из кэша L1. Всё, чего, по словам части 2, не делает учебное руководство, моё ядро тоже не делало. Я стоял ровно там, где должна быть недостающая средняя ступенька, держа в руках атом — и никакой лестницы.

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

Этот фреймворк — BLIS. Прежде чем хвалить его вслух, покажу форму, из которой эта похвала следует: понимание его структуры — единственная причина, по которой остаток цикла короток. Стоит увидеть форму BLIS — и «перенести GEMM на SME» перестаёт быть проектом и становится анкетой для заполнения.

Озарение: одно ядро, а всё остальное — мебель

Вот наблюдение, на котором построен BLIS; оно принадлежит Кадзусигэ Гото и было формализовано Филдом Ван Зи и Робертом ван де Гейном из Техасского университета в Остине. Возьмите любую высокопроизводительную реализацию GEMM — для x86, для POWER, для ARM, для дюжины умерших архитектур — и прищурьтесь. Все они — одна и та же программа. Все упаковывают операнды в удобные для кэша панели; все разбивают три цикла по M, N и K на блоки так, чтобы нужные данные находились в нужном уровне кэша в нужное время; все опираются в основании на маленькое, вручную настроенное ядро, умножающее узкий срез A на узкий срез B. Блокирование одинаково. Упаковка одинакова. Порядок циклов одинаков. Единственное, чем великий GEMM для AVX-512 отличается от великого GEMM для NEON, — крохотное ядро в самом основании и горстка чисел, описывающих размеры кэшей. Одинаковость — это всеобщее; архитектуры — его особенные обличья; крохотное ядро в основании — единичное, в котором всё различие и умещается.

И BLIS делает очевидную — задним числом — вещь: записывает всю эту одинаковость один раз, на переносимом C, а различия выставляет в виде небольшого набора точек подключения. Переносимая часть — которую статьи о BLIS называют «макроядром», вместе с окружающими его циклами, — огромна, тонка, и трогать её никогда не приходится. Она ведает объектным API, интерфейсами CBLAS и Fortran, транспонированием, нормализацией порядка хранения, блокированием под кэш на трёх уровнях, расписанием упаковки, многопоточностью и граничными случаями, когда размеры матрицы не кратны ничему удобному. Это тысячи строк самого выстраданного знания в вычислительной математике, и перенос на новую архитектуру переиспользует его целиком.

Вы поставляете мебель, которая встаёт в гнёзда:

Микроядро: умножить одну упакованную микропанель A на одну упакованную микропанель B, накопить результат в крохотном тайле C размером MR×NR, применить альфу и бету. Вот сюда идёт ваш цикл с FMOPA.
Ядро упаковки (необязательно — есть эталонное): переставить блок A или B в непрерывную, дополненную нулями раскладку, которую микроядро хочет потреблять потоком.
Таблицу чисел: размеры регистрового тайла MR и NR и размеры кэш-блоков MC, KC, NC.

Это и есть весь перенос. Микроядро — несколько сотен строк, размеры блоков — пять целых чисел, а всё остальное делает BLIS. Когда я говорю, что остаток цикла — «заполнение пропусков», это те самые пропуски. Они по-прежнему интересны — матричный движок достаточно необычен, чтобы заполнить их хорошо стоило настоящего труда, о чём и рассказывают части с 4 по 7, — но объём работы ограничен так, как реализация GEMM с нуля не бывает ограничена никогда.

Пять циклов, снаружи внутрь

Чтобы разместить пропуски, нужна картина гнезда циклов BLIS. GEMM в BLIS — это пять вложенных циклов, обёрнутых вокруг одного микроядра, и каждый цикл существует, чтобы угодить своему уровню иерархии памяти. От внешнего к внутреннему:

Цикл 5 (NC), по N. Нарезать задачу на столбцовые панели B шириной NC. Каждая панель — то, что потребит один проход через остальную машину.
Цикл 4 (KC), по K. Нарезать размерность K на отрезки длиной KC. Столбцовая панель B высотой KC (размером NC×KC) теперь упаковывается в непрерывный, размещённый в кэше буфер: этот блок будет переиспользоваться снова и снова, поэтому его стоит реорганизовать. Упакованная панель B живёт в диапазоне кэшей L3/L2.
Цикл 3 (MC), по M. Нарезать A на строковые панели высотой MC. Блок A размером MC×KC упаковывается в собственный непрерывный буфер, рассчитанный на L2/L1. Этот упакованный блок A будет многократно проходить сквозь упакованный блок B.
Цикл 2 (NR), по упакованной панели B. Обходить упакованный блок B полосами шириной NR — по одной микропанели B.
Цикл 1 (MR), по упакованной панели A. Обходить упакованный блок A полосами высотой MR — по одной микропанели A. Пара (MR, NR) выбирает один регистровый тайл C, и мы вызываем микроядро: пропустить панель A размером MR×KC через панель B размером KC×NR, накопив KC внешних произведений в регистрах, а затем обновить C.

Прочтите это изнутри наружу — и получится рассказ о переиспользовании данных. Микроядро удерживает тайл C в регистрах (в нашем случае — в ZA) на протяжении всей редукции по KC, так что C записывается в память один раз, а не KC раз. Упакованный блок A подобран так, чтобы оставаться в L2 и переиспользоваться на каждой NR-полосе B. Упакованный блок B подобран так, чтобы оставаться в L3 и переиспользоваться на каждой MC-панели A. Каждый байт упаковывается потому, что его предстоит прочитать много раз; каждая граница цикла — уровень кэша. Здесь нет ничего специфичного для x86, ARM или SME. Это специфично для устройства памяти, а оно у всех общее.

И выигрыш для наших целей: две вещи, делающие эту схему быстрой на конкретной машине, — ровно те две вещи, которые BLIS предлагает вам подключить. Регистровый тайл (MR, NR) и микроядро определяют, как вы используете вычислительный блок; кэш-блоки (MC, KC, NC) — как вы его кормите. SME меняет то, чем регистровый тайл является — это массив ZA, а не набор векторных регистров, — но не меняет того, что регистровый тайл есть то, во что сводит результат самый внутренний цикл. Гнездо подходит.

Почему это правильный фреймворк именно для матричного движка

Есть и более глубокая причина, по которой BLIS подходит SME, помимо «это хороший фреймворк для GEMM». Центральная абстракция BLIS: микроядро накапливает обновление ранга 1 на каждом шаге по K в размещённый в регистрах тайл C. Оглянитесь на часть 1: FMOPA и есть обновление ранга 1 — внешнее произведение, — накапливаемое в размещённый в регистрах тайл по имени ZA. Контракт микроядра BLIS и инструкция SME, никогда не встречавшись, описывали одну и ту же операцию.

На SIMD-машине микроядру BLIS приходится имитировать внешнее произведение: транслировать один элемент A на весь вектор, умножать на вектор B и повторять это MR раз, синтезируя обновление ранга 1 из операций FMA ранга 0. Этот синтез — неказистое, вечно стеснённое нехваткой регистров сердце каждого SIMD-ядра GEMM. На SME синтез исчезает: оборудование выполняет обновление ранга 1 само, одной инструкцией, в регистровый файл, созданный служить тайлом C. BLIS тридцать лет притворялся, что векторные регистры — это матричный аккумулятор. SME просто делает это правдой. Тридцать лет она была правдой лишь в возможности — записанной в контракте; кремний сделал её действительной. Вставить микроядро SME в гнездо BLIS — не согласование несовместимого; это абстракция, наконец получившая оборудование, которое она всё это время описывала.

По той же причине таблица размеров блоков — то место, где живёт интересная настройка. Поскольку ZA огромен — регистровый тайл 32×32 одинарной точности против тайлов порядка 8×8, которыми располагает ядро на NEON, — числа MC/KC/NC, приводящие его в равновесие, не похожи ни на что в стандартных конфигурациях ARM. В части 4 мы увидим, что KC стремится быть огромным (2048): весь смысл гигантского аккумулятора ZA в том, что он никогда не выгружается в память, поэтому редукция по K ограничена лишь тем, сколько упакованных данных A и B удаётся удержать в кэше. Фреймворк тот же; числа, заставляющие его петь, — новые.

Что BLIS даёт вам, конкретно, для переноса на Apple SME

Сделаем утверждение «заполните пропуски» конкретным, потому что это сквозная нить всего дальнейшего. Вот полный список того, что работа над Apple SME добавляет в BLIS, — а всё, чего нет в этом списке, BLIS уже сделал:

Субконфигурация (applesme), которая регистрирует ядра и, что принципиально, распознаёт оборудование во время выполнения — SME2 для ядер одинарной точности, дополнительный признак FEAT_SME_F64F64 для ядер двойной точности — и молча оставляет эталонные ядра BLIS, если нужного кремния нет. (Сага о флагах компилятора из части 1 тоже живёт здесь.)
Четыре микроядра GEMM, по одному на тип данных: sgemm (часть 4), dgemm (часть 5) и два комплексных ядра (часть 6).
Ядро упаковки, использующее сам ZA как машину транспонирования (часть 7).
Таблица размеров блоков, в которой MR и NR выводятся во время выполнения из потоковой длины вектора, так что один и тот же двоичный файл адаптируется к любому будущему SVL.

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

Регистрируя ядро, вы также сообщаете BLIS один бит предпочтения: хочет ли это ядро видеть матрицу C в памяти по строкам или по столбцам? Наши ядра SME вычитывают результат из ZA столбец за столбцом, поэтому объявляют предпочтение столбцового порядка, и BLIS подстраивает C под него. Один логический признак — и фреймворк корректно выбирает порядок хранения для любого вызывающего кода. Такова фактура всего переноса: небольшие, локальные декларации того, чего хочет оборудование, — и фреймворк, который уже продумал последствия.

Вывод. Среднюю ступеньку лестницы SME — упаковку, блокирование под кэш, полный контракт BLAS, многопоточность, обработку краёв — не нужно изобретать: BLIS и есть эта ступенька, причём с тех времён, когда самого оборудования ещё не существовало. Его основополагающее наблюдение: каждый GEMM — одна и та же программа, за вычетом одного маленького ядра и пяти чисел размеров блоков; а контракт его микроядра (накапливать обновления ранга 1 в размещённый в регистрах тайл C) — в точности то, что делает внешнее произведение SME. Перенос сводится к трём действиям: напишите ядро, заполните таблицу, объявите, чего хочет оборудование. Следующие четыре части — эти пропуски, заполненные; и именно в том, чтобы заполнить их хорошо, скрывалось всё удовольствие.

Далее: микроядро sgemm, целиком. В части 4 мы разбираем ядро одинарной точности 2VL×2VL по винтикам: как аккумулятор 32×32 отображается на четыре тайла ZA, почему цикл по K расшит по два, и загружает данные мультивекторными инструкциями SME2, как альфа и бета применяются при чтении ZA столбец за столбцом — и один флаг (beta == 0), с которым нужно обращаться осторожно, иначе значения NaN просочатся в свежую матрицу.

Хабр Курсы для бэкендеров

Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!

Удивительный ответ 403 при доступе через некоторых провайдеров

diakin — Tue, 11 Aug 2026 04:27:11 +0000

diakin1 час назад

Простой

1 мин

Кейс

Recovery Mode

На днях внезапно обнаружил, что с домашнего компа мой сайт https://wenda.rip стал выдавать ответ 403.

Помыкавшись и не добившись результата с .htaccess, написал в поддержку reg.ru, но там сейчас завал (на Хабре писали что у всех по какой-то причине, но я забыл). Проверил доступ на работе - все нормально. Подумал, что наверное где-то закешировалось. Почистил кэш, все равно норм.
Зашел дома с телефончика через WiFi - ответ 403. Отключил WiFi, зашел через Мегафон - страница открылась! Что за на ???
Полез проверять через сервисы, например https://dostupno.net

Source Response Time HTTP Code Status
mobileMoscow Megafon 1 0.85 sec 200 OK
mobileMoscow Megafon 2 0.66 sec 403 OK
mobileMoscow Megafon 3 0.85 sec 200 OK
Moscow Kornet  0.65 sec 200 OK
Moscow Link  0.64 sec 403 OK
Moscow Rostelecom 1 0.59 sec 200 OK
St. Petersburg, Point 1 0.64 sec 200 OK
St. Petersburg, Point 3 1.34 sec 200 OK
St. Petersburg, Point 4 1.31 sec 200 OK
St. Petersburg, Point 5 0.87 sec 403 OK

Ах, удивительное дело!
Причем другой сайт, на том же хостинге, например ... ну неважно.. открывается нормально.
Что бы это могло быть?

Хабр Курсы для всех

Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!

Три месяца спустя: стемы, которые убивали вкладку, и синхрон, который меня чуть не доконал

MrPikasso — Tue, 11 Aug 2026 04:08:22 +0000

MrPikasso1 час назад

Простой

8 мин

Кейс

Год назад я рассказал, как из боли «песни разбросаны по чатам» вырос сервис для команд прославления: PHP на дешёвом хостинге, React, деплой по FTP руками. В конце той статьи было три обещания одним абзацем — сделаю стемы, синхронизирую сцену, перееду с shared-хостинга. Все три оказались на порядок сложнее, чем звучали.

Эта статья — про то, что было дальше. Честно, с провалами. Про то, где я бился неделями, где всё падало и где приходилось заходить по пять-семь раз, прежде чем получилось.

Сразу оговорюсь: сами нейросети для разделения на дорожки и распознавания аккордов — не мои. Я использую API Moises. Всё остальное — доставка, движок, синхрон, продукт — моё, и об этом ниже.

Стемы: семь заходов, шесть провалов

В первой статье это была одна строка: «сделаю через Replicate». На деле я перебрал семь провайдеров разделения аудио, и шесть из них отвалились — каждый по-своему.

Локальный Demucs. Красиво в теории, невозможно на практике: на дешёвом хостинге нет GPU и лимит 120 секунд на запрос, а Demucs на CPU думает минутами. Не вписался ни разу.
Replicate. Работает, но платно за секунду GPU — и отдаёт только дорожки. Ни аккордов, ни битов. А музыканту нужен разбор песни, а не папка с WAV.
fal.ai. Первый, кто реально доехал до прода. Те же минусы: только разделение, платно, максимум 6 дорожек. Зато именно на нём я впервые уронил весь сервер (об этом ниже).
LALAL.AI. Один проход — два трека. Чтобы получить 8 дорожек, надо гонять файл по кругу и платить за каждый круг. Для бесплатного продукта экономика не сходится вообще.
Свой GPU-сервис. Топовое качество, десятки моделей — и отдельная инфраструктура с видеокартой, очередями и счётом за простой. Для одного разработчика — рано.
Music.ai. Вот где было по-настоящему обидно. Официальный платный API, который умеет всё сразу — и стемы, и аккорды, и секции. То, что нужно. Но задачи воспроизводимо падали с INTERNAL_ERROR через 65–120 минут ожидания. Полтора часа — ради ошибки. Поддержка молчала. И да, за эти попытки я платил своими деньгами. Ключ от него теперь закомментирован на всех серверах, и в правилах проекта отдельной строкой висит «перед деплоем проверь, что он закомментирован» — чтобы случайная конфигурация не увела трафик обратно на этот дорогой и нестабильный путь.

Победил седьмой — API Moises. Он за 3–8 минут отдаёт сразу весь пакет: 7–8 дорожек, аккорды с таймингом, биты, темп, тональность и секции (куплет/припев/бридж).

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

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

Как я уронил весь сервер шестью дорожками

Первая схема доставки казалась разумной: пусть PHP сам качает дорожки из хранилища и отдаёт их браузеру. Единая точка, никаких чужих доменов.

Это была катастрофа.

PHP-воркер занят всё время, пока играет дорожка — пять-семь минут. Шесть дорожек — шесть занятых воркеров. А пул воркеров на дешёвом хостинге — две-три штуки. Итог: 503 на весь сервис — чат, расписание, песни. Аудио убивало вообще всё.

Ту неделю я до сих пор помню. Сначала все шесть дорожек падали мгновенной ошибкой — оказалось, кэш пытался скачать 50 МБ в темп до первого отданного байта, и nginx рвал соединение. Потом 503 на всё. Потом Chrome начал блокировать часть дорожек, потому что я создавал шесть <audio> разом. Каждый вечер — новый корень.

Вывод, который я записал заглавными буквами: PHP отдаёт JSON со ссылками один раз, дальше браузер общается с хранилищем сам. Ни один воркер не участвует в передаче аудио.

А дальше — контринтуитивная деталь, из-за которой я сделал, замерил и откатил. Логика говорит: убери посредника, будет быстрее. Я убрал прокси — телефон стал качать напрямую из хранилища. Стало в разы медленнее: ~98 секунд против ~10–15 через мой сервер. Оказалось, мой VPS и хранилище — в одной сети провайдера, и он работает не лишним хопом, а ускорителем. Коммит отката так и назвал: «прокси быстрее, чем напрямую».

И вишенка: уже потом я на проде написал в конфиге nginx один адрес литералом вместо переменной. nginx резолвит такие адреса при старте, резолв ушёл не туда — и не поднялся весь сайт, а не «раздел со стемами». Час паники. Мораль: конфиг сервера — тоже код, и ломается так же тихо.

Движок: три поколения и один упрямый iPhone

Задача звучит просто: восемь дорожек, играть синхронно, с mute/solo/громкостью на каждую, с перемоткой и сдвигом тональности. В Safari на iPhone. Она оказалась самой долгой историей проекта.

V1 — в лоб. Скачал, декодировал, играю. Работает — на трёх дорожках. Дальше арифметика убивает: несжатый звук — это ~10 МБ на минуту на дорожку. Пятиминутная песня × 8 дорожек ≈ 400 МБ в памяти. iOS убивает вкладку.

V2 — умнее. Декод в фоновом потоке, звук «перемещается» (не копируется) в аудио-поток, память живёт там. 8 дорожек заиграли на iPhone. Я выдохнул. Зря.

Через неделю пришла та самая песня — медли на 704 секунды. Play → вкладка умирает. V2 всё ещё декодировал каждую дорожку целиком, а на 12 минутах это снова ~2 ГБ. Я честно исключал по одному: код тот же? — да, контрольные суммы совпадают. Доставка виновата? — перенёс файлы, краш не изменился. Прод виноват? — склонировал на тест, тоже краш. Значит — сама песня. Длина упиралась в память.

Прежде чем изобретать, я час просидел над минифицированным бандлом чужого зрелого плеера (6.4 МБ) — просто чтобы понять, как они держат длинные треки. Ответ был в одной функции: плеер не хранит песню целиком. Буфер стартует с пяти секунд, растёт по требованию, старое выселяется. В памяти — только окно вокруг того места, что играет сейчас.

V3 — окно. Я взял принцип, а реализацию сделал свою, на нативном WebCodecs: декодирую только кусок вокруг текущей позиции, старое выбрасываю. Память — ~100 МБ вместо двух гигабайт, и не зависит от длины песни.

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

Итог на телефоне: 12-минутный медли, 8 дорожек — играет без краша, старт ~4 секунды вместо двух минут. На это ушли недели.

Перемотка добила отдельно: жмёшь — и дорожки гаснут одна за другой до полной тишины. Три независимых бага в одной кнопке, три вечера. А самая обидная история — сдвиг тональности, который тихо исчез. Настоящий сдвиг высоты звука был написан только в V1. В V2 и V3 метод остался — но пустой, ничего не делал. А подпись аккордов менялась всегда (это другой модуль). Снаружи выглядело идеально: тональность на экране едет, звук — нет. И никто не замечал, потому что глазами всё работало. Урок дорогого стоит: когда новая реализация вытесняет старую, сверять надо не то, что методы на месте, а то, что они реально делают.

Почему пришлось уехать с дешёвого хостинга

Дешёвый хостинг был идеален для медиатеки: пришёл короткий запрос — ушёл короткий ответ. Обе новые фичи сломали ровно эту модель, потому что обеим нужно держать соединение открытым.

Убийца — синхронизация Live Pro. Телефон музыканта висит на соединении с сервером до 8 секунд, ожидая, куда двинулся лидер. Команда из шести человек — шесть таких соединений по кругу. На пуле в две-три воркера этого хватает, чтобы сайт целиком отдавал 503 — ни чат, ни расписание. Долгое соединение на shared-хостинге не «медленное», оно несовместимо по построению.

Так я переехал на свой VPS. Он тут же принёс собственные проблемы — хостер режет исходящую почту (пришлось слать через HTTP API), тот самый nginx-литерал, грабли деплоя. Но это проблемы, которые можно починить, потому что сервер твой. На дешёвом хостинге стена была «нельзя», а не «сложно».

Live Pro: три дня, за которые я почти всё возненавидел

Вот главная битва. Лидер играет разбор песни с телефона в общий звук; у каждого музыканта свой телефон, и на нём должно быть то же самое в то же время — тот же аккорд, та же доля, та же секция.

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

Дальше — три дня охоты, двенадцать багов, и почти каждый со своим ложным объяснением. Расскажу те, где было по-настоящему больно.

Часы, которые врали на 25 секунд. Телефоны не знают точного времени относительно сервера — у одного из тестовых iPhone расхождение было −25 секунд. Пришлось мерить это расхождение отдельно, как маленький NTP.

«Клиент разъезжается» — а виноват был сервер. Стартуем вместе, через минуту фолловер откатывается назад, разрыв растёт: 21 секунда, 50 секунд. Я неделю искал баг у клиента. Оказалось — защита на сервере: он не принимал «момент» старше 60 секунд и тихо переписывал его на «сейчас», ломая мою пару чисел. Симптом кричал «клиент», виноват был сервер.

Я чинил не тот звук. Пользователь пишет: «аккорды спешат на полторы-две секунды». Я меряю экраны — совпадают до 25 мс. Меряю ещё раз — совпадают. Разгадка пришла с вопросом «а куда выведен звук?»: оба телефона играли в свои динамики, и человек стоял у того, чей звук отставал by design. Формально всё работало как задумано — а пользователю было плохо. С тех пор у фолловера звук принудительно на паузе.

LTE травит часы. На видео с двух телефонов было видно: к концу песни один убежал на 4 секунды. Телеметрия показала, что расхождение часов прыгало +0.8 → +3.7 секунды. На LTE отправка встаёт в очередь на секунды, все замеры приходят кривыми — и я их безоговорочно применял. Пришлось добавить фильтр: замер, пришедший по плохой сети, выбрасываем целиком и держим старый — устаревший в сотни раз точнее отравленного.

Итог, которым горжусь: экраны лидера и музыкантов совпадают в пределах ±15 мс — заметно меньше, чем разброс между живыми людьми, играющими вместе.

Но главный вывод не про числа. Половину этих багов я сначала объяснил неправильно — и каждое неправильное объяснение стоило бы дня работы не туда. Runaway списал на один параметр — оказалось, другое. «Спешат аккорды» списал на данные — замер показал, что данные ровные, а слушали старую версию. Поэтому я перестал верить ушам и глазам на репетиции и построил себе приборы: стенд, который прогоняет весь алгоритм без телефонов; тесты против живого сервера; телеметрию, которая пишет, какая версия кода реально исполняется. Скучно было писать — окупилось на второй же жалобе.

Отдельная боль: тесты, которые врали, и код, который возвращался

Четыре раза подряд я деплоил фикс, просил проверить — и получал «не работает». Каждый раз это было правдой ровно наполовину: открытая вкладка на сцене не подхватывает деплой. Музыкант не перезагружает страницу, браузер исполняет старый код сколько угодно долго, а я делаю ложные выводы и «чиню» уже починенное. Апофеоз — когда арифметика симптома идеально совпала со старым багом, а телеметрия потом показала: лидер просто крутил сборку без фикса. Пришлось научить вкладку саму замечать, что вышло обновление, и сверять версию перед каждым тестом синхрона.

И совсем показательная история — аккорды, которые «улетают». Песни хранятся как две строки: аккорды над словами, выровненные пробелами. При смене тональности аккорд меняет длину (C → A#), и если сохранять число пробелов, а не позицию, — каждый следующий аккорд уезжает вправо, и вся строка расползается. Я это починил. А потом оно вернулось — рефакторинг тихо вернул старую логику, потому что фикс нечем было сторожить. Полетели те же жалобы от всех команд разом: «опять слетело», «все устали». Чинил второй раз — уже с тестом, который падает, если кто-нибудь снова так сделает. Фикс без теста — это временный фикс. Разница между «починил» и «починил, чтобы осталось» — ровно один тест.

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

Хабр Курсы для бэкендеров

Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!