Часть 2. Есть ли настоящее и будущее у микробенчмаркинга?

Продолжаем исследование, первая часть здесь.

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

programming-language-benchmarks.vercel.app → тестируются базовые алгоритмы, написанные на разных языках (без фреймворков), представлено несколько связок алгоритм + рантайм / компилятор для каждого языка, удобный интерфейс для проведения сравнительного анализа языков, можно посмотреть исходный код (как впрочем и на всех остальных ресурсах)

benchmarksgame-team.pages.debian.net → аналогичен предыдущему, но с менее дружелюбным интерфейсом. Из интересного: судя по дискуссии, там когда-то был Kotlin, но выпилили за отсутствием интереса ☔️

web-frameworks-benchmark.netlify.app → расширенный вариант (по количеству исследуемых связок) рассматриваемого ранее sharkbench.dev. Также тестируются довольно простые сценарии на железе уровня домашнего ПК.

techempower.com/benchmarks → самый фундаментальный труд из представленных: много, нет, МНОГО связок-язык фреймворк, которые почти ежегодно тестируются на prod-like железе в 7 различных сценариях (JSON Serialization, Single Database Query, Multiple Database Queries, Fortunes, Database Updates, Plaintext, Caching). Подробнее в их wiki.

Первые два кандидата хороши, но ответа на вопрос «какую взять связку для нового микросервиса» они не дадут. Тем не менее, если интересует изолированная производительность рантайма — эти ресурсы можно добавить в закладки.

Перейдем сразу к четвертому кандидату и работе, проделанной TechEmpower. Титанический труд, моё почтение! Получился фундаментальный обзор существующих решений. Я точно на час-другой залип, разбираясь кто такой Вован и что мне делать с офисным этажом 🤣. Если рассматривать решения на Java / Kotlin / Go / Scala / Rust, то в каждой из категорий чаще побеждают связки на Rust или Java. Уфф, не придется Go учить пока! Как и в прошлый раз в категории Java в топах видим Quarkus и Vert.x. Прощай Spring? Rust судя по этим тестам можно считать абсолютным лидером среди вообще всех языков. Вот и определились потенциальные кандидаты для гейтвея 👦?

Добавлю ложку дегтя, чтобы жизнь медом не казалась. Для честного сравнения абсолютно необходим вдумчивый разбор каждой реализации — насколько корректно реализована микрологика и используются библиотеки, что кэшируется, не было ли решение намеренно затюнено или наоборот под конкретный бенчмарк. Чего пока не хватает и, наверное, чего никогда не будет в такого рода бенчмарках, так это навороченных боевых сценариев, которые можно найти в кровавом enterprise, а именно:
* приближенности тестируемого кода по сложности к уровню микросервиса, а не просто "выжать максимум из худенькой ручки"
* сериализации / десериализации сложных структур
* интеграции с брокерами сообщений (хотя взаимодействие с реальными СУБД есть)

Много хочу? Определенно 👍. Удивительно, что нет или я не нашел? ресурса, где бы упор шел на тестирование прицельно JVM-приложений, обмазанных логикой и интеграциями. Кажется, что написав сервис один раз, его будет не так сложно портировать под другие фреймворки. Может нам было бы достаточно поменять библиотеку сериализации / работы с MongoDB / Kafka? Хотя, конечно, с точки зрения долгосрочной поддержи это будет достаточно затратное мероприятие. Да и насколько такому тестированию можно будет верить? Подняли мы тут на днях немажорные версии библиотек на гейтвее и нагрузочное тестирование показало рост CPU в районе 10% 🤣 В итоге никогда точно не скажешь, как фреймворк поведёт себя на реальных задачах, а не в изолированном микробенчмарке. Идем проводить эксперименты на стенде нагрузочного тестирования? 💯%

Если знаешь другие ресурсы, где проводят такие сравнения — пишите мне в личку @senior_junior_dev, буду рад дополнить подборку.

После того, как мой прошлый помидорный таймер приказал долго жить после трех дней работы, потребовав 11$, я понял, что не хочу больше это терпеть ☝. Я хочу гибкости, настраиваемой статистики и полного контроля над происходящим. Пришлось повайбкодить, чтобы у тебя тоже был такой инструмент. Итак...

Открой для себя Pomodoro Supreme — сверхнадёжный отказоустойчивый таймер фокусировки моей собственной разработки.

🚀 Особенности, которые вдохновляют

🌐 Всегда с тобой — в любой точке планеты
Работает в облаке, синхронизируется автоматически: начни сессию в Москве, продолжи во Владивостоке. Всё, что тебе нужно — Google-аккаунт и доступ в сеть Интернет.

🛡 Абсолютная отказоустойчивость
Google-инфраструктура обеспечивает надежность уровня 99.999%. Даже апокалипсису придётся подождать до конца твоей фокус-сессии.

🧩 Гибкость без ограничений
Поддержка любых активностей, настройка длительности, расширяемость через Google Apps Script — хочешь Telegram-бота, Slack-оповещения или аналитику? Легко! Ты всё это сможешь добавить сам!

📦 Полная автономность
Не требует хостинга, развертывания или оплаты серверов. Все данные хранятся в Google Таблице — просто, прозрачно, под твоим контролем.

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

Никаких установок. Никаких банковских карт. Только ты, твоя цель и максимальная концентрация.

Готов начать? Просто открой Google Таблицу. Скачай код тут 😵‍💫 Перейди в интерфейс Apps Script, скопируй код в соответствующие файлы и нажми "Начать развертывание" ⌨️

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

Активный найм — много собеседований. Чтобы не нарваться на кандидата, который проходит паровозик (несколько кандидатов идут на одну и ту же вакансию, собирая базу вопросов) или пользуется базой слитых вопросов, выработал для себя ультимативную тактику. Каждый раз задаю на 80% новый набор вопросов, благо ChatGPT не страдает от недостатка фантазии. Конечно, такой подход требует как бОльшую подготовку перед самим собеседованием, так и сильную теоретико-практическую базу. Все это в наличии 😎

Для того, чтобы отсеять накрутчиков опыта, выполняем ревью кода и решаем небольшие практические задачки на знание языка. Условие одной из них: нужно написать неблокирующий потокобезопасный стек, не используя коллекций из библиотеки j.u.c. Попробуй свои силы. Вот решение:

public class LockFreeStack<T> {

// по классике хранит непосредственно значение и ссылку на следующую Node
private static class Node<T> { ...

private final java.util.concurrent.atomic.AtomicReference<Node<T>> head = new AtomicReference<>();

public void push(T element) {
Node<T> newNode;
Node<T> currentHead;
do {
currentHead = head.get();
newNode = new Node<>(element, currentHead);
} while (!head.compareAndSet(currentHead, newNode));
}

public T pop() {
Node<T> currentHead;
Node<T> nextNode;
do {
currentHead = head.get();
if (currentHead == null) {
return null;
}
nextNode = currentHead.next;
} while (!head.compareAndSet(currentHead, nextNode));
return currentHead.value;
}
}

На medium есть целая статья, которая предлагает более элегантное решение с хвостовой рекурсией на Kotlin.

Раньше давал алгоритмическую задачу, от которой впоследствии отказался. За отведенные 15 минут нужно было нарисовать лестницу заданной высоты N вида:

    |¯
  |¯
|¯

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

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

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

Насобирал с последнего поста по собеседованиям немного вестей с полей.

Коллега пишет:

Есть острое ощущение, что сейчас на скрининге кандидат использовал нейросетку для прохождения собесов: cluely.com
К кому придет на интервью товарищ ... — присмотритесь.

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

Как это проявлялось:

Структура ответа всегда одинаковая: сначала полная хрень, потом по бумажке. Говорили чуть-чуть про кубер, спросил его про сайдкары. Он резко сменил контекст, начал рассказывать про распределенные транзакции. Стал у него уточнять, выяснилось, что он про saga рассказывает. Видать нейросетка ослышалась.

Буквально вчера столкнулся с подобным на скрининге: на первоначальный вопрос в ответ полная ерунда, затем после незначительного уточнения/повторения развернутый подробный ответ. И так не один раз, а буквально через вопрос. На некоторые — вообще не получил ответ при том, что спрашивал вполне себе базу у разработчика со стажем в 5 лет... так в резюме написано, я бумажке верю 😃

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

Вы скажете: "Паранойя!". Возможно, но другой мой коллега пишет:

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

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

Лет, наверное, 5 назад мне очень запомнились два менти. Парень и девушка, которые не имели профильного образования и работали в совершенно не связанных с IT сферах. Они только закончили курсы и хотели получить какой-то опыт собеседований. Каждого из них после первого mock-интервью я отправил собирать офферы. Их ответы были точны и по делу. Практически не было вопросов, на которые они не знали ответ, но даже в этом случае они не сдавались. Это были очень приятные собеседования, о которых я до сих пор помню. Ребята нашли работу в течение двух недель. Да, рынок был другой, но у меня не было сомнений, что работодатели будут бороться за таких специалистов.

А что делать интервьюерам?

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

На самом интервью будем просить включить камеру со второго ракурса и не использовать наушники, как я писал ранее, буду задавать на 80% новый набор вопросов. Вопросы должны быть не в лоб, как, например, "Что такое Index Only Scan?" в контексте анализа плана запроса, а "Чем плох Index Only Scan?". В них по незнанию тяжелее сориентироваться.

Коллеги развивают идею:

Можно задавать вопросы настолько всрато (издалека заходить), что их даже ИИ не разберет.

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

Такой вот он найм сейчас — крутимся как можем 🤩

Все же уже видели ⬆️? В связи с этим:

Идея для стартапа №1
Нужно сделать фейк настолько дип, что задействовано будет все помещение, а видеопотоки будут синхронизироваться на несколько устройств. Причем готовая запись не подойдет — будут просить протереть камеры и покрутиться на стуле💃

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

Идея для стартапа № 2
В связи с этим все большей популярностью будут пользоваться системы независимой оценки кандидатов.

Linkedin и HH (в рамках Национальной системы подтверждения IT-компетенций 🧐) уже предлагают подтвердить свои навыки. Правда, в текущем виде ценность для работодателя такой оценки чуть меньше, чем нулевая.

Как это должно выглядеть НА САМОМ ДЕЛЕ? Кандидат приезжает в локацию, где под наблюдением и с использованием средств РЭБ🪖 будет проходить собеседование по заранее выбранным темам. За достоверность результатов компания отвечает в первую очередь своим именем. Это напоминает сдачу сертификационных экзаменов Oracle, которые в России (как, наверное, и везде) можно было сдать только в тестовых центрах Pearson VUE.

———

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

———

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

Как у вас с рекурсивно заданными типами?

public abstract class Enum<E extends Enum<E>> ...

interface Entity<T extends Еntity<T>> ...

Меня в коде они всегда приводят в замешательство 🧐 На самом деле, это не что иное, как F-bounded Polymorphism. Попробуем вместе разобраться с этим понятием, и какое отражение оно нашло в Java 👉 тык. В пост телеги контент не влез.

Прошёл Легендарную тридцатку!

Последний раз я ходил в трёхнедельный школьно-студенческий поход на Камчатку. Было это более 10 лет назад. В этот раз занетворкался с ребятами из дружественного банка.

Как было круто, можно увидеть на фото. Я же хотел поделиться моим скромным опытом о технической стороне похода.

Все написанное ниже касается только несложных летних горных походов.

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

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

Палатка
Взял свою старую добрую двухместную Freetime Easy Ride. Она относительно легкая (2.2 кг) и простая в установке, но достаточно серьезно потеет ночью и оборудована одним тамбуром. Сейчас я бы взял что-то более легкое, практичное и технологичное. Можно присмотреться, например, к топовым вариантам от Sea To Summit (одноместная на 1,1 кг, двухместная на 1,4 кг).

Коврик и спальный мешок
Классический коврик не брал. Взял у друга надувной матрас. Было очень удобно, но так как не посмотрел его характеристики, то ночью в сочетании с моим спальником было прохладно. Приходилось утеплять его флисками. мысли на этот счёт:
* спальник я бы брал максимально теплый, но в то же время легкий (до 700-800 гр), например, такой. Если жарко, то его можно просто не застегивать;
* коврик дает защиту от проколов и холода надувному матрасу, но достаточно объемный. Можно рассмотреть утепленные матрасы;
* ребята брали обычные коврики, что не так удобно, но в сочетании с тёплыми спальниками работали хорошо;
* учитывайте одежду, в которой будете спать, чтобы она не крала тепло.

Рюкзак
Желательно подобрать в магазине, предварительно нагрузив. Чем больше регулировок, тем больше шанс что-то поправить непосредственно в походе. Если рюкзак очень большой, не под ваш рост, то никакие регулировки не помогут.

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

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

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

У обоих новых ботинок Millet на третий день в зона сгиба носка отошла прорезиненная защита 😐. Обязательно разносите новые ботинки хотя бы несколько дней до похода.

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

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

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

Поэтому подготовил удобный Dockerfile c Postgres и генерацией датасета заданного размера с помощью тулкита TPC–H. Удивительно, но такую задачу как будто никто не решает. Никому не нужно? Или я плохо искал? Буду благодарен, если поделитесь другими подобными проектами, прикреплю их к посту 🙏

А что за TPC-H?

TPC-H — это бенчмарк (по-простому набор тестов), разработанный организацией Transaction Processing Performance Council (TPC) для оценки производительности СУБД, выполняющих аналитические (OLAP) запросы в стиле Decision Support Systems (DSS), как сами их и называют авторы.

Меня интересовал не весь проект TPC-H, а только инструмент генерации данных dbgen. Он генерирует данные для 8 таблиц, связанных между собой. Можно сгенерировать столько данных, сколько укажете в аргументе при сборке образа. Подробнее, как и какие будут генерироваться данные, можно прочитать в четвертой главе спецификации.

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

И всё же, какие есть альтернативы?

1️⃣Есть ряд вариантов, предлагающих заранее сгенеренные синтетические данные заданного размера (обычно небольшого). Например, Pagila. Почему-то тоже не нашел свежий образ / Dockerfile.

2️⃣ Использовать реальные датасеты. Один из примеров — история поездок нью-йоркского такси, когда можно поработать с "живыми" данными. Но опять же придется привести данные к такому виду, чтобы их прожевала ваша БД.