Барух Садогурский, JFrog: Developer Advocate, Java 9 и мировое господство Kotlin (но вы лучше посмотрите на Groovy)


В начале ноября в Киеве в шестой раз пройдет конференция JavaDay. Мы пообщались с ее постоянным спикером Барухом jbaruch Садогурским — Developer Advocate в JFrog. За время беседы мы успели обсудить:

— Особенности работы Developer Advocate: почему он не должен продвигать продукты работодателя
— Java 9 и частоте релизов Java на примере маршруток и поездов
— Kotlin и его пути к мировому господству



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


Твоя должность звучит как  Developer Advocate? Насколько я понимаю, это некий аналог евангелиста, верно?
Да, аналог евангелиста, но не совсем. Само понятие «евангелизм» несет религиозную окраску в контексте донесения до народа истины о едином правильном решении. Это не то, что я делаю. По крайней мере, мне бы хотелось в это верить. Евангелист это тот, кто рассказывает, как правильно сделать. Advocate в английском, хоть изначально и имеет не юридическое значение, как в русском, но подразумевает защиту, представление интересов. В этом и разница.

Защитник интересов разработчиков. Это предполагает понимание пожеланий разработчиков, коммьюнити — и донесение их внутри компании?
Это одно из направлений. Второе, не менее важное, — помощь разработчикам в решении определенных проблем даже без использования (хотя, конечно, лучше с использованием) продуктов компании, которая платит мне зарплату. Я могу сказать: «Ребята, используйте Artifactory, потому что он поможет решить ваши проблемы.» А иногда могу сказать: «Лучше не используйте — здесь вам он не поможет.» За оба варианта меня похвалят, но, конечно, лучше, когда я могу использовать первый.

Где тогда грань между продвижением продукта компании и профессиональной работой Developer Advocate?
Дело в том, насколько ты понимаешь нужды тех, с кем работаешь. Насколько ты в состоянии помочь решить их проблемы, ставя их интерес выше интересов продукта, который продвигаешь. Грубо говоря, если ты в состоянии сказать: не берите наш продукт — он вам сейчас не поможет, тогда ты профессионал Developer Relations. А если ты все равно продвигаешь продукт, потому что ты или не слушал, не понял разработчика — это непрофессионально.

Должен ли Developer Advocate быть одновременно еще и разработчиком? Например, чтобы держать себя в форме и понимать потребности комьюнити.
Обязательно. И дело не в форме. Без написания кода ты не поймешь потребности людей — и не выполнишь свои обязанности. Обязательно нужно писать код, понимать технологии, «играть» с ними. Да и это просто интересно и приятно.

Какой должен быть баланс между маркетинговой и девелоперской составляющими? Как часто ты кодишь?
Возвращаясь к сути работы, маркетинг не является частью developer relations. Developer Advocate в компании чаще всего очень мало. Сейчас в JFrog работает 250 человек и advocate всего один. Хотя скоро нас будет трое. Но для компании в 250 человек даже этого мало. Поэтому под эту функцию обычно не выделяют отдел, а присоединяют к другому подразделению.

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

В том, что касается соотношения relations и development, идеальным соотношением было бы 50/50. К сожалению, народу мало — работы много, поэтому техническую часть приходится «добирать» в нерабочее время. К примеру, на JavaDay я еду в том числе для того, чтобы послушать последние новости, опробовать на себе новые технологии. Подкаст «Разбор полетов» преследует для меня те же цели. Я не стараюсь ничего продвигать там по работе, а наоборот — учиться и слушать, чтобы оставаться в курсе событий. Очень надеюсь, что когда я наберу команду, у меня наконец будет время заниматься этим в рабочее время.

То есть, ты любишь ездить и выступать. Но и код писать тоже любишь?
Мне очень нравится и ездить, и писать код. Если бы я мог делать и то, и другое в соотношении 50/50… У меня и так идеальная работа, но она была бы немножко идеальней.



Профессионализм Developer Relations — быть честным с собой. Но работодатель наверняка ставит некие KPI? Как измеряется эффективности работы?
Влияние померять можно, но это очень непросто и дорого. На раннем этапе компании не готовы вкладывать деньги в измерение влияния специалиста по Developer Relations на комьюнити. В многих компаниях влияние либо никак не меряют, или опираются на очень простые и наивные метрики вроде количества фолловеров в Twitter или людей, посетивших доклад. Но то, сколько человек пришло на выступление, зависит от двух вещей: насколько у доклада  скандальное название, и кто выступал параллельно. Если со мной в параллели были звезды первой величины, вроде тех, которые уже висят на сайте JavaDay, то ко мне никто не придет даже на потрясающий доклад. Это пример KPI, которые не имеют никакого смысла.

Какие KPI действительно важны? Насколько мой доклад зацепил людей? Давайте рассмотрим на примере Егора Бугаенко. Его доклады очень «цепляют» людей. Это хорошо или плохо? Его Developer Relations от этого улучшается или ухудшается? Егор выступает ради найма. В этом случае все просто: если три человека после его доклада пришли к нему на работу, значит доклад был хороший. Неважно, что еще 100 человек могли быть потенциально недовольны докладом.

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

Тебя снова утвердили в качестве спикера на JavaOne. С чем ты будешь выступать?
Там еще не пришли ответы по всем моих докладам, поскольку у меня большинство докладов все-таки касаются DevOps. Я рассчитываю, что туда примут достаточно много моих технологичных докладов, например про Docker. На основной поток по Java пока приняли один доклад о голосовых пользовательских интерфейсах. Сделаем один из двух наших любимых форматов: Alexa vs Google Home. Мы будем писать для них некое расширение, и в процессе будем сравнивать те решения, которые приняли Amazon и Google в контексте дизайна и интеграции для сторонних расширений.

В июле ты вошел в список Top 20 Java Influencers 2017 года. Насколько значимы попадания в такие рейтинги для Developer Advocate? Почему ты в него попал, как думаешь?
В прошлом году организаторы впервые сделали этот рейтинг,  и мы — те кто туда не попал — жутко тролили тех, кто там оказался. Дело в том, что рейтинг основан как раз на тех бессмысленных метриках, о которых мы говорили ранее. Ребята просто взяли Klout — платформу, которая строит рейтинги влияния в соцсетях на основе взаимодействия пользователей. Но, на самом деле, платформа достаточно наивна и, как я говорил, влияние все-таки сложно измерять. Но в этом году я туда попал! И все, Klout сразу — серьезнейший и правдивейший инструмент измерения влияния над умами! (Шучу конечно. Это мелочь, но но приятно).

Oracle недавно сократил всех евангелистов. Ему-то наверняка хватило денег, чтобы измерить их эффективность?
Отличный показатель того, напрасно их сократили или нет, это знаешь ли ты их имена. Если читаешь новость о том, что уволили евангелистов, а ты про них никогда не слышал, значит специалисты из них были так себе. В случае с Oracle были как и известные люди, как Саймон Риттер — так и не очень. Их сокращение никакого ущерба Java или компании не нанесли.

«Сейчас уже можно говорить об очень многих позитивных сторонах Java 9»


Не думаешь, что теперь некому продвигать Java 9, которая пока не очень популярна?
Ответ двоякий. Никакой Developer Relations не сможет продвинуть плохой продукт. Если люди понимают, что то, что будет в «девятке», им не нравится, то никто не сможет их переубедить. Год назад релиз был более чем проблематичен. Если бы я работал в Oracle на позиции Developer Advocate, то я бы критиковал, по крайней мере, внутренне, эти решения.
Сейчас ситуация немного изменилась. Oracle заставили поменять концепцию, отказаться от агрессивного продвижения модулей, которые будут в девятке «под капотом», а пересаживание на них всего сообщества перенеслось в направлении Java 10. Это делает «девятку» достаточно безобидным апдейтом. Так из ситуации «о нет, я не буду апдейтиться, потому что оно все сломает» мы перешли в ситуацию «можно и проапдейтиться — наверное, там есть какие-то ништяки». И при таком положении дел, отсутствие Developer Relations в Oracle плохо влияет на Java. Уже не надо защищать модулярность, но нужно раскрыть те преимущества, которые в новом релизе есть — и не всем очевидны.

Давай представим, что Барух у Oracle на зарплате. Ты бы продвигал Java 9? Что именно хотел бы донести разработчикам?
Да, безусловно, сейчас уже можно говорить об очень многих позитивных сторонах Java 9. Самая большая фича, которая вызывала наибольшее количество дебатов и отторжения — это Jigsaw. Его  предыдущая реинкарнация обещала все сломать, но сейчас ее сняли с повестки дня. Почти все, что работает в Java 8, будет работать почти без изменений и в «девятке». Поэтому можно говорить о других фичах.
Например, есть новинки в синтаксисе языка — incubator projects — которые позволят попробовать некоторые вещи, нацеленные на 10-ку и дальше, вроде нового HttpClient. Да, это уже не будет такой гигантский релиз как 5-ка или 8-ка. Java 9 будет более минорным стабилизирующим релизом, как 7-ка. Но в ней есть о чем говорить — и есть причины предлагать проапдейтиться.

Насколько такое промедление и адаптация вредят развитию языка? У Oracle же была идея про сокращение циклов разработки, чтобы выпускать новые версии не раз в пятилетку, а чаще.
Да, сейчас идет дискуссия о том, должны ли релизы Java быть «маршрутками» или «поездами». «Маршрутка» выходит, когда она заполнена. То есть, существует определенный набор фич, которые запланированы в конкретном релизе. Он выйдет, когда все фичи будут готовы — маршрутка заполнится. «Поезд» же выходит по расписанию: кто успел – уехал, кто нет – ждет следующего поезда. До сих пор релизы Java были «маршруткой». «Отправление» Java 9 постоянно откладывалось, потому что все ждали готовности модулей.
Сейчас в Oracle происходит смещение в сторону «поезда» с назначенной датой релиза. Это, скорее всего, приведет нас к релизам «через один», когда за крупным будет следовать более «косметический». То есть, если следующая фаза модулей (та самая, которая всем все сломает), войдет в «десятку», а в Java 11, скорее всего, кардинальных изменений не будет. Просто не успеют написать.

А ты за «маршрутки» или за «поезда»?
Мне кажется, что «поезда» правильней. Такой подход намного уменьшит стресс project owners Oracle. В случае «маршрутки» они должны нестись сломя голову, идти на компромиссы в качестве, но успеть к релизу — или быть виноватыми в том, что он снова откладывается.
Думаю, как раз с этой проблемой столкнулась Java 8. Она, мягко говоря, была проблематичной с точки зрения качества и в плане багов, и документации, и design decisions. Хотя Java остается более стабильной, чем многие другие языки (даже на стабильном JVM), по стандартам Java «восьмерка» была на удивление сырой. Вероятно, давление успеть «заполнить маршрутку» и было тому причиной. В случае с регулярными релизами (не успели к этому — выйдет в следующем) такой проблемы, скорее всего, удастся избежать.

А может Java развиваться по принципу continuous delivery?
Я очень сомневаюсь, потому что не стоит забывать о том, с какой платформой мы имеем дело. Она взрослая. На нее полагаются много консервативных enterprise-клиентов. Апгрейды у них не быстрые, а постоянный выпуск новых версий создает некоторое давление. «Вышло уже три версии, а мы все еще не апдейтились!» Они к такому не готовы. Поэтому, делать continuous delivery билдов для разработчиков — возможно. Но очень сомневаюсь, что long term support-версии имеет смысл выкладывать чаще, чем раз в год.

Мы поговорили про частоту релизов. Давай теперь про качество. Чего не хватает в Java? Чтобы ты добавил в следующих крупных релизах?
Об этом, конечно, можно говорить бесконечно. Существует масса языковых фич, которых нет в Java потому, что так сложилось исторически или так задумано. Если говорить про то, что бы порадовало конкретно меня, то это properties, generics без erasure и, наверное, type inference. Встроенный immutability, наверное, был бы тоже очень неплохим вариантом. Короче говоря, если хотите узнать, как я хочу, чтобы выглядела Java, посмотрите на Groovy.

«У Kotlin есть хорошая стартовая позиция для завоевания мира. Она называется JetBrains»


А как на счет Kotlin? Почему сейчас все повально о нем говорят?
Во-первых, когда о тебе говорят на Google I/O, это явно способствует популярности. Кроме того, Kotlin — хороший язык. В нем очень много вещей, взятых из других языков и правильно имплементированных. Хотя, конечно, как мы все знаем, популярность языка зависит от бороды его автора (поглаживает бороду). Но, если серьезно, зависит она и от возможности продвижения и популяризации. Какой-нибудь Smalltalk, который все считают образцом ООП, не взлетел по совершенно необъективным причинам.

У Kotlin сейчас есть хорошая стартовая позиция для завоевания мира. Она называется JetBrains, которая благодаря IntelliJ IDEA пользуется огромной популярностью и уважением среди разработчиков. Когда мы думаем о JetBrains, мы представляем себе классные продукты, которые сделаны на хорошем технологическом уровне. Помимо этого, их команда вместо того, чтобы гнаться за прибылями, делает то, что считает нужным (по крайней мере, они хотят, чтобы мы так считали). Это такая компания мечты.

Такой запас доверия отображается на самом языке. «О, Kotlin сделали в JetBrains – значит это что-то хорошее!». А потом ты смотришь и оказывается, что это действительно что-то хорошее. Это заметили разработчики после Google I/O, который создал волну хайпа. Тем более, что если ты не пишешь для Android на Kotlin, значит ты кодишь на какой-то Java 6. Боль и мучение.

А чем Kotlin так хорош? В чем его преимущества перед Java?
У Kotlin много хороших черт из других языков. Более удобный и правильный синтаксис, который уменьшает количество boilerplate. К примеру, POGOs можно создавать с намного меньшим количеством кода. В нем не нужны никакие геттеры, сеттеры. Прямо Groovy какой-то!
Одна из самых серьезных фич это Null Safety. Это преимущество, например, над Groovy. В общем,  способов выстрелить себе в ногу во всем, что касается nullability, в Kotlin намного меньше. Шесть лет дизайна умными людьми не проходят даром.

А модные штуки вроде реактивного программирования там заложены?
В 138–ом выпуске «Разбора полетов» мы говорили с Ромой Елизаровым, который как раз пишет реактивную библиотеку для Kotlin. Язык сделан так, что библиотеки вроде RX очень легко и удобно подключать нативно. Как только ее подключаешь, она очень гармонично вписывается в синтаксис и можно с ней работать как будто это было заложено в языке.

Стоит ли сейчас его учить?
Всегда стоит учить новый язык – это прекрасная возможность расширить свои горизонты, стать лучшим программистом, неважно на чем ты уже кодишь. Даже если ты работаешь в традиционном банке, где в ближайшие десятилетия ничего не поменяется, учить Kotlin стоит просто ради профессионального развития. Это твоя работа как разработчика.
Но кроме того, если искать карьерные возможности, Kotlin – интересная ставка. Это не означает 100% вероятность, что она «выстрелит» и твоя следующая работа будет именно на Kotlin. С другой стороны, как учил нас Талеб – попытка не пытка! — а вдруг еще и «выстрелит»?

У Kotlin есть хороший задел на Android, но насколько он может конкурировать с Java в enterprise-сегменте?
На сегодняшний день отрыв у Java гигантский. В ближайшее время его не перекрыть. Мне кажется, что и целевые аудитории немного разные. Мы говорили про банки и госструктуры, которые любят Java за ее стабильность и огромную корпорацию, которая за ней стоит. Они не поменяют сегодня Java на Kotlin просто потому, что каким-то программистам удобнее писать код. Это очень долгий процесс, который у Java занял 15 лет. Чтоб сменить Java в этом сегменте, другому языку потребуется раз в пять больше. Более динамичные компании, стартапы, для которых гораздо важнее качество и количество релизов, а не какая-то стабильность, и которые легче идут на перемены, намного быстрее воспримут язык вроде Kotlin.
В банках же уверены, что Java никуда не денется, будет долго поддерживаться, разработчиков на Java всегда можно будет найти, а следующая ее версия будет backwards compatible и им не придется апгрейдиться каждые два месяца. Они работают с поставщиком, который понимает их нужды.

Мне это напомнило пост, где парень брал интервью у своей матери. Она последние двадцать с лишним лет работает COBOL-разработчиком в банке. Сейчас такие разработчики очень дорого стоят, а банк не может позволить себе перейти на что-то другое, поскольку им нужен uptime 24/7.
На самом деле, они не могут позволить перестроить не потому, что у них нет времени поменять сервера. Это неправда. Они не могут позволить себе этого, потому что миллионы строк кода написаны на COBOL. Гораздо дешевле платить COBOL-разработчикам больше, чем получает средний разработчик, чем переписывать все эти системы на других языках.
И все-таки они переписывают. Думаю, в 2017 году в банковских системах намного больше Java, чем COBOL. Да, это многолетние проекты, которые делают с параллельной поддержкой кода на COBOL, но в итоге смена происходит. А через лет 50 Java будет новым COBOL. Это очевидно, неминуемо и, наверное, естественно.




К сожалению, не доступен сервер mySQL