Про зарплатные вилки

Очень тяжёлая штука, указывать зарплатную вилку. Если, конечно, бюджетом управляешь ты, а не кто-то тебе сверху спустил стандарты. С одной стороны есть вот эта тема с утечкой информации, якобы компания больше знает об уровне зарплат (смотрит много кандидатов), а соискатель якобы не знает. И получается, что ассиметрия информации, надо выбивать вилку и вот это всё. Надо. Несомненно надо.
С другой стороны, когда указываешь вилку типа 250-400к в месяц, то любой, вообще каждый кандидат будет просить 400к. И будет уверен, что он достоин, как минимум, не меньше.
На выходе иногда получается, что компания либо просто отказывает кандидату, потому что могла бы предложить 300, а он просит 400 — больше разница. Либо предлагает кандидату 300, и тот в некоторых случаях принимает, а в некоторых уже всё, раз в вилке прочитал 400, будет искать эту зарплату на рынке, пока не переберёт все компании мира.
Такова человеческая натура, я тоже всегда только на верхнюю границу смотрю.

Вопрос праздный, у меня этой проблемы нет (пока?). Но как вы думаете, нужно выбирать вилку для указания в вакансии?

Про лоу перформеров

У нас на работе несколько месяцев как появились разные мероприятия для руководителей, где можно обсудить острые темы и обменяться опытом. В том числе анонимно. Насколько раз за последнее время всплывала тема "плохо работает, обратная связь не помогает, мотивация не помогает; ну или альтернативно: помогает волнами". Это ситуация, которая была у меня, к сожалению, уже несколько раз.
Давайте я обозначу здесь сразу какие-то очевидные вещи.
- Самая важная очевидная вещь. Нужно говорить с людьми. Если им не сказать, что они делают что-то плохо/медленно/не то, то они об этом не узнают.
- Вторая важная очевидная вещь. Разговаривать нужно конкретно по поступкам. Не "ты чет плохо работаешь", а "ты делаешь задачу Х уже на неделю дольше и всё ещё не готово". Не по персоналии.
- Третья очень важная очевидная вещь, которую часто забывают. Сначала узнать у сотрудника, как он видит ситуацию. Только потом рассказать, как видишь ты и _предложить_ помощь_.
- Четвёртая очевидная важная вещь, которую тоже забывают. После того, как обсудили план, че делать дальше, _убедиться_, что вы поняли друг друга одинаково. Проще всего попросить объяснить своими словами, что человек понял и что собирается делать.
- Пятая, не столь очевидная вещь. Нужно знать, что мотивирует конкретного сотрудника и пытаться это ему дать.

Все эти очевидные вещи в нормальном формате можно узнать в практикуме.

Теперь предположим, что вы всё делали, как написано в учебнике. Несколько раз. Но ТРЕНЕР, БЛОКИ НЕ РАБОТАЮТ. Тогда надо перестать жевать сопли и говорить с сотрудником о расставании. Все попытки дать ещё и ещё и ещё один шанс, какие-то там пряники и кнуты, возможно, будут помогать на _очень_ короткие промежутки времени. Но, во-первых, это издевательство над психикой сотрудника, постоянный стресс, отсутствие уверенности в завтрашнем дне. Во-вторых, это ужасающая куча геморроя, на который времени тратить придётся много, а эффекта будет мало.

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

Дочитал диалог "Протагор"

И преисполнился. Во-первых, это очень понятный диалог. Во-вторых, сложно не согласиться с его выводами. Почувствовал себя намного мудрее теперь.

Интересные наблюдения:
- если "апология Сократа" дала понимание, почему греческие философы зачастую прибегали к аскезе вообще; то "Протагор" подтверждает, что аскеза — это общепринятое в греческом обществе благо. Это сразу расширяет границы понимания университетского курса философии (не аспирантского, конечно), где куча аскетов, потому аскеза это круто 🤡
- греки практиковали голодание, как оздоровительную процедуру 🤔
- теперь полностью ясна концепция, что всё зло от незнания; что человек по природе своей не может осознанно деять зло. Я, кстати, с этим полностью согласен, от этой основы строится моя картина мира. Но из-за этого со мной редко кто согласен в дискуссиях на общественно-политические темы.
Именно из-за этого представления Платон потом говорит, что идеальные правители — это философы, т.е. люди, посвящяющие жизнь приобретению знаний.
- САМОЕ ГЛАВНОЕ ДЛЯ МЕНЯ. Даже мудрейший Протагор нем умеет читать, чито написано! Я очень сильно бешусь, когда люди читают не то, что написано, а то, что они хотят прочитать. Додумывают в контексте собственных мыслей, знаний и представлений, не задумываясь о таковых автора.
Это, кстати, проблема именно письменной речи, почему-то. Надо бы обдумать, почему так.
Справедливости ради, Протагор не смог прочитать довольно сложный кейс (в отличие от большинства людей в интернете), но сути дела это не меняет — читать, что написано, не умеет почти никто (я тоже), но у всех неумение на разных уровнях.

Суть ошибки Протагора следующая. Он рассматривает стих Симонида.

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

Там же, ниже по тексту, Симонид критикует Питтака:

Вовсе не ладным сдаётся мне слово Питтака,
Хоть его рёк и мудрец: добрым быть нелегко.

Простите, но думаю, что многие, как и Протагор, увидят здесь противоречие. Сам Симонид сначала говорит, что сложно стать хорошим, а потом критикует Питтака за слова, что трудно брать хорошим. Но противоречия здесь нет. TL;DR Симонид утверждает, что даже стать хорошим (будучи плохим) сложно, а уж быть хорошим (всё время) вообще невозможно. И Симонид считает, что не стоит осуждать неидеальных людей, потому что иначе придётся осуждать всех.

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

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

Про memory barriers

Опять не про психологию, а эти мои любимые компьютеры. Контент в кои-то веки c++ tolerant!

Сегодня снова про разницу между sequential consistency и release/acquire. Если забыли, в чем там прикол, то перечитайте презентацию с гитхаба Саши или статью Дага Ли. Многие продвинутые джависты, я уверен, читали jsr 133 cookbook. Там написано, как _можно_было_бы_ реализовать volatile записи и чтения (это sequential consistency) на разных архитектурах процессоров.

В этой статье есть несколько интересных моментов. Давайте их посмотрим поближе.
Первое. Рассматриваются барьеры между парами операций чтения и записи (load/load — между двумя чтениями, store/load — между чтением и записью, load/store и store/store). Это представление достаточно удобно для рассуждений (reasoning), но является абстракцией.
Второе. У x86 есть только одна инструкция-барьер — mfence, у power pc две: [lw]sync и hwsync; и вообще больше двух инструкций ни у кого нет. А абстрактных барьера — четыре. Наплодили тут!
Третье. Для x86 вообще почти все барьеры — noop. И только store/load требует барьера. Но! Мы видели у Саши Ланцова на графиках, что release/acquire быстрее sequentially consistent исполнения на x86. Как так? Всё просто: абстрактная модель с четырьмя такими барьерами не позволяет описать release/acquire! (Можете даже в исходники jdk заглянуть, они там отдельные)

В своё время (очень очень много лет назад) я увидел iriw и никак не мог понять, как с помощью этих барьеров его описать. Это меня очень мучало, я во сне даже это видел. Пришёл на JPoint. Пытался спросить г-на Шипилёва, но его всё время перехватывали, поэтому он меня отфутболил к г-ну Елизарову, который просто цензурно, но грубо послал меня на хер, с посылом, что дебилам это не нужно, отвали и забей, мальчик. ¯\_(ツ)_/¯
Но мальчики не сдаются. Я поймал г-на Шипилёва где-то во время какого-то доклада и он показал мне это. И это офигенно, почитайте на досуге.

Теперь давайте посмотрим, как устроены внутри setRelease и getAcquire, да и в целом все инструкции с барьерами внутри. Важный для понимания факт: при записи барьер выставляется ПЕРЕД самой записью, а при чтении — ПОСЛЕ самого чтения. Это может быть контринтуитивно. Но если подумать от гарантиях, то всё встанет на свои места. Смысл примерно такой:

Если мы увидели конкретную запись, то увидим и все предыдущие
Если мы прочитали какое-то значение, то его же должны видеть все последующие

Это неаккуратно, но передаёт мой посыл — куда думать.

Ну так вот. Для release/acquire на ppc нужны lwsync и до записи и после чтения. Для sequentially consistent нужна более тяжёлая артиллерия: [hw]sync на чтении. Для x86, как мы видели в cookbook'е, для sc нужен только mfence после чтения. А вот для release/acquire вообще ничего не нужно ни на чтении, ни на записи! Мы специально проверили, что opaque на x86 дает ту же корректность и ту же производительность, что и release/acquire. Напомню, что opaque ставит только компиляторные барьеры (не дает оптимизировать через компиляторный барьер). А всё благодаря TSO (total store order).
Интересный факт: явная инстркция барьера на x86 работает (работала?) медленнее, чем дающая те же гарантии атомарная инструкция lock addl, поэтому в jdk используется (использовалась?) именно последняя.

Я уже не знаю, зачем существует этот пост, но не могу остановиться.
КОРОЧЕ. В С/С++11 есть еще семантика release/consume... Она еще чуть слабее release/acquire и нужна вот зачем. Вы можете прочитать с consume записанную с release переменную-указатель и вам гарантируется, что по этому указателю вы увидите данные записанные до release записи. Т.е. зависимость по данным порождает видимость. НО! Эта штука была нужна, на сколько я знаю, только на альфах, которые канули в лету. Так что забейте.

Have a nice day, как говорится.

И, пожалуйста, не пишите на основе этой статьи компиляторы! Я не выверял формулировки, мог быть не точен, а мог и вовсе ошибиться.

Ну чёт даже не знаю

Как я "золото" нашёл

Одним летом, когда мне было лет 12 - 14, я приехал на дачу к бабушке. Свободного времени было выше крыши, поэтому бо́льшую его часть я разъезжал по деревне на велосипеде. Сначала объездил все асфальтированные дороги, потом всё побережье реки, потом грунтовки и тропинки. В конце концов я начал ездить просто по лугу, на котором иногда паслись козы и бараны, но по большей части на нём не происходило ничего.

Еду я по этому лугу, смотрю: что-то золотом блестит в траве. Остановился. Самородок! Довольно большой камень, то ли серый, то ли чёрный — уже не помню — а местами поверхность блестит желтизной.
У меня аж дух захватило! Осмотрелся по сторонам: откуда бы он мог взяться? Может, кто потерял? Метров на триста вокруг даже трава не примята. Взял я этот камень и покатил скорее домой.

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

Только пару месяцев томительного ожидания спустя мне удалось узнать у отчима, что же там с этим самородком. Это была медь. Разочарование.

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

А самородок тот я так больше никогда и не увидел.

Мысли в слух

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

Попробовал тут этот ваш ChatGPT для работы. Что ж, очень неплохо пишет sql запросы, помогает в пятницу вечером провалидировать рефакторинг, если вы вдруг почему-то не написали тесты, которых по какой-то неведомой причине не было и до вашего вмешательства.
Но чтобы прям вот тикеты решать... По-моему пока ИИ до этого не дошёл. Всё-таки самая сложная часть по-прежнему: перевести из "хочу Х" в "надо переделать Y, чтобы он был Z", с учётом кучи ограничений: не уронить надёжность, перфоманс, читаемость, поддерживаемость; сделать легко отключаемым по рубильнику, легко расширяемым (но только там, где надо!), обратно совместимым; уложиться в код стиль, дизайн стиль, архитектуру приложения. Но это ладно, могу в теории представить огромный сложный промпт с этим всем. А вот сказать, что как просили, сделать нельзя, зато можно вот так и так; согласовать такое; синхронизироваться с соседями по api и срокам разработки; синхронизировать выкатки, найти способ проверить в условиях ограниченных прав доступа и неработающих кусков тестового окружения; попинать того чувака, который всё ещё не ответил, эскалировать в его руководителя — это всё че-то пока кажется сложным.
Особо умные уже подумали: так зачем это все нужно, если можно просто убрать людей из цепочки? А вот людей сложно убрать. Кто должен писать промпты, кто-то должен валидировать выхлоп. Целиком большую задачу LLM пока не может прожевать, по моему опыту (да и проверить никто не сможет), а если разбить на куски, то нужна синхронизация, а учитывая то, как часто модели выдумывают, ошибаются и откровенно врут, я не знаю, как они будут договариваться, ведь у них пока что garbage in -> garbage out, булшит фильтра в голове, как у человека, у них пока нет.

Ну или я не прав, переубедите в комментариях.

Для тех, кто приходит за чем-то полезным, у меня есть заготовка
Шикарное видео про феминитивы, с позицией, которую я разделяю
Наконец-то всё разъяснили настоящие филологи, а не троечник (ладно, у меня был хор по лингвистике, но откровенно слабенький)
https://youtu.be/7eC2GNCVDH8

Снова про ретроспективы

Основная мысль: нужно регулярно менять формат.

Подробнее. Я уже писал про наши ретро, ориентированные на каждого сотрудника в отдельности. Мы там крутили формулировки, фреймили, это помогло на время. Но дальше мы просто изменили формат радикально и стали проводить ретро в разрезе команды.
Раньше вопросы были про "что помешало [тебе] успеть", "что могло бы помочь [тебе]", "что нового узнал [ты] “. Хотя черно указания числа в вопросах нет, они фреймятся в юнит, в тебя.
Теперь вопросы стали про "что нам прекратить делать", "что начать", "что продолжить". Переключение сразу вытащило на свет кучу топиков. Сразу стало что обсудить.

Недавно я наконец почувствовал, что у нас начинается фаза storming. Есть мнение, что модель Такмана бесполезна, но я пока не уверен в этом. Так вот, мы поймали, как мне кажется, идеальный момент для ретроспективы в формате that guy, this guy. Обозначили границы, дали анонимную обратную связь друг другу, кое-где это помогло разанонимизироваться, потому что договорились и "помирились". Срезали сильно демотивирующие моменты, вызванные банально разным пониманием.
Команда очень довольна новым форматом. Опять 😊

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

Весна

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

Но эта весна была другой. Я с удивлением обнаружил, что мне понравилось. В феврале в Белграде было серо и уныло. И много собачьих какашек на улице (как весной в России, только хуже!).
Но вот к середине марта/апрелю стало замечательно. Во-первых, солнце. Очень тепло. Во-вторых, сразу всё цветёт, всё зелёное, фиолетовое, красное, синее, розовое — очки красиво. Приятно погулять (чего не скажешь о привычной мне весне).

Теперь я видел красивую и приятную весну. Мне понравилось. Делаю вывод, что мне надо жить где-то не в Москве всё-таки.

Про результаты некоторых моих менеджерских потуг

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

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

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

Кстати, про bus factor. Мы свою единичку пробили (ушёл от нас старожил). Но на удивление спокойно прошло. Мы сильно потеряли в производительности, как команда, но сакральные знания нас почти не тормозят. Здесь, конечно, заслуга и всех доков, и борьбы за оформление тикетов, но бо‌льшую часть лично я атрибутирую к парному программированию.

ДПДГ

Я как-то незаслуженно мимолётно упомянул об этом методе в посте про то, как я чуть не умер. Исправляю это недоразумение.

Метод позволяет справиться с ПТСР, некоторыми паническими атаками и некоторыми страхами. Я пробовал использовать только при втором.

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

Вообще рекомендуется делать практику с терапевтом. И практика эта в целом труднее, чем кажется. Но можно делать и самому.

В чём суть?
Нужно сконцентрироваться на травмирующем воспоминании (вспомнить и сидеть переживать его заново). Одновременно с этим надо медленно водить глазами. Можно влево-вправо, можно вверх-вниз, можно описывать окружность, бесконечность, геометрические фигуры. Я смотрю вот это видео и слежу за шариком.
Полезно фиксировать уровень тревоги во время воспоминания, по шкале от 0 до 10. Прекращать можно, когда уровень тревоги упал до 0-1. Это обычно несколько минут (я в 10 укладываюсь всегда). Всё. Вот так просто.

Википедия пишет, что три сеанса обычно хватает для проработки события уровня автомобильной аварии. Мне один сеанс помог с эпизодом гипертонического криза. Два сеанса с ТЭЛА и всей реанимацией. *У меня были панические атаки, особенно жесткая была в аппарате МРТ. Что любопытно, окружающие никогда не понимают, что я в ужасе.

А узнал я об этом методе от психологов, которых привлекал Райф (они были профессионалы по ПТСР), когда ковид согнал нас всех на удалёнку. Видать, с таким стрессом тоже помогает справиться.

Очень интересная небольшая серия постов в канале у Бориса. Речь о распределениях экстремальных величин (максимумов и минимумов). Идеи из этой области иногда применяют в оценках realized волатильности, но контекстов множество. Борис как раз рассматривает максимальную продолжительность жизни человека.
https://t.iss.one/BorisBurkov/686

Над чем я сейчас работаю?

Давайте расскажу, чем я занят на работе, а то всё опционы, опционы, у нас тут есть другой финтех!

Сейчас у меня две подгруппы: разработка платежного шлюза и разработка инфраструктуры безналичных платежей.

Платежный шлюз или PSP (payment system provider).
Несколько наших ребят интегрированы в большую и весёлую команду во главе с Антоном Курандой, которая делает платёжное сердце компании. Архитектура системы обкатана многократно и является эволюцией первого в мире опен сорс процессинга. Разрабатываем всё на golang, с использованием опен сорс базы данных YDB. За последние несколько месяцев мы уже увидели превосходство нового решения: тут и рост конверсии, и улучшение таймингов, и колоссальный рост скорости разработки. Проект перешел из экспериментальной фазы в целевое решение. Но работы ещё очень много! Здесь и многочисленные интеграции с процессингами, и интеграция новых методов оплат, и, конечно, развитие ядра системы.

Инфраструктура безналичных платежей
Здесь у нас экосистема сервисов, которые предоставляют упрощенный API для проведения платежей и дополнительные околоплатежные функции. Примерно половина усилий команды сосредоточена на разработке сервиса на python3. Он получает на вход счет, какой вы обычно получаете в ресторане, и желаемый способ оплаты (карта, СБП, ApplePay и т.п.). А дальше сервис сам понимает, сколько уже списано, сколько необходимо списать (или вернуть) и генерирует необходимые команды к процессингу PSP (про который написано выше). По дороге, можно воспользоваться функционалом по интеграции с антифродом, долгами и биллингом.
Ещё примерно половина усилий уходит на сервисы, написанные на C++ с использованием опен сорс фреймворка userver. Тут у нас сервис управления долгами, кэш методов оплат (это список привязанных карт и других доступных в регионе методов оплат), интегрированный в антифрод систему продуктов. Самый нагруженный сервис в этом сегменте это, пожалуй, кошелек баллов Плюса (ещё бы, баланс светится чуть ли не на каждой странице). Но самая активная разработка в данный момент сосредоточена в сервисе чеков. Это "невозможный" сервис, нацеленный на работу со всеми нашими сервисами во всех странах, позволяющий при том ограничивать влияние разных бизнесов на доступность друг друга.
Ближайшие цели направлены на создание единой точки входа для всех функций экосистемы. Будет еще удобнее! (и мы тоже начали внедрять golang)

А ещё мы нанимаем в обе подгруппы!
Податься можно на эту вакансию. Приходите, буду рад 🤗

Я не вижу ваших репостов! Поднимите ваши репосты выше! Давайте, давайте, оба ваших репоста!


Ладно, если серьёзно, покидайте, пожалуйста, друзьям go-шникам, плюсовикам и питонистам. Мы учим полиглотству. И космополитии немножко (международные офисы).

Как считать железо

У меня в очередной раз наступила пора подсчёта железа (пока я писал пост, она уже закончилась, но да ладно). Нужно прикинуть, сколько процессоров, памяти, дисков и сети понадобится сервисам и базам данных, за которые я отвечаю. Навык считать железо полезный, тем более требуется на собеседованиях продвинутого уровня. Решил вам поведать сие "тайное" знание.

Подготовка
Прежде, чем считать хоть что-то, нужно разработать API и подсчитать примерно количество запросов в это API (в запросах в секунду aka rps). Реализация не обязательна, но интерфейс — да. Нужно знать, какие будут точки входа в сервис, какие и какого размера данные они будут получать на вход и отдавать на выход.

Теперь думаем, сколько у нас примерно пользователей в день. Это примерно как считать количество настройщиков пианино в Чикаго. Думаем, сколько времени в день в среднем они будут пользоваться нашим сервисом. Из этих данных можно понять среднюю нагрузку (rps). Дальше правило большого пальца: в пиковый час будет нагрузка х2 от средней (или х2.5 по Бунину). Вы великолепны, у вас есть максимальный ожидаемый rps.

CPU
Начнём с самого сложного. И уже тут нужно примерно понимать, что будет в реализации: несколько random access в память или сплошные кэш хиты (походы по сети/в бд/на HDD или SSD считать нужно, как сисколы, потому что процессор вряд ли будет простаивать и ждать, пока ему ответят с внешних устройств). Очень примерно, очень грубо. Неправильно: 3 похода в память + чтение 137КБ с HDD. Правильно: ну там несколько сотен случайных походов в память, давай примерно 50мкс скажем.
Для каждой точки входа нужно понять, за сколько времени в среднем она будет отрабатывать.
Следим за руками: если наша функция отрабатывает в среднем за 10мс, то одно ядро за одну секунду (1000мс) может обработать максимум 100 запросов.
Теперь из подготовленных данных смотрим, сколько мы ожидаем rps в пиковой загрузке, делим в данном случае на 100 и получаем количество ядер. Ура!

RAM
Для баз данных или какого-нибудь машинного обучения стоит посмотреть на примерный размер юнита (датасет или средняя запись в базе) и умножить его на количество таких объектов. Потом надо заложить запаса на индексы, фрагментацию, кеши, копирования для промежуточной обработки, бэкапы. Здесь всё сильно зависит от вендора и реализации.
Если у вас не планируется in-memory кешей, масштабной мемоизации или каких-то особенных структур данных, то рост будет чаще всего суб-линейным. В типичном веб-сервисе данные очень активно переиспользуются между запросами, а потому не растут линейно с ростом rps. Довольно понятной, но грубой оценкой снизу можно считать rps*размер входящего сообщения (его надо десериализовать).
Но единственным более или менее надежным способом здесь является запуск приложения и замер (ну потому что очень уж много способов память отжать: mmap, IPC, частая аллокация и т.д.). И не забыть про RAM под нужды ОС!
Если вы знаете способ лучше — жду вас в комментариях! Я не нашёл.

Продолжаем считать железки. Теперь к переферии.

NETWORK
Тут всё несложно. У нас уже есть rps, размеры входящих и исходящих данных. Обычно, всякая мета типа хедеров сетевых протоколов пренебрежимо мала по сравнению с данными, поэтому можно дополнительно об этом не думать. Умножаем rps на размеры входящего и исходящего сообщений, получаем upload/download объёмы трафика. Дальше смотрим в таблицу красных резиновых мячей пропускных способностей сетевых карт и интерфейсов. Теперь мы можем понять, сколько нам нужно машин и с какими интерфейсами (10Gb Ethernet или 100Gb Ethernet или что-то ещё).

STORAGE
Если это не база данных или что-то подобное, то чаще всего здесь у нас будут только ОС, бинари приложения и логи. Зная rps и прикидывая, сколько примерно будем писать догов на один запрос, мы можем понять рейт записи логов (сколько байт в секунду). Тут можно уже выбрать железо (конкретные характеристики и количество), но обычно хватает самых простых конфигураций.
Дальше смотрим, как часто будем ротировать логи, понимаем, сколько максимально места нужно под это. Вот вам и число — объём диска. Если у вас там ещё всякие raid массивы, то нужно домножить на соответствующий мультипликатор.

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

Основная задача руководителя

Давайте так: как меряют успехи руководителя? По успехам его команды. Что считать успехом команды, какой там чей вклад — вопрос отдельный. Но понятно, что чем больше и качественнее сделано в заданный период времени — тем лучше.

Что же в таком случае нужно делать руководителю, чтобы было хорошо? Нужно делать так, чтобы за единицу времени делалось больше работы.
Как этого добиваться? Здесь есть две основные стратегии.

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

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

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

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

Добавим сюда ещё стандартные замедляторы:
- переключения контекста от задачи к задаче
- потеря контекста из-за встреч, обеда, выходных, вопросов коллег
- откладывание и прокрастинация из-за непонятно поставленной задачи

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

По-существу, большая часть всех этих элементов включается в ёмкое понятие: планирование.

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

Поэтому основная задача руководителя: иметь план. Для команды и для себя. И чем дальше вперёд этот план есть, тем проще работать, проще что-то в нём менять, проще управлять рисками.

Алгоритмы мои, алгоритмики

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

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

Так вот, я же тут погружаюсь в С++. Недавно прочитал супер интересную статью про бинарный поиск, решил с вами поделиться.

Какие проблемы у наивного бинарного поиска? Плохой бранч предикшен (потому что на каждом бранче вероятность угадать 50%) и плохой паттерн использования памяти (потому что опять же невозможно спрогнозировать, какую линию нужно префетчить).

Какие есть улучшения? Самое известное — galloping binary search. Это гибрид линейного с бинарным. Мы топаем вперёд по степеням двойки, пока не перепрыгнем, а там уже линейный. Здесь всего один бранч миспредикшен и довольно неплохой префетч.

Что ещё? Ещё довольно популярное решение — B-tree. Это дерево поиска, у которого не два дочерних узла, а k. Можно подобрать k таким, чтобы полностью его выбирать, например, с одного блока HDD или, что для нас сейчас интереснее, чтобы k полностью занимал кеш-линию. Здесь, кажется, что с бранчами не радужно: ведь мы снова в ситуации 50/50. К тому же на каждой итерации (в каждом узле) добавляется подпроцедура поиска внутри узла. Но зато количество кеш-промахов минимальное!

Однако, вот в этой статье от то ли 2015, то ли 2017 года авторы нашли решение ещё лучше.

Многие знают, что бинарная куча очень хорошо ложится в массив. Причём так, что для каждого элемента, находящегося по индексу j, можно найти его потомков по индексам 2*j и 2*j+1.
Но мало кто знает, что можно точно так же уложить и бинарное дерево поиска!
Вот так можно сложить отсортированный массив чисел от 1 до 7:
4261357

Такая укладка носит имя Eytzinger, в честь изобретателя.
Теперь следите за руками. Очень хитрый хак. Мы топаем по индексам (2*j, если число меньше либо равно искомого; 2*j+1 в противном случае), пока не вылезем за границы массива. Так как все походы в левое поддерево — удвоения индекса, то по сути весь путь зашифрован в двоичном представлении получившегося индекса. Поэтому, нам нужно отрезать все последние походы в правое поддерево и мы получим искомый индекс. Это всё делается битовыми операциями. Более того, можно совсем избавиться от бранчей, если скастить условие к int:

while (j <= n)
    j = 2 * j + (a[j] < x);

Скорее всего, нифига не понятно написал, поэтому любопытным предлагаю подсмотреть здесь. Там краткая выжимка конкретного алгоритма.

Почему хорошо работает? Потому что мы всё время движемся в одну сторону по массиву, хороший бранч предикшен (просто цикл while, причем еще и условие хорошее) и очень понятный паттерн префетча. Настолько понятный, что можно префетчить сразу много кэшлиний. И в этом ключ! Несмотря на то, что у B-tree количество кэш промахов меньше, для него мы должны префетчить линии последовательно, сложно угадать, какая будет следующая. Для укладки Eytzinger же мы можем не ждать, пока получим следующую линию, а тащить их в кэши сразу пачками. Таким образом B-tree ограничено латенси доступа в память, а укладка Eytzinger — фрупутом (простите).

Любопытное наблюдение. B-tree это алгоритм cache-aware, то есть требующий знания о размере кэш линии. А вот Eytzinger binary search как-будто бы cache-oblivious, то есть он учитывает, что кэши существуют, но ему не требуется знание об их размерах. ПЕРЕНОСИМОСТЬ.
Нахожу интересным то, что в данном случае дополнительная информация не помогает разогнать алгоритм.

Пятничного негатива минутка

Посмотрел я тут выпук(sic!) книжного клуба. Это шок контент для меня. Я даже и представить себе не мог, что можно _так_ прочесть биографию Фейнмана.
Книга буквально вся состоит из самоиронии. Читая её, понимаешь, что Нобелевские лауреаты тоже люди. Со своими странностями, глупыми поступками и ошибками.
Комики же почему-то решили, что
- это автобиография (да, там на обложке написано, что автор Фейнман, но по факту это не так, эта книга основана на рассказах Фейнмана, но это не автобиография)
- Фейнман постоянно рассказывает, какой он крутой (смотрит на взрыв атомной бомбы через стекло)
- Фейнман хвастается мудацкими и глупыми поступками (чаевые под окном воды, взломы сейфов)
- у Фейнмана нет друзей (про них якобы нет упоминаний)
- главное (и, видимо, единственное) достижение Фейнмана — создание атомной бомбы (любой физик знает, что это даже не близко к правде, его вклад в бомбу не такой большой, как нескольких других, более старших коллег)
- что свои причуды Фейнман принимает, как проблемы окружающих (я не понимаю, чем надо было читать, чтобы это так увидеть)

Короче, я прям хорошо отношусь к тому, что делают Квашонкин и Ловкачёв, в частности к книжному клубу. Но это просто какая-то феерия.