«Менеджеру нужно продолжать кодить»: интервью со Стивеном Чином

Многие Java-разработчики знают Стивена Чина. Кто-то видел его трансляции с Java-мероприятий, кто-то — его интервью с другими известными джавистами, а кто-то — доклады про Java на Raspberry Pi. Да что уж там, в Твиттере он @steveonjava — то есть даже юзернеймом показывает, насколько его жизнь посвящена этому языку.

До недавних пор он работал в Oracle, а теперь перешёл в компанию JFrog. Это может звучать неожиданно: уйти из Oracle, когда твоя жизнь — это Java? Но второе название российским джавистам тоже хорошо знакомо, во многом благодаря работающему там Баруху jbaruch Садогурскому.

Скоро российские разработчики смогут увидеть лично и Стивена, и Баруха на конференции Joker, а пока что Стивен рассказал нам о самых разных вещах, например, таких:

• Чем именно он занимается теперь;
• Как разработчику правильнее становиться менеджером;
• Насколько большим можно сделать кластер из Raspberry Pi (и зачем);
• Жива ли JavaFX;
• Чем Java-активисту полезен мотоцикл.

Олег Чирухин: Компания JFrog занимается CI/CD и прочим, но российским джавистам она особенно хорошо известна тем, что там работает Барух. Вы же его наверняка знаете, так?

Стивен: Да, мы с ним отличные друзья. Я его знал ещё до шляпы!

Олег: Вы теперь «senior director of developer relations», а должность Баруха называется «head of developer advocacy». Что именно за этим кроется?

Стивен: DevRel — это целая куча различных активностей. В том числе это developer advocates — люди вроде меня с Барухом, выступающие на конференциях с докладами. Ещё это мероприятия для разработчиков, общение с людьми на конференциях, создание контента для разработчиков и так далее. В общем, теперь я тоже подключился к этому всему, и мы собираемся увеличить активность в работе с сообществом.

Олег: Судя по вашему профилю в LinkedIn, у вас очень интересная карьера. Вначале вы получили диплом бакалавра по computer science, потом в течение трёх лет занимались менеджментом, затем в течение года — программированием, потом снова менеджментом. Почему у вас были такие зигзаги в карьере? Вообще, насколько разумно для джуниора так часто менять область деятельности?

Стивен: Вполне разумно, именно так всем и надо начинать карьеру! *смеётся*

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

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

Олег: Легко ли сочетать в одном человеке навыки менеджера и программиста?
Ведь это сильно отличающиеся области.

Стивен: Да, но я занимаюсь менеджментом только в тех сферах, в которых я сам разбираюсь. Я знаю, как писать код, как тестировать, как применять методологии Agile, потому что всему этому я научился самостоятельно. Кроме того, я уже несколько лет занимаюсь developer advocacy, так что в этой области у меня теперь тоже появились навыки.

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

Олег: Когда-то у вас была должность «Сhief Agile Methodologist». Боюсь даже предположить, что это должно значить.

Стивен: Ну, у всех у нас в жизни бывали ошибки! *смеётся*

В определённый момент у меня стали очень хорошо получаться Agile-методологии и инфраструктура DevOps. Я стал помогать не только своей команде, но и другим командам в компании, а также стал помогать планировать крупные релизы. Потом я даже написал на Java инструмент для подобного. В компании стали им пользоваться, со временем он развивался, и в итоге благодаря этому мы смогли вырваться из ада таблиц Excel (если оказывались в нём, знаете, какое это ужасное место).

Но всё-таки заниматься методологиями для меня не так интересно, как технологиями. Поэтому в итоге я снова вернулся к прежним делам.

Олег: Я знаю, что вы много работали с JavaFX. Что вас изначально подтолкнуло к этой технологии?

Стивен: Это довольно интересная история. Ещё до того, как вышла JavaFX 1.0, я работал над десктопным фреймворком виджетов. Прототип этого фреймворка я отправил Джошуа Мариначчи (Joshua Marinacci) из Sun, который на тот момент работал евангелистом Java. Лично я с ним знаком не был, хоть и уважал его, поэтому никакого отклика я не ожидал. Но он ответил, сказал, что ему понравилась идея, и предложил попробовать JavaFX, который на тот момент был совершенно вне моего поля зрения. У меня было три дня выходных (из-за праздника), и за эти три дня я переписал свой фреймворк на JavaFX, после чего результат снова отправил Джошуа.

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

Олег: Полностью согласен. Правда, в IntelliJ IDEA по-прежнему используют Swing.

Стивен: Ну, IDEA сама была создана в начале 2000-х. Конечно, есть люди, которые занимаются поддержкой больших приложений с большим количеством легаси на Java2D, и в этом случае, естественно, выбирать не приходится. Но для новых инструментов, по-моему, дико использовать тулкит, которому больше 20 лет.

Олег: Что ожидает JavaFX в будущем? Ведь сейчас она перестала быть частью JDK.

Стивен: Ну, JavaFX остаётся частью проекта OpenJDK. Её убрали из сборки Oracle, но эта сборка всё равно сейчас коммерческая, так что потеря невелика. Что тут можно сказать — пользуйтесь сборками JavaFX от Gluon. Они, кстати, также занимаются мобильным JavaFX, в общем, делают много важного для экосистемы.

Олег: А что сейчас с проектами на JavaFX вроде вашего WidgetFX?

Стивен: Конкретно над WidgetFX работа больше не ведётся, но есть другие проекты, которые поддерживает сообщество. В целом экосистема JavaFX живая. Есть много случаев, в которых JavaFX незаменима и позволяет писать вещи, которые трудно воспроизвести на JavaScript.

Олег: У вас есть проект «Nighthacking» — можете рассказать о нём?

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

Для их публикации в интернете я пользовался разными сервисами, но в конечном итоге остановил свой выбор на Periscope, который мне подсказал Крис Тэлингер (Chris Thalinger). Это отличная платформа, позволяющая публиковать интервью и помогающая людям узнавать о новых технологиях.

Кроме того, у меня и Баруха появилась мысль создать программу в аналогичном формате по тематике DevOps. Мы планируем запустить её на вашей конференции Joker, она будет называться DevOps Speakeasy.

Олег: Это было бы здорово. Насколько я знаю, вы путешествовали на мотоцикле с ещё одним знакомым нам Java-разработчиком, Себастьяном Дашнером?

Стивен: Да, мы с ним объездили весь мир, были в Европе, в Японии. На первый взгляд может показаться, что мотоцикл — странное средство транспорта, но когда нужно за две недели побывать в десятке различных юзер-групп в разных городах, как мы делали в Японии, мотоцикл очень эффективен.

Олег: Раз вы видели много джавовских юзер-групп по всему миру — есть ли культурные различия между группами в разных частях света?

Стивен: Думаю, сходств больше, чем отличий. Чаще всего эти группы существуют на средства самих гиков, которые их организуют, то есть функционируют на добровольных началах. Я и сам, руководя юзер-группой в области залива Сан-Франциско, ощущал это способом помочь другим так же, как в своё время помогли мне. Юзер-группы позволяют делиться знанием, мне очень нравится в них ходить, в них пульсирует дух сообщества. Для developer advocates лучше всего заниматься именно юзер-группами.

Олег: У вас много видео по робототехнике, Raspberry Pi и прочему. Занимаетесь ли вы этим профессионально, или это скорее хобби?

Стивен: Робототехникой я начал заниматься по работе, потому что в Oracle у нас были проекты, связанные с Java для Raspberry Pi и других встроенных платформ. А потом я увидел, что на Raspberry Pi очень удобно учить детей программированию. И я этим довольно много занимался, проводил семинары для детей на различных конференциях. Раньше на этих семинарах мне помогала моя дочь, сейчас она такие же семинары проводит сама. Она подключает встроенные датчики (например, датчики света, акселерометры) к Raspberry Pi, демонстрирует очень простые примеры кода с этими датчиками, и таким образом учит детей. Благодаря этим урокам в будущем может появиться новое поколение программистов, у которых интерес к коду возник очень рано.

Олег: Может, когда-нибудь и она выступит на Joker. Является ли Raspberry Pi по-прежнему лучшей платформой для робототехники? Говорят, что новые версии очень сильно перегреваются, вспоминаются твиты Алексея Шипилёва. Хотя страшно представить, каким нагрузкам подвергает их Шипилёв, так что расскажите о более «нормальном» использовании.



Стивен: Для тех, кто занимается этим делом в качестве хобби, преимущество Raspberry Pi в том, что что систему очень просто поднять: подключить её к USB-разъёму, вставить обычную SD-карту, на всё про всё уходит полчаса. Как я уже говорил, в Oracle я работал в команде, которая занималась коммерческими встроенными системами — правда, сам я там занимался developer advocacy, но вокруг меня было много людей, тестировавших и настраивавших различные встроенные платформы. Так вот, чтобы запустить самые простые вещи на коммерческой системе, требовалось потратить не одну неделю.

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

Пользуясь теми же технологиями, фонд Raspberry Pi в Великобритании создал платформу, которой легко пользоваться в образовании, она проста, эффективна, и у неё отличная экосистема. В особенности она хороша для тех, кто хочет в свободное время сделать какой-нибудь простой проект — кстати сказать, я написал книгу про Java и Raspberry Pi.

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

Олег: Изменилась ли робототехническая сторона Raspberry Pi с годами? Я этим специально не занимался, но, насколько я знаю, в Java по умолчанию есть GPIO. Существуют ли какие-либо фреймворки, или, возможно, производители железа сами предоставляют поддержку?

Стивен: Есть множество финансируемых сообществом проектов, например, Robo4J: это платформа для робототехники в IOT на основе Raspberry Pi. Другой отличный проект с доступом к GPIO — Pi4J. Он использует ту же библиотеку на С, что и все остальные, WiringPi, но поверх неё он предоставляет очень эффективную оболочку на Java, которая обладает отличной производительностью.

Я проводил низкоуровневые опросы GPIO для симуляции аналоговых пинов. Обычно в Raspberry Pi это очень трудно делать, поскольку она не является операционной системой реального времени. Обёртка на Java добавляет паузы для JIT-компиляции и тому подобное. Но при помощи низкоуровневой библиотеки Pie4J мне удалось использовать аналоговый датчик расстояния на контроллере на Java. В общем, с Raspberry Pi можно сделать много интересных вещей напрямую из Java. Ну и, конечно, помимо этого есть большая экосистема на C, Python и прочем.

Олег: Я видел, что люди создают кластеры из Raspberry Pi. Имеет ли это какое-либо практическое значение?

Стивен: На Oracle Code One скоро пройдёт презентация проекта, в котором я участвовал, это кластер из 1024 Raspberry Pi.

Как вы понимаете, собрать кластер из 10 или 20 Pi несложно, хоть и займёт порядочное количество времени. Если же в кластере больше 1000 Pi, возникают проблемы с энергопотреблением, с загрузкой с SD карты или по сети, с правильной топологией сети и инфраструктурой — сообщение между узлами сети не должно стать узким местом при вычислениях. Кроме того, охлаждение такого количества Pi в одном помещении — задача нетривиальная. Но когда мы все эти трудности преодолеем, это будет самый большой кластер из Raspberry Pi в мире. Кстати говоря, он будет в форме синей британской полицейской телефонной будки — как из сами знаете какого научно-фантастического телесериала. Надеюсь, мы не нарушили ничьи авторские права.

Такого рода кластер — это словно бы у вас игрушечная железная дорога с поездами, но она при этом моделирует полномасштабную железнодорожную сеть. По такой модели никогда не сможет пройти реальный поезд, и та же история здесь: кластер из 1024 Raspberry Pi не будет мощнее даже одной современной GPU с несколькими сотнями ядер, но для симуляции поведения крупных систем этот кластер полезен. Кроме того, он отлично подходит для некоторых очень сильно распараллеленных задач. Но очень часто сеть или скорость чтения и записи SD-карт становятся узким местом. А для сложных алгоритмов именно именно эти вещи являются реальными ограничениями.

Олег: Да, и этот кластер можно использовать как тренировочную модель, можно попробовать развернуть что-нибудь с помощью Kubernetes, Docker и каких-нибудь продуктов JFrog.

Стивен: Почему бы и нет! *смеётся*

Олег: Вы — бывший работник Oracle, и давно занимаетесь Java. Каким вы видите будущее языка? Может, оно за GraalVM, Valhalla или чем-то подобным?

Стивен: С релизами Java в ближайшем будущем должно появиться много интересных технологий. Наиболее важных две, одну из них вы уже назвали, это GraalVM. Это компиляторная инфраструктура следующего поколения. Речь идёт о написанном на Java и для Java компиляторе, который может работать с несколькими языками, и который значительно проще оптимизировать, чем обычный HotSpot. Думаю, в долгосрочной перспективе этот компилятор превысит по производительности другие компиляторы JVM и станет важной частью архитектуры Java.

Существенное преимущество GraalVM — AOT-компиляция. Она в особенности полезна для мобильных и встроенных устройств. Код компилируется заранее, бинарник разворачивается на устройстве, и время запуска и требуемая память сравнимы с кодом на С, Go и других языках. Кроме того, AOT-компиляция позволяет значительно эффективнее работать с микросервисами или бессерверной архитектурой, где много процессов выполняются одновременно на нескольких серверах или в разных тредах на одной машине. При необходимости можно запускать отдельную JVM для каждого контейнера Docker или виртуальной среды. В общем, для вещей вроде serverless на Java сегодня GraalVM стал почти незаменим.

Другая интересная новая технология, над которой работает команда JVM — это Fibers. Они позволяют создавать приложения Java по традиционной схеме, с тредами, но при этом иметь такую же производительность, как если бы использовался асинхронный фреймворк, например, Vert.x, Node.js или какой-либо другой.

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

Олег: На самом деле, в OpenJDK уже сделаны некоторые изменения, подготавливающие приход Loom. Например, в JEP 353: Reimplement the Legacy Socket API.

Стивен: Насколько я знаю, сейчас реализуется основная инфраструктура для Fibers и Loom, но она не будет открытой для пользователей, потому что разработчики не хотят, чтобы люди работали с ними напрямую. Так что сейчас идёт работа над API для Fibers.

Олег: Вы используете последние версии Java?

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

Крупным организациям тяжелее всего при переходе через рубеж Java 9. Тогда появилась модульность, и принесла с собой много других изменений. Часто многие фреймворки и технологии, от которых зависит проект, ещё не перешли на Java 9 и более поздние версии, что также затрудняет переход. Если же этот рубеж пройден, то дальше обновляться значительно проще, так как следующие версии (10, 11, 12 и, если я ничего не перепутал, в скором времени 13) довольно похожи. С точки зрения совместимости наибольшее изменение — это модульность.

Олег: И уход Java Enterprise.

Стивен: Да.

Олег: Напоследок можете рассказать что-то про ваш новый доклад, с которым приезжаете к нам на Joker?

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

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

Я очень рад буду приехать на Joker. В Санкт-Петербурге я уже был, но на этой конференции — ещё ни разу, хотя слышал о ней пока только хорошее. Там также будет выступать и Барух — и, как уже упомянул, мы с ним на конференции будем снимать видео в рамках нашей программы DevOps Speakeasy. Про Баруха я слышал, что он у вас своего рода рок-звезда.

Олег: Это точно. Знаете, есть обычные фильмы, а есть боевики. Так вот, у Баруха — доклады-боевики! Спасибо за интервью, и до скорой встречи в Санкт-Петербурге.