Как отказывают в IT. Часть 2 — молчание ягнят

Ссылка на первую часть

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

Если вы нанимаете к себе разработчиков, не делайте так 👇, пожалуйста!

3️⃣ Компания 3 (сквозная нумерация с первой частью) — большая и известная корпорация.

Меня собеседовали на Go-разработчика при том, что я пока не написал ни одной строчки на этом языке 😂 Меня заверили, что нанимают по принципу «был бы человек хороший, а языку Go обучим».

Шли мы очень бодро. Первый собес — классические leetcode-like задачи плюс теоретические вопросы про многопоточку, структуры данных, сети и внутренности C++. Быстрый фидбек: «Всё хорошо, идём дальше». Второй собес — задача на написание кода, очень сильно приближенная к реальной практике backend-разработки. Про это надо будет сделать отдельный пост, потому что это новый для меня формат собесов, который, кажется, начинает набирать популярность. Пару дней была тишина, потом сказали: «Идём дальше».

Третий собес — system design с положительным итогом. Через несколько дней звонит рекрутер и сообщает об отказе без фидбека. По его словам, он впервые в своей практике видел, чтобы эта контора отказала молча.

Три успешно пройденные секции из трёх — и никаких объяснений 🤷‍♂️

4️⃣ Компания 4 — ещё один HFT

Вышли на меня сами. Первый собес — разговор с лидом команды, который решил не включать своё видео 🤔 Технических вопросов не было, говорили «за жизнь». И как-то очень туго шло — не нашли контакта. Второй собес — такой же разговор, но уже с другим лидом. Он и камеру включил, и контакт мы легко установили. Было немного вопросов по сетям и C++.

Присылают отказ со словами «Сейчас не нанимаем Senior — только Middle. Как появятся позиции на Senior, обязательно с вами свяжемся». Наверняка причины другие, потому что странно, что HFT закрывает найм Senior позиций. Но открыто сказать кандидату, что именно не устроило, не смогли.

Мораль

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

К счастью, есть те, кто действует иначе, но об этом я расскажу в третьей части.

А с вами бывали подобные ситуации? Поделитесь в комментариях.

Каково работать с кодом на C в 2024 году

Итак, я уже неделю плотно работаю с кодовой базовой СУБД Pangolin, которую СберТех разрабатывает как для Сбера, так и для внешних клиентов.

Pangolin основан на опенсорсном PostgreSQL, поэтому подавляющее большинство кодовой базы написано на чистом C. Я знал, что так будет и осознанно пошёл в этот проект. Сейчас хочу подвести первые итоги, каково это после 16 лет разработки преимущественно на С++ столкнуться с С 😳

Боль
🤕 Простота кода — вернее её отсутствие 😉 Открываешь функцию на 1000 строк, которая вызывает функцию на 600 строк, которая вызывает ещё 5 функций по 300 строк каждая
🤕 RAII, я по тебе скучаю. Я рыдал, когда читал код вот этой функции. В строке 2482 она получает char* passwd, аллоцированный другой функцией. Ниже есть 10 мест, где вызывается return, и в каждом из них надо не забыть вызывать pfree(passwd), а то же память утечёт 🤦

Кайф
😎 Компилируется космически быстро, несмотря на исполинские размеры кодовой базы 🚀
😎Пошаговая отладка дебаггером как на университетских лабораторках — быстро, легко, понятно и просто работает из коробки. Я сейчас очень много этим пользуюсь, чтобы освоиться в кодовой базе и изучить, какая функция откуда вызывается.
😎 Сберовский GigaChat неплохо знает исходники PostgreSQL и со второго-третьего вопроса неплохо объясняет, в какое место кода надо смотреть, чтобы найти, как работает нужная мне функциональность. Сильно ускоряет погружение в кодобазу.
😎 VS Code индексирует весь код из коробки, и навигация работает... просто работает 👍

А кто из вас работает на чистом С? Как вам?

Доклады, нетворкинг и ничего лишнего

IT конференции сильно изменились за прошедшие 10 лет.

Я помню самую первую конференцию C++ Russia в 2015 году. Билет на неё стоил, кажется, 1000 рублей. Было много сильных докладов, пара-тройка компаний пришли со стендами, на которых разработчики делились техническими особенностями своих решений.

Билет на Highload++ в Москве сейчас стоит 90 000₽, там наверняка будет 100500 стендов самых разных компаний, на которых специально обученные люди проводят бесконечные розыгрыши мерча и собирают лиды̀ для дальнейших контактов со стороны рекрутмента. Сейчас конференции — это бизнес, который участникам продаёт нетворкинг с выдающимися представителями индустрии, а компаниям — собственно участников (поправьте меня, если я не прав).

Интересно наблюдать за людьми, которые в этом течении идут против тренда. Золотой голос российского IT Андрей Смирнов сделал свою конференцию Soft Weekend в том виде, какой была первая C++ Russia: доступные билеты, крутые спикеры, нетворкинг и больше ничего. Софтовые доклады давно собирают полные залы, ведь все понимают, что для роста в карьере и зарплате одних хардов недостаточно. Андрей сделал эту конференцию, чтобы дать возможность прокачать универсальные для любого направления и стека скиллы, требуемые почти в любой рабочей ситуации.

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

Когда — 23 ноября 2024, 10:00-18:00
Где — Москва, Пространство Весна, Спартаковский п., 2с1
Подробности — на сайте

P.S. По промокоду IAMHIRED действует скидка.

Сперва скажите нет

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

Подходит тем,
— кого разрывают 100500 одновременных задач
— кто помогает коллегам не потому что может, а потому что неловко отказать
— кто стабильно выручает компанию и стабильно выгорает 😢
— кто чувствует, что говорить "нет" сложно, стыдно, нехорошо

Время — 20:00 мск
Где — в чат-боте «Выше вилки»

Приходите!

Моё рабочее место

В комментариях к одному из постов меня попросили рассказать о своём рабочем месте. Что ж, месяц работы R&D разработчиком в Sbertech позади — есть чем поделиться. Давайте расскажу, какими инструментами пользуюсь на рабочем ноутбуке.

Операционная система — Windows

Здесь, наверное, в меня полетят первые помидоры и насмешки 🍅 Но мне правда удобна Windows — я почти всегда пользовался ею. Все равно вся разработка происходит на удалённых Linux-виртуалках, поэтому ОС ноутбука — всего лишь тонкий клиент. Я никогда не использовал MacOS — мы с ней всё никак не встретимся. А Windows я всегда предпочитал по двум причинам.

Первая — это PowerPoint. Так как я часто где-то выступаю, мне гораздо удобнее готовить презентации в нём, чем в инструментах, которые есть в Ubuntu. В последнее время всё больше использую Google Presentations, но если надо сделать что-то сложнее маркированных списков, всегда берусь за PowerPoint.

Вторая причина — это Punto Switcher (я не нашёл аналогов для Ubuntu)

Выделяю его в отдельный пункт, потому что для меня это must have инструмент. Очень жаль, что Сбере служба ИБ его запретила. Я подсел на него, когда мы делали «Пояса по С++». Тогда приходилось очень много писать текстов, где русский язык перемежался с кодом, и переключать раскладку туда-сюда жутко бесило. Когда я освоил Punto Switcher и заточил его под себя, мир разделился на до и после 😆 У меня "ёё" автоматом превращается в "``", чтобы легко форматировать куски кода, «ПРивет» сам превращается в «Привет» и много других удобных штук.

Типографская раскладка Ильи Бирмана

На неё меня подсадил Антон Полднев тоже во времена «Поясов по С++». Она позволяет легко набирать «вот такие кавычки», длинное — тире, [квадратные скобки], знак рубля ₽ и кучу всего другого, но пользуюсь я в основном тем, что перечислил.

IDE — VS Code с плагином GigaCode

Тут без сюрпризов. Я года 3 уже ни у кого не видел ничего кроме VS Code. Я много лет был преданным пользователем CLion, но в погоне за фичами они полностью растеряли быстродействие, что сделало CLion абсолютно неприменимым даже на не самой большой кодовой базе Яндекс Еды образца 2021 года. С тех пор я пересел на VS Code и пользуюсь им. Да — фичей меньше, но работает быстро и умеет необходимый минимум.

GigaCode пока скорее разочаровывает и сильно уступает GitHub Copilot, я рассчитывал, что он мне поможет писать тесты на Perl (которого я не знаю), но он оказался бесполезен.

И, наконец, Obsidian

Инструмент для заметок и формирования базы знаний. Киллер фича по сравнению с Notion, Evernote, Confluence, wiki и прочими web-based штуками в том, что Obsidian — это просто браузер Markdown-файлов, которые хранятся у вас на диске и всегда доступны offline. А это значит:
— быстрый поиск по всей базе
— Markdown — легко запоминаемые возможности оформления файлов (меня в Notion бесит, что парой неаккуратных нажатий можно разнести оформление заметки в пух и прах)
— если Obsidian решит, что больше не работает в России, вся ваша база знаний останется с вами

Это то, чем я пользуюсь каждый день. А как у вас?

Если не говоришь "нет", твоё "да" ничего не стоит

Примерно год назад мой знакомый, который работает в Google, поделился историей. Каждый день к нему ходил "чужой" менеджер и по 1-2 часа обсуждал с ним свои проекты, никак не связанные с целями моего собеседника. Он понимал, что тратит время впустую, но не отказывал этому менеджеру, потому что боялся, что в случае отказа менеджер напишет на него плохой отзыв и это негативно скажется на результатах ревью.

После того разговора я задумал сделать тренинг по конструктивным отказам, чтобы помочь людям выпутываться из подобных ситуаций. Я и сам в прошлом много времени провёл на бесполезных встречах, потому что "руководитель позвал", и участвовал в side проектах, потому что "неудобно отказать; ну, может, на ревью зачтётся". Так что ситуация хорошо знакома.

После того разговора я и Паша Филонов (мы вместе делаем "Выше вилки") стали собирать материал для тренинга по отказам. Я прочитал "Сперва скажите нет" Джима Кемпа, прошерстил конспекты курсов по коммуникации, которые проходил в Яндексе, посмотрел кучу лекций Ильи Мутовина.

С отказами есть две проблемы:
👉 это морально тяжело, поэтому мы можем избегать их совершать
👉 мы можем отказывать нечётко, из-за чего собеседник думает, что мы согласились ("может быть, смогу через неделю")

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

Отработке этих формул и посвящён наш новый тренинг "Нет".

✅ У нас будет 2 созвона в зуме по 3 часа каждый - 25 ноября и 2 декабря
✅ Разбираем 4 ситуации, в которых оказывается каждый из нас на работе:
    1⃣ отказ от проекта, в котором вы не видите пользы
    2⃣ отказ от сомнительной задачи, которую вам спустило руководство
    3⃣ как не испортить отношения с коллегами, не соглашаясь на их предложения
    4⃣ мне предлагают проект мечты, а я весь в делах. Что делать?
✅ Каждую из этих ситуаций мы разбираем по схеме
    1⃣ Участники в парах ведут переговоры на тренировочном кейсе
    2⃣ Мы с Пашей даём теорию, как следует вести разговор в этой ситуации
    3⃣ Участники в парах отрабатывают полученный материал. Итого каждый участник за время тренинга отрабатывает 16 переговорных кейсов
✅ Между встречами даём неделю перерыва, чтобы усвоить материал и попробовать его в жизни.

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

Не софтами едиными

Я давно не упоминал, что у меня есть курс «Алгоритмический фундамент программиста», который я сделал, чтобы снять вопрос о подготовке к алгоритмическим собеседованиям.

Он размещён на платформе Stepik, и там сейчас идёт распродажа в честь «чёрной пятницы». На «Фундамент» можно попасть со скидкой 25%.

Напомню основные преимущества курса:
— это онлайн-курс, который вы проходите в удобное для вас время
— на протяжении курса вы решите 100 задач по программированию — после такого объёма практики просто невозможно не стать лучше в программировании
— в курсе нет ничего лишнего — только темы, которые я реально встречал на coding interview

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

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

Моё рабочее место — девайсы

Недавно был пост про софт, который я привык использовать. Давайте обсудим и железки. На фото — стол, за которым я работаю дома.

На YouTube много видео типа «рабочее место программиста 2024», в которых показывают какие-то умопомрачительные столы, гигантские мониторы, какую-нибудь светодиодную подсветку и т.д. У меня всё проще.

Ноутбук DELL Latitude с диагональю 15,4

Был моим рабочим ноутбуком в Яндексе. Когда я увольнялся, как раз подошло время его списания, и я выкупил его себе по смешной цене. Ему уже 5-й год пошёл, но работает безупречно. Кроме одной детали...

Bluetooth клавиатура Logitech...

...появилась у меня, потому что нижний ряд клавиш моего ноутбука стал странно себя вести: кнопки то не нажимаются, то дают двойное нажатие. И это касается только стрелок влево/вправо, пробела и клавиш C, V, B, N. Я носил его в ремонт, 3 дня был совсем без ноута 😱, мне его вернули с вердиктом «дефект не воспроизводится». Я психанул, купил bluetooth клавиатуру и стал пользоваться ею вместо штатной.

Подставку под ноутбук завёл случайно. Раньше всегда думал, что её используют, чтобы освободить место на столе. Однако как-то супруга стала жаловаться, что у неё шея болит после работы за ноутом. Я вспомнил про подставку, купил ей. Попробовал сам, подумал «и как я вообще жил без неё все эти годы» и купил себе тоже. Правда шее гораздо удобнее, потому что весь день смотрю вперёд, а не вниз.

Ну и после появления подставки Bluetooth клавиатура стала уже не костылём, а необходимостью. Особенно удобно, что я ею же пользуюсь для работы на ноуте Сбера — не надо переучивать раскладку, пересаживаясь с ноута на ноут.

Наушники Soundcore

Мои предыдущие Bluetooth наушники перестали держать заряд. Я пришёл в магазин Dr. Head на Новом Арбате в Москве и попросил «хорошие наушники, чтобы общаться в зум». Мне дали эти — мне понравилось.

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

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

Как вам? Кидайте в комментарии фото своих рабочих столов.

Всех с наступающим Новым годом! 🎉🥳

Желаю, чтобы в 2025 вам везло чаще, чем в 2024, а не везло реже, чем в 2024 😉 А с остальными вещами, уверен, мы справимся сами 💪

Блеск и нищета языка С

Сегодня возобновляется рабочий режим и хочется снова поделиться впечатлениями о работе на языке C, на котором мы делаем СУБД Pangolin в СберТехе.

Два месяца назад я уже делился впечатлениями. Сейчас опыта стало больше, и я подметил интересную двойственность с работе на C.

1. Простота чтения кода

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

2. Высокая сложность чтения кода

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

Это выматывает.

3. Мне тяжело писать код

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

Мне кажется, примерно так же чувствуют себя люди с опытом в Python или С#, первый раз начиная программировать на С++ 🤯

Я сейчас работаю над расширением для PostgreSQL. Его необязательно писать на С, хотя большинство из них написаны именно на С. Я в конце года 2 дня страдал, пытаясь корректно написать значительный кусок функциональности на С. Потом психанул, за день разобрался, как это сделать на С++, и за полдня написал всё, что не мог до этого.

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

Есть те, кто вникал в С++ после Python? Были у вас схожие ощущения?

А вы достаточно проактивны?

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

Лидеры компаний много говорят, как важно быть проактивным сотрудником. Впервые с этим buzz word'ом я столкнулся в 2014 году. Дождливым осенним днём я как обычно пришёл на работу в Яндекс и с удивлением обнаружил, что примерно половина коллег моего отдела в офис не пришли. Остальные недоумевали и не знали, куда все подевались 😱 Только спустя несколько дней нам рассказали, что в тот день компания отобрала «высокогрейдовых и проактивных» сотрудников и увезла их загород на стратсессию.

Паршивое тогда было чувство: вроде мы все работали вместе, а тут взяли и всех молча поделили на умных и красивых 🥺

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

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

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

☝ Вот работаю я работу и вижу, что какие-то процессы плохо устроены. Я начинаю людям сообщать об этом, а они сопротивляются и ничего не меняют. Я не исправил проблему — я не проактивный?

✌ Или какой-то внутренний инструмент работает плохо. А его делает команда в 15 человек. Я принёс им багрепорт, они его проигнорировали. И что? Я должен засучить рукава, разобраться в их кодовой базе и сам сделать фикс? Звучит круто, но чтобы вникнуть, нужно не меньше месяца, а у меня у самого немало работы... Если я так не делаю, я не проактивный, получается?

В общем, я так и не научился понимать, достаточно ли я проактивный.

☺ И только на прошлой неделе я, кажется, нашёл для себя ответ. Я был на встрече по инструменту, про который ничего не знаю. Довольно быстро я потерял нить обсуждения и, чтобы время встречи прошло с пользой, стал читать про этот инструмент документацию и, в конце концов, заглянул в его код. А там кровь из глаз! 🥴😵 🤢 🤯 Код написан на C++, но он совершенно не идиоматичный — это, скорее, "C с классами", но не C++.

Я прихожу к лиду и говорю: «Вот эта штука плохо написана на C++. Я могу смотреть pull request'ы на C++ и предлагать более простые конструкции». Теперь ко мне прилетают все PR'ы, и я отсматриваю там код на C++. Уже один баг у коллеги таким образом нашёл 💪

И вот это, на мой взгляд, как раз достаточная проактивность — «Если видишь, что сделано плохо, сделай настолько хорошо, насколько позволяют твои возможности». И это важно помнить.

А как у вас с проактивностью?

API курильщика или «Хорошо, что я не психопат»

СУБД Pangolin, в которой я теперь работаю, основана на open-source'ном код PostgreSQL. А значит, наша кодовая база является бесконечным источником говнокода поучительных примеров 😁

Я вчера два часа жизни потратил на отлавливание проезда по памяти. Написал код, который создаёт новый кортеж для последующей вставки его в таблицу. И там segfault 💣 А Postgres — это всякие межпроцессные взаимодействия, синхронизация через общую память и прочие места, где легко накосячить. Ну вот я копал в эту сторону, обложившись GDB, breakpoint'ами и отладочным выводом в логи.

Какого же было моё возмущение, когда я нашёл причину 😬🤬

В Postgres есть довольно простая функция создания нового кортежа — heap_form_tuple:

HeapTuple heap_form_tuple(
    TupleDesc tupleDescriptor,
    const Datum *values,
    const bool *isnull);

Она принимает некое описание кортежа и два массива:
- значения его колонок
- булевский массив, который задаёт, какие колонки имеют значение NULL
Размер этих массивов записан в tupleDescriptor.

А ещё для удобства есть константы, которые задают номера колонок системных таблиц. То есть массив values можно заполнять вот так:

Datum *values = ...;
bool *isnulls = ...;

values[Anum_pg_authid_oid] = ObjectIdGetDatum(roleid);
values[Anum_pg_authid_rolname] = CStringGetDatum("user");
...
isnulls[Anum_pg_authid_rolvaliduntil] = true; // Говорим, что эта колонка имеет значение NULL

HeapTuple tuple = heap_form_tuple(desc, values, isnulls);

И какого же было моё изумление, что нумерация констант Anum_pg_authid_oid, Anum_pg_authid_rolname и т.п. начинается с единицы! С единицы, Карл! В языке, где вся индексация везде осуществляется с нуля! 🤯

И проезд по памяти у меня происходил в строке isnulls[Anum_pg_authid_rolvaliduntil] = true, потому что Anum_pg_authid_rolvaliduntil имеет значение 12, а в массиве isnulls как раз было выделено 12 элементов 🤦‍♂️

А значит, чтобы корректно использовать удобные константы, нужно каждый раз вычитать из них 1 при заполнении кортежа (код ниже взят отсюда):

new_record[Anum_pg_authid_rolname - 1] =
   DirectFunctionCall1(namein, CStringGetDatum(stmt->role));
new_record[Anum_pg_authid_rolsuper - 1] = BoolGetDatum(issuper);
new_record[Anum_pg_authid_rolinherit - 1] = BoolGetDatum(inherit);
new_record[Anum_pg_authid_rolcreaterole - 1] = BoolGetDatum(createrole);
new_record[Anum_pg_authid_rolcreatedb - 1] = BoolGetDatum(createdb);
new_record[Anum_pg_authid_rolcanlogin - 1] = BoolGetDatum(canlogin);
new_record[Anum_pg_authid_rolreplication - 1] = BoolGetDatum(isreplication);
new_record[Anum_pg_authid_rolconnlimit - 1] = Int32GetDatum(connlimit);

Хороший API легко использовать правильно и тяжело — неправильно. API выше — плохой. Гораздо лучше было бы пронумеровать константы с нуля, а внутри функций, которым нужна нумерация с единицы, делать +1. А так получилось, что деталь реализации пролезла в интерфейс, и отобрала у меня 2 часа на дебаг 😔

Как говорится, пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете. Хорошо, что я не психопат и, разобравшись с этим, продолжил заниматься рабочими задачами. А то ж ведь мог и в git blame полезть 😆

А у вас тоже есть шпаргалка по perf?

Чтобы программисту быстрее справляться с задачами, важно хорошо владеть инструментами и эффективно их использовать: знать горячие клавиши в IDE, уметь анализировать coredump в GDB, находить узкие места в коде с помощью профайлера.

Однако есть инструменты, которыми объективно тяжело пользоваться. Для меня, например, таким является профайлер в perf. У него так много опций и возможностей, что я каждый раз заново изучаю, с какими параметрами его надо запустить, чтобы построить flame graph тормозящей программы.

Я знаю, что у многих просто есть шпаргалка, как его запускать, и они просто копируют оттуда команды в консоль 😁

На днях в мире стало одним профайлером больше — Яндекс выложил в Open Source свою систему непрерывного профилирования Perforator. Во всех подробностях они рассказывают о нём у себя на Хабре.

Мне очень понравилось, что одной командой sudo ./perforator record --serve :1234 -- ./main можно прогнать профайлер и сразу получить flame graph у себя в браузере. Это удобно.

В статье очень много технических деталей и подробностей того, как профайлеры работают под капотом — прочитал с интересом.

Perforator поддерживает программы на нативных языках (C++, C, Go, Rust), а также экспериментально Python и Java. Он используется внутри Яндекса уже довольно давно для анализа производительности распределённых бекендов (ещё когда я там работал, я встречал это название 😃). Поэтому Perforator умеет работать не только локально, но и в k8s.

Исходный код доступен под лицензией MIT (и GPL — для eBPF-программ) и запускается под x86-64 Linux.

Визуализация — здесь.

Переходите в гитхаб и попробуйте Perforator в деле

А как у вас проходит демо?

У нас на работе есть отличная практика — устраивать демо своей работы для коллег. Это не просто показ кода, а настоящий мастер-класс! 💪 Вчера я как раз проводил такое демо, и оно привело к неожиданным результатам. 😲

Я уже три месяца работаю над одной фичей и, наконец-то, был готов показать коллегам, что у меня получилось. Фича требует значительной предварительной настройки: в этом конфиге одно прописать, в том — другое. 🔧 Всё это довольно муторно, поэтому я написал автотесты для всех сценариев.

Моё первое предложение было продемонстрировать код тестов и показать, что они работают. Но лид сказал, что по правилам нужно выполнять команды в консоли прямо во время демо, чтобы не только разработчики, но и администраторы БД понимали, что я сделал. 😒

Ну ладно, начал готовиться. Всё локально настроил, запустил — не работает 😳 Разбирался, разбирался — понял, что допустил опечатку в одном из конфигов. 🤦‍♂️

Настроил другой сценарий — тоже не работает. 🤔 Стал разбираться — понял, что не предусмотрел один сценарий, сделал доработку. 💡

Настроил третий сценарий — опять не работает 🤯 Оказалось, вылез баг, который я не отловил автотестами. 🛠 Ну и так далее... Только один из пяти сценариев заработал сразу. 😞

По итогам подготовки:
— Вся рабочая неделя ушла на подготовку к демо. 📅
— Сделал одну доработку функциональности. 🔧
— Исправил два бага. 🎯
— Доработал тесты, добавив сценарии, которые возникли только во время подготовки. 📜

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

Необычность этой практики для меня в том, что она позволяет собрать фидбек с коллег, увидев их взгляд на вещи. 👀 Раньше я привык к режиму: «Сделал фичу, выкатил в прод, проверил, что работает; побежал дальше, потому что нужно больше перформить». 🏃‍♂️ По старой памяти, было тревожно целую неделю готовиться к демо — в голову лезли мысли: «А достаточно ли я перформлю?» 🤔

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

А как вы проводите демо и что необычного в вашей практике?