Среди наших интервью со спикерами JPoint 2017 было одно исключение: хотя Глеб Смирнов присутствовал на конференции без доклада, мы все равно решили поговорить и с ним. Во-первых, он выступал на JPoint ещё в 2014-м и в 2015-м — настоящий ветеран. А во-вторых, как раз интересно было получить картинку с другого ракурса. Когда не надо заниматься собственным докладом, на конференции можно быть более расслабленным, и Глеб соответствовал этому, расхаживая там в тапочках.
Что хочется добавить к этому интервью спустя год? Во-первых, вскоре после JPoint Глеб выступил на митапе с темой «Как всё испортить своим Java-агентом», так что спикерство он не забросил. А во-вторых, хотя на приближающемся JPoint 2018 доклада от него не будет, в этом случае Глеб участвует иначе: входит в Программный Комитет конференции.
Руслан: В нашей студии Глеб Смирнов из компании Plumbr. Если вы сейчас откроете программу и начнете судорожно искать его, то не найдёте. Глеб, ты в последний раз выступал у нас пару лет назад, но вижу тебя на каждой нашей Java-конференции, ты активно участвуешь в жизни сообщества. Зачем именно тебе это?
Глеб: Сделать добрые дела можно не только докладом. Очень полезно приходить сюда просто пообщаться с людьми и обменяться с ними идеями. Как помочь им с какой-то их проблемой или задачей, так и получить что-то от них. Или донести до людей в кулуарном общении какие-то полезные мысли.
Например, за последнюю неделю я человек 30 убедил, что нужно просто мониторить продакшн. До этого никто из них вообще это не делал! Не важно, Plumbr они будут использовать или не Plumbr, это просто хорошее дело, по дефолту люди его не делают. В целом, можно узнать очень много нового не на докладах.
Евгений: Когда оказываешься как зритель, а не как спикер, можно как следует посмотреть чужие доклады. Уже увидел что-то интересное для себя?
Глеб: Да, здесь очень много интересных докладов, я этим очень доволен. Наиболее интересный для меня ещё не состоялся — это доклад Володи Долженко про hashСode. Мне в нём очень нравится методология, там прослеживается от начала до конца конкретный научный метод в применении к JVM. Я смотрел его превью и был жутко доволен.
Руслан: Про научный метод: есть дискуссия, даже холиваром можно назвать, должен ли программист знать матан. Как ты считаешь?
Глеб: Именно матан — это уже довольно узко специализированная область. Скорее, программист должен действовать рационально и логично. Для этого хорошо помогает математика, но, в принципе, не только. Нужно быть здравомыслящим человеком. Матан — это полезный плюс, мне кажется, что если его знать, то это здорово. Если ты способен разобраться в том, как там устроен спринг, то наверно ты способен посчитать интеграл. Наверное, не сложно.
Руслан: Но при этом многие говорят «чтобы CRUD-приложения в энтерпрайзе пилить, ваша математика вообще не нужна». Насколько понимаю, ты математическим аппаратом в какой-то мере владеешь, тебе как это в жизни помогает вообще?
Глеб: Может быть, кто-нибудь заметил — я здесь, помимо других добрых дел, активно распространяю знание теоремы Байеса. Я хожу от одного человека к другому и показываю, как она может помочь. Это одна из наиболее полезных штук, которую можно применить в том числе программисту. Вот вы разрабатываете систему и хотите минимизировать риск того, что с ней что-то плохое случится: она упадёт, данные потеряются или что-то еще. Вы должны действовать, а не думать: «А наверное, может быть, не упадёт». Нет, вам нужно взять в руки карандаш, взять или измерить конкретные числа и вы сможете посчитать вероятности. Теория вероятности — одна из важнейших штук, которая всем программистам нужна.
Евгений: Вот ещё про доклады. Ты причастен к небольшой книжке по GC от Plumbr — в связи с этим, наверное, доклад Шипилёва про Shenandoah был особенно интересен?
Глеб: Да, доклад про Shenandoah был действительно интересным. С практической точки зрения именно для Plumbr пока что не очень, потому что он еще далёк от того, чтобы быть у наших клиентов. Но да, у нас есть маленькая книжка Java Garbage Collection Handbook, в которой мы рассказываем про Garbage Collector, пара абзацев там посвящена Shenandoah, но его там мало. И вполне возможно, что после сегодняшнего доклада и общения с Алексеем мы дополним этот раздел.
Руслан: Что-нибудь еще из хороших дел ты хотел бы упомянуть?
Глеб: Да, конечно. Вчера был отличный закрывающий кейноут от Алексея Савватеева, который рассказывал про теорию игр, про математику, про установление правил. Недавно была еще интересная публикация от DeepMind. Суть в том, что, ребята, кооперация — это оптимально. Делайте это, помогайте друг другу, делайте добрые дела. Если вы можете потратить 5 минут на то, чтобы кому то сохранить 10 часов, возьмите и сделайте это, а потом кто нибудь другой сохранит вам 10 часов, и все будут счастливы.
Руслан: Савватеев, показывал, что эта история работает не всегда так, как мы ожидаем. Не боишься ли ты, что будешь кому-то помогать, а в ответ ничего не получать?
Глеб: Так неизбежно будет, так будет постоянно происходить, потому что эгоизм зачастую удобнее, но если все будут кооперироваться, то постепенно можно построить правила игры так, чтобы это было оптимальным, а если все к этому будут привыкать, тогда тоже можно будет получить от этого профит. Мне часто люди просто случайно берут и помогают, а я только рад.
Евгений: Возвращаясь к теме математики. Недавно был масштабный холивар о том, правильно ли поступают IT-компании, терзающие на собеседованиях вопросами по алгоритмам. Какая твоя позиция в этом холиваре?
Глеб: Тут позиция довольно простая. В первую очередь, важно не знание алгоритмов, а способность алгоритмически мыслить. Она крайне важна для разработчика, но это лишь один из факторов. Важно, например, также проверить немного другое, хоть банальный soft skills. Способен ли человек адекватно говорить и обмениваться информацией с другим человеком? Чтобы не было так, что ему дали задачу, вроде он неделю над ней работает, а делает совершенно другое. Мне кажется, это важнее проверить, чем способность развернуть двоичное дерево.
Но в большинстве случаев, когда я провожу собеседования и даю алгоритмические задачки, мне важно увидеть, как человек думает, что бы он вслух сказал: «Мне в этой задаче нужно сделать то-то, наверное, логично, что у меня к алгоритму должны быть такие-то требования» — и просто послушать, как человек рассуждает. Это то, что человек будет делать во время работы, и это надо проверять.
Руслан: Правда в том, что обычно задачи на алгоритмы проверяют не знание этого алгоритма. В идеале, кандидат не должен знать ответ, а должен показывать, что он двигается в правильном направлении. В этом холиваре я тоже считаю, что вопросы про алгоритмы точно должны быть. Другой вопрос, какие критерии к ним должны выставляться. Если вы ждёте ответы в стиле цитат из учебников, наверное, вы делаете что-то не так.
Глеб: Да, согласен.
Евгений: Еще одна холиварная тема. Вчера, сидя тут, Алексей Шипилёв говорил, что значимость перформанса переоценивают. И раз ты пришёл сюда нести благую весть, что надо использовать перформанс-мониторинг: а точно ли всем надо?
Глеб: Ну я не уверен, что именно сказал Алексей, но предполагаю, что он мог иметь в виду следующее: люди очень любят делать перформанс ради перформанса, они забывают, что программистам платят не за то, что они пишут код, а за то, что они решают бизнес-задачу. Точно так же программа должна удовлетворять бизнес требованиям, а не быть быстрой. Например, очень частая ситуация: сделали новый релиз, админ вдруг смотрит, что после релиза ресурсы CPU потребляются в два раза больше, перформанс просадили. Откатывают релиз, а нагрузка на CPU не уменьшается, что такое? Оказывается, что релиз был хороший, просто пришли новые пользователи и нагрузили сайт сильнее, а тот, кто делает перформанс ради перформанса, этого не заметил.
В первую очередь надо концентрироваться на том, чтобы приложение работало корректно и удовлетворяло пользователей. Если эти требования выполнены, то тогда ничего не надо оптимизировать. Однако для того, чтобы понять, счастливы ли ваши пользователи, действительно ли ваше приложение работает корректно, тогда вам нужен перформанс, scalability, мониторинг в продакшене, без этого никак. Если вы не понимаете, что у вас происходит в продакшене, то тогда вам и оптимизировать нечего.
Руслан: Кстати, ты слушал вчера доклад Саши Гольдштейна? Он про туже саму историю рассказывал. И, кстати, про инструмент он рассказывал бесплатный.
Глеб: У Саши вообще отличный доклад, мне очень понравился, единственный момент, он рассказывал об этом не со стороны мониторинга, а troubleshooting-а. То есть если у вас уже что-то сломалось, и вы знаете, что есть проблема, и знаете примерно где она, то тогда можно взять все то, что Саша рассказывал, оно отлично поможет понять в чем дело и починить. Но нужно сначала узнать, что проблема есть. Бывают такие истории, что сайт годами работает медленно, об этом никто не знает, добавляют мониторинг и думают: «Ё-моё, сколько мы бабла потеряли на этом». Или всякие оптимизации, типо SEO и прочее: “Сейчас мы сделаем 10 экспериментов главной страницы, подвинув кнопку на два пикселя”, — а у них эта страница открывается 30 секунд.
Руслан: Да, вся боль в бессмысленных и беспощадных экспериментах. Спасибо, Глеб, за приятную беседу!
Глеб СмирновСпециалист по разработке высокопроизводительных отказоустойчивых приложений, в том числе платформ для высокочастотной торговли. В свободное время любит поковыряться в исходниках OpenJDK и потворить с ними всяческое непотребство. Автор нескольких популярных статей о многопоточности. Некоторое время проработал в петербургских подразделениях Яндекса и центра разработки Deutsche Bank. В данный момент странствует по миру и работает в Plumbr, где разрабатывает решения для мониторинга производительности и надёжности приложений @gvsmirnov
