— Есть несколько тем, которые можно обсудить. Во-первых, ты выступаешь на Joker с докладом. Во-вторых, ты активный участник сообщества, постоянно что-то делаешь. В-третьих, ты постоянно ходишь на наши конференции и почему-то считаешь, что это хорошо.
— По поводу того, что я участник сообщества. Я, как и большинство людей, страдаю синдромом самозванца, у меня нет ощущения, что я много чего полезного делаю, особенно для Java-сообщества, особенно в последнее время. Последнее, что я сделал полезного для сообщества — мы с ребятами написали клёвую библиотеку для Spring, которая называется spring-flow-state-machine, которая позволяет управлять состояниями объектов в приложении. Она маленькая и удобная.
— Это та самая библиотека, которая сейчас пиарится на главной Спринга?
— Нет, наверное, там Spring Statemachine, и она дико убогая: она очень плохо написана, очень странно работает и делает совсем не то. Spring Statemachine управляет состоянием приложения, когда твое приложение представляет из себя какую-то finite statemachine и в разных состояниях работает по-разному. Мы сделали другую штуку: когда у тебя есть какая-то сущность, ты для неё задаешь жизненный цикл и можешь её по этому жизненному циклу гонять. А наша задача — подумать о том, чтобы у тебя транзакции работали и всё такое. У нас просто в одном правильном месте стоит аннотация @Transactional, как ты понимаешь, и этого достаточно для того, чтобы мы говорили, что оно управляет состоянием. Главное, что там есть удобный DSL, который позволяет говорить, откуда куда можно и что нужно делать по дороге.
— А я правильно понимаю, что, поскольку эта штука у тебя управляет абстрактными вещами, на ней можно сделать то же самое, что делает Spring Statemachine?
— Да, правда, есть нюанс. Основной сущностью, которой управляет эта штука, является, кажется, entity with id или что-то в этом роде. Это действительно очень маленькая библиотека из двух интерфейсов, двух exception'ов и четырех классов.
— А та штука, которую Spring сделал — почему ты считаешь, что это нечто странное и непонятно зачем нужное?
— Оно понятно, зачем нужное, просто сделано очень плохо. Оно заявлено, как будто умеет вообще всё. Во-первых, примеры, которые у них приведены в документации, не собираются, а во-вторых, если попытаться покопаться в исходном коде (а ты всегда копаешься в исходном коде Спринга, когда хочешь что-то сделать, потому что далеко не всё написано в документации), ты выясняешь, что он написан так, как лучше писать не надо. Кстати, кажется, к Spring Batch обычно примерно те же претензии.
— Ты Spring Batch тоже использовал?
— Мне кажется, я использовал почти всё, что есть в экосистеме Спринга.
— И как — продолжишь использовать?
— Ты знаешь, на следующем месте работы у меня не будет Спринга, у меня будет ЕЕ. Это был не мой выбор. Наверное, я бы использовал Спринг, но вообще-то я в нашем подкасте как-то рассказывал, что сейчас мой фаворит — это микрофреймворк Jooby, который умеет всё на свете. Его написал в одно лицо какой-то Java-чемпион. Там есть тоже dependency injection, который построен на Guice. Оно прикольное, у него есть экосистема, в отличие, кстати, от всех остальных микрофреймворков.
— Я вижу, что есть два варианта — для Java и для Kotlin.
— Я подозреваю, что можно для чего угодно. На Scala, наверное, тоже можно, но придется отказаться от Guice, который наверняка со Scala не работает. Я, как обычно, люблю constructor injection с аннотациями. А это делается в Guice.
— А если такое приложение можно будет собрать с помощью GraalVM статически — это будет просто космос.
— Я не думаю, что ты там много чего выиграешь. Это как Spring — конечно, что-то выиграешь по перформансу.
— Поднимать скорость стартапа, например.
— Конечно же мы в продакшн потащим какую-то маргинальную штуку, написанную одним Java-чемпионом, и будем там бороться за скорость стартапа!
— Понятно.
— Наверное, ребята, которым по-настоящему важна скорость стартапа, берут какой-нибудь Azul Zing и тюнят им что-нибудь на голом SE написанное.
— А я правильно понял, что та библиотека, которую ты писал, она опенсорсная и всё такое?
— Да, она заопенсоршена у моего прошлого работодателя и так или иначе принадлежит ему, поскольку это было использовано в рабочем проекте.
— Понятно. То есть писали вы ее в рабочее время.
— Да, писали в рабочее время.
— А как ты думаешь, есть какая-то перспектива писать софт в нерабочее время?
— Я пишу софт в нерабочее время, правда, сейчас это не настоящий софт. А последнее, что я написал… сейчас в России актуальна проблема с блокировками, а для меня актуальная проблема — эти блокировки обходить. Есть замечательный прокси-сервер, который называется 3proxy, вот я под Fedora, Ubuntu, Debian и Centos написал Ansible playbook, протестированный во все концы, и расшарил его на GitHub. И в Ansible Galaxy тоже расшарил.
— А где ты находишь время на вот это всё?
— У меня, как и у всех, проблемы со временем, потому что я устаю на работе, у меня семья, надо хотя бы сколько-то времени проводить с семьей. Но по выходным семья спит допоздна, а я жаворонок и просыпаюсь рано, голова у меня с утра хорошо работает, и я могу много чего сделать. Иногда я пишу что-нибудь даже перед работой.
— Что бы ты посоветовал тем, кто хочет начать писать что-то в опенсорс, но никак не получается?
— Спросить себя, почему не получается? И в зависимости от ответа на вопрос, попробовать что-нибудь написать.
— Есть стандартный ответ: нет времени, непонятно, где я такой нужен.
— Насчет «нет времени», бывает такое, что по-настоящему нет времени, а бывает такое, что не по-настоящему нет времени. «Нет времени» — это такой способ сказать, что у меня нет мотивации. Это абсолютно хорошо понятно, и не факт, что с этим надо бороться. Не все люди обязаны коммитить в опенсорс. Это клёвый способ сделать что-то для себя и для комьюнити, но никто ничего никому не должен.
Если непонятно, кому ты нужен, вопрос, опять-таки, почему. Бывает две причины: ты еще совсем мало времени вообще занимаешься чем-то таким в программировании, и тебе кажется, что это что-то предельно скучное, и тогда вероятно, правда, на этом этапе ты никому не можешь помочь. Хотя я знаю людей, например, Слава Семушин — первое, что он сделал — стал контрибьютить в Alt Linux до того, как начал программировать куда-то там в продакшн. Это был его путь в программирование (это шутка, конечно). Но он реально ничего не понимал, когда начал, разбирался по ходу. И вот это уже не шутка.
Бывает такое, что люди долго занимаются энтерпрайзом и не понимают, что могут сделать. В этой ситуации очень долго был я. Еще года 4 назад точно. Я 6 лет уже был в энтерпрайзе и не понимал, что я могу сделать. Но со временем я увидел, что вот этот вот компонент системы, который я хочу переписать, в принципе можно выделить в отдельный модуль и его заопенсорсить. Это должно быть согласовано с работодателем. Главное — сделать первый шаг.
Иногда работодатель не хочет согласовывать, это довольно живая тема. Например, Тинькофф не горит желанием какие-то свои бэкенд-компоненты опенсорсить, хотя теоретически можно было бы.
Ты начинаешь видеть возможности со временем. Главное, выделить это в отдельный компонент. Если работодатель не разрешит, будете внутри работодателя использовать, будет такое внутренний опенсорс, как делают в каком-нибудь Zalando. Потом на следующем проекте ты увидишь, что эту штуку можно выделить тоже.
— Ух ты. Или написать её заново, например.
— Насчет «написать заново». Одной из проблем, которую мы решали на прошлом месте, было логирование. Понятно, все крупняки заморочены с централизованным логированием, без этого жизни вообще нет. Стандартное решение для этого — ELK stack, ElasticSearch, Logstash, Kibana. Только есть маленькая проблема — это Logstash. ElasticSearch, Kibana работают хорошо, а Logstash — не очень. Он либо работает не персистентно, либо очень медленно. Если он работает не персистентно, то размер очереди у него — 5000 сообщений. Напихал больше — сообщения начинают дропаться. Мягко говоря, неприятная особенность. Поэтому у нас вместо него была Kafka. В Сбербанке мы написали свой Kafka logback appender, который тоже заопенсоршен и вполне себе отлично работает.
— Так вот кто это был!
— Их уже три, я не уверен, что ты именно наш видел.
— Ладно. Возвращаясь к теме опенсорса и логгирования. А почему люди используют в энтерпрайзе централизованные логгеры постоянно, пытаются их сами писать, если там есть Linux и придуманные дедами способы — залить все в файлик, например?
— Я не знаю в Линуксе нормального централизованного логгирования. Там есть rsyslog, который является хорошим форматом, но, мягко говоря, не адаптирован, например, к Джаве, потому что если ты посмотришь на какие-нибудь стектрейсы, то внезапно выяснится, что стектрейсы — это много строчек, а не одна. Так что и в rsyslog-е это будут отдельные записи лога. Если это всё замешается в одну большую кучу, мне кажется, больно будет всем.
— Да, наверное.
— А еще я, честно говоря, не знаю, какие гарантии дает rsyslog. Я обычно запариваюсь, когда у меня есть какое-то решение, я пытаюсь найти его место в CAP-теореме. И я по rsyslog просто не нашел этой информации, может, я плохо искал. Но быстро я его определить не смог. Он нам вообще гарантирует доставку и за какое время? Какие там таймстемпы будут у того, что он зашипит куда-нибудь? Если он гарантирует, это уже неплохо, если ты нормально ведешь логи со всякими там спанами и трейсами, тогда ты всё равно разберешься, что бы он там ни сделал. Если он не гарантирует доставку, это совсем беда. Кафке в этом смысле я доверяю больше, но у нее больше пропускная способность. Это при том, что я плохо знаю Кафку, честно говоря.
— Там нужно еще как-то поделить, наверное, логи на критичные/не критичные, потому что если сервер логирования все-таки вылетит, то никогда не узнаешь, что произошло.
Пока мы с тобой говорим о Джаве, всё совсем просто. Мы бегаем в каком-нибудь Докере и у нас логи в stdout вводятся от уровня ERROR. А в Кафку льется всё, начиная от дебага или от трейса. Я тот человек, у которого дебажные логи вообще-то никогда обычно не выключаются. Я еще ни разу не дожил до этого светлого момента, когда я понял — всё, я больше не использую дебажные логи для разбора проблем.
— А ты не боишься, что пропускная способность, например, сети Кафки просто возьмет и закончится, если все эти терабайты логов туда полетят?
— Мы всегда были слишком маленькими, у нас было 100 Гб логов в день, а 100 Гб — что это за объем? Основная проблема, как его хранить, а не как его передавать. А у тебя реально были терабайты логов?
— Я не знаю, сколько это было в выражении хранения на диске, но я знаю, что иногда система стартовала так медленно, что мы не дожидались, когда она запустится. Кто-то случайно поставил то ли дебаг, то ли трейс, и всё.
— Подожди. Мне кажется, или вы пошли не тем путем, когда сделали логи синхронными, по сети?
— Нет, они как раз лились именно в Кафку.
— Но синхронно? Вряд ли у вас был вариант делать асинхронно, вам нужно было бы дождаться ACK от Кафки хотя бы от одной ноды, даже если вы совсем упороты и вам не хочется гарантии на логи. Хотя бы один ACK вы всё-таки дожидались.
— Наверное, да.
— Я так говорю, потому что мы писали logback appender, я понимаю, чем мы руководствовались. Но мы этот appender завернули в AsyncAppender, а потом экспериментально посчитали, сколько у нас сообщений бывает в пике, и буфер в этом AsyncAppender выкрутили на чуть-чуть больше, типа там пик плюс 10%. Получилось, что у нас приложение не блокируется.
— Какие страшные рассказы у тебя. А почему в Джаве это всё не стандартно, почему надо писать руками?
— Потому что надо писать руками во всех языках, только вот в Джаве хоть понятно, куда писать. А если взять какие-нибудь плюсы, я не знаю, с какого места начинать.
— То есть ты считаешь, там нет каких-то библиотек, которые можно добавить в Maven, и всё само установится?
— Давай начнем с того, что у них нет нормального Maven, у них ведь Ninja, Make, CMake, qmake и всё немножко тяжело с Maven. Конечно, у них есть библиотеки для логирования, они и в Джаве есть, и понятно, как к ним приделывать аппендеры. Причем в Джаве они красивые, гибкие, работают обычно с фасадами и всем таким. А если ты посмотришь на какой-нибудь Rust, там что-то совсем грусть-печаль. Я не знаю, куда там класть и записывать свои логгеры. Я с трудом осилил, как их конфигурировать.
— То есть на самом деле Джава тебе нравится?
— Мне нравится экосистема. Мне нравится Котлин как язык и Джава как экосистема. Кстати, ни одного языка, лучше Котлина, я сейчас вообще не знаю. Когда-то я торчал на Groovy, у меня даже есть футболка от Баруха с надписью Groovy.
— Выбирая между Java, Scala, Groovy и Kotlin – почему именно Kotlin?
— Идеальное сочетание хорошего синтаксиса и сложности выстрелить себе в ногу. Скалу я не люблю, потому что в ногу очень легко выстрелить, причем иногда не себе, а своему соседу. Ты добавляешь implicit-переменные, у тебя всё магически работает, а у него в дебаге ад. Можно, конечно, договориться их не использовать, тогда ты теряешь часть прелестей Скалы. Конечно, если ты совсем умный, ты используешь макросы в Скале и никто, кроме тебя, не понимает, как это работает.
— В Скале доделали макросы, получается?
— Я хочу сказать, что они работают, но я не хочу сказать, что ими можно пользоваться. И если ты еще умнее, то ты используешь библиотеку типа Cats. Но это, наверное, на том же уровне, когда ты стал чуть-чуть умнее и тебе уже скучно использовать scalaz, и ты используешь Cats. Но этот код никто не может читать, кроме тебя.
— И других адептов Cats.
— Ты так говоришь, как будто это правда, но это не правда, потому что другие адепты Cats используют его по-другому.
— В этом и есть часть мощности этой системы.
— Очень мощная, напоминает BFG.
— Которым ты стреляешь себе под ноги.
— Иногда себе, иногда другим, как повезет. Кстати, заметил — люди, которые пишут на Скале, иногда забывают думать. У них такие красивые концепции, что они могут сделать 2 инсерта подряд в разных местах и не подумать о том, что это всё нужно как-то завернуть в транзакцию. У них зато красивые вызовы в базу каким-нибудь сликом (или что там сейчас модно для работы с SQL в Скале).
— Но ты же в Джаве можешь в двух местах сделать...
— Но в Джаве у меня есть Spring, и я ставлю аннотацию @Transactional. В Джаве не принято делать сложные вещи. В Котлине, похоже, кстати, тоже. А в Скале принято. Насчет Груви – это крутой язык, конечно, пока не залезаешь в байткод с одной стороны или не напарываешься на то, что ты не понимаешь, какого типа у тебя объект. Еще они иногда любят кричать, что любой валидный джава-код — это любой валидный груви-код, но это неправда, потому что там не работают anonymous inner classes. Нельзя взять и инстанциировать. Ты должен создать лямбду и потом ее кастовать. И поэтому я выбираю Котлин, у него немного другой синтаксис, чем в Джаве, но там есть конвертер, если очень хочется. С другой стороны, никакой новой сложности. Нет ничего такого, где ты не мог бы ctrl-кликнуть на что-нибудь и не перейти. Ты ctrl-кликаешь на двойное равно и переходишь на метод equals.
— Такой скользкий момент: а ты доверяешь JetBrains? Сейчас многие не очень доверяют Джаве, потому что это Oracle, а что делать с JetBrains? Там нормальные ребята сидят, развивают язык?
— Не хочу спойлерить кусок доклада, но в целом мне нравится, как они говорят, и мне нравится то, что я вижу. У меня нет варианта «не доверять». Окей, ну не доверяю я JetBrains, тогда всё становится совсем грустным, потому что какие еще у нас языки разрабатываются каким-то относительно вменяемыми людьми? Наверное, Rust (разрабатывается Mozilla), Golang разрабатывается Google. Плюс они все разрабатываются сообществами в том числе, даже Джава. Просто непонятно, кому и почему можно доверять. У меня проблемы с паранойей, я в нее не умею.
В первый день конференции Joker (19-20 октября 2018) Паша будет рассказывать о бэкендах на Kotlin в докладе «Котлин — 2 года в продакшне и ни единого разрыва». Joker — одна из основных наших конференций, и мы постоянно пишем о ней на Хабре. Если есть возможность — обязательно приходите.
— Недавно мы с Барухом обнаружили некое исследование на тему Котлина, которое показывает, что программа на Котлине в 40 их попугаев (попугаев исследования) лучше, чем программа на Джаве.
— Не лучше, а короче, если мне память не изменяет.
— Там и короче, и лучше. Они измеряли это всё в код-смеллах (code smell). Не знаю, как это сказать. Наверное, в каком-то смысле это можно заменить словом «лучше».
— Отлично. Только знаешь, в любом сравнении двух языков есть одна маленькая проблема. Правда ли реализовали одну и ту же задачу и правда ли были одинаковые инструменты измерения? Правда ли код-смеллы одинаково качественно меряют в Джаве и в Котлине? Или на Джаве пишут последние 20 лет и код смеллов научились находить 800, а на Котлине пишут 2 года и научились находить 20?
— Вот это да, это очень хороший вопрос. Но там интересны не цифры, которые они вывели, а какие вопросы они ресерчили. Их всего 5, хочу их тебе тоже задать. Какой уровень адаптации Котлина где-либо в области? От этого зависит, сколько у тебя людей, с которыми ты работаешь, сколько проектов, сколько примеров.
— Понятно, что весь Android почти переехал на Котлин (современная разработка), а бэкенд переезжает очень медленно. Одна из целей моего доклада — ускорить этот процесс. Когда я пришел в HH на собеседование и сказал, что последние два года я пишу бэкенд на Котлине, мне сказали, а что, так можно? Это же только для мобилок! Работодатели реально не знают, что так можно. Вероятно, и сотрудники тоже не знают. Про объём адаптации сложно говорить, думаю, что в Android к 80-90%, а в бэкенде — процентов 10 максимум, наверное. Да какие 10! Если считать все легаси-системы, там и двух процентов не наберется. А вот если засчитать только новые проекты, то может будет процентов 10.
— То есть как минимум такая вещь, как Котлин на бэкенде, уже существует?
— Да, я же в Центре Недвижимости от Сбербанка писал. И до этого тоже писал.
— Хорошо. Просто многие говорят, что это маркетинг JetBrains, и живые люди по-другому будут на это реагировать.
— Часть моего доклада посвящена тому, что в итоге вся джава-часть компании стала переходить на Котлин после того, как наш проект успешно полетел.
— Вот, и следующий вопрос дальше возникает: какой процент кода на Котлине составляет приложение? Во-первых, ты можешь смешать Джаву и Котлин в качестве базы. Во-вторых, Котлин можно использовать как DSL и начать переписывать всё подряд на него.
— С моей точки зрения, ситуаций, когда нужно осмысленно мешать Джаву и Котлин, существует очень мало. Имеет смысл писать проект на Котлине целиком. Может быть, если ты чувствуешь, что ты будешь переводить приложение на Котлин целиком, ты можешь сначала начать писать новые классы на Котлине и потом в какой-то момент начать конвертировать старые классы из Джавы в Котлин и ручками их подравнивать. Но надо сказать, что «Java2Kotlin»— ну так себе инструмент, не идеальный.
— Под «Java2Kotlin» ты имеешь в виду Ctrl C – Ctrl V в Идее между файлами?
— Да, но там еще есть какой-то отдельный шорткат, наверное.
— Кстати, я пытался когда-то для Скалы использовать именно Ctrl C – Ctrl V в Идее, но там получался редкостный трешняк в качестве результата.
— Мне тоже не нравится, что делает Java2Kotlin. Я пишу лучше. Иногда с этого можно начать, конечно. У тебя есть два пути: либо ты конвертируешь весь проект, особенно если он не очень большой, и потом ты исправляешь все неправильные места. Либо ты это делаешь по одному классику: переписывать руками очень долго, много механической работы. Но тебе, наверное, захочется с чего-то начать.
— Не возникает ли там каких-то сложностей, связанных не с тупым синтаксисом, а со смысловой частью?
— Возникает, я про это расскажу в докладе.
— Хорошо. Когда Котлин добавляется в проект, дальше растет его количество или падает? Сколько должно быть Котлина, чтобы он начал всё пожирать?
— У меня нет такого опыта. Мы сразу писали приложение на Котлине, кроме одного случая. Ты ориентируешься в экосистеме плагинов к Идее?
— Немного.
— Некоторое время назад мой друг, Слава Артемьев, написал сравнительно популярный плагин к Идее, который помогает ориентироваться в спринговых и ЕЕ-шных эндпоинтах. Там есть какое-то хитрое сочетание клавиш, ты его вводишь, и у тебя возникает строка для подсказок, ты туда вводишь путь, и у тебя сам находится контроллер и метод, который за этот путь отвечает.
— В Community Edition это, наверное, очень полезная штука.
— Оно и в Community Edition работает, и в Ultimate.
— В Ultimate не особо нужно, эта фича уже есть в Spring-плагине.
— Нет нормально сделанной, потому что она работает только тогда, когда у тебя запущено приложение в Spring-плагине, если мне не изменяет память.
— В Спринг-плагине, кажется, есть вкладочка endpoints, но настолько хорошо она работает, я не знаю.
— Так она же не маппится на конкретные урлы. Она знает endpoint'ы, но разве она умеет удобно по ним искать?
— Нет, ты должен их листать. Ладно, я понял, этот плагин лучше.
— Тут же штука, у которой как в Идее всё устроено, когда ты нажимаешь Shift-Shift-Shift, начинает что-то писать, Shift-Shift-Shift подсказывает тебе всё, что есть в Идее, а эта штука сама ищет тебе endpoint'ы и методы, отвечающие за урлы. Как обычно, более-менее нечувствительна к регистру и всё такое.
— А, то есть это Search Anywhere, только для урлов и эндпоинтов.
— Так вот. Сначала он написал ее на Джаве, потому что он начал ее писать до того, как Котлин стал в компании мейнстримом. А потом постепенно мы переводили это на Котлин. И, наверное, Котлин сожрал всё, когда его стало больше трети. Когда ты видишь реальный профит, ты начинаешь очень быстро переезжать туда, потому что, с одной стороны, у тебя реально сокращается количество кода, а с другой стороны, количество процентов покрытия твоего кода тестами увеличивается, просто за счет отсутствия бойлерплейта, который ты обычно не тестируешь.
— К этому приводит именно введение Котлина или просто то, что ты включил голову?
— Мне кажется, что первое. Я не считаю, что, чтобы писать на Котлине или на Джаве, надо иметь много мозга.
— Я не про то. Там, в том числе в этом исследовании, показано, что улучшилось качество кода. И мы с Барухом по этому поводу немного поспорили в кулуарах. Выходит, что когда человек начинает писать на новом языке и он специально сделал такое осмысленное решение, то он и код начинает писать более осмысленно, и автоматически получается, что код у него лучше.
— Скорее, мой пример это опровергает, потому что, как ты понимаешь, плагин к Идее никто не начинает писать, не включая голову, потому что это штука, которой никто никогда не занимался, кроме людей, которые на этом специализируются. И редкие исключения. Конечно, есть комьюнити-плагины. Но ты пытаешься сразу писать хорошо. Нет, дело в том, что на Котлине проще писать хорошо. Там нет всех этих бесконечных Java-паззлеров, еще и Идея помогает. Если ты пишешь generic недостаточно широко, она тебе подскажет, что тут есть invariants, добавь ключевое слово in. И всё такое. На Котлине просто легче писать хороший код. Он, скорее, сам получается. Опять же, есть редкие исключения. Например, если вы пишете на Haskell, то как вы работаете с коллекцией? Вы говорите: map, fmap, фильтр и всё такое.
— На джавовских стримах то же самое.
— Проблема вот в чем: если ты на Котлине попытаешься неэффективно работать с коллекцией, у тебя она будет каждый раз представляться как новая, будет в новый лист складываться. Конечно, в Котлине есть замечательная штука — sequence. Они тут — то же самое, что в Скале.
И тогда ты начинаешь работать с коллекциями гораздо эффективнее, чем джавовые стримы, и про это есть бенчмарк, непринятый пулл-реквест к Олегу Шелаеву. Но на GraalVM оптимизируется до стояния, как будто мы выполняем одну операцию, а не несколько в конвейере. Это то, что я постил в @graalvm_ru.
— Можешь подробнее?
— Представь себе конвейер операций над массивом. К каждому числу в массиве добавить 2, потом получившееся число умножить на 2 и потом еще раз 2 добавить. А потом посчитать сумму элементов массива.
— Ты можешь это буферизованно делать, например. У тебя есть конвейер операций, ты в удобном тебе темпе обрабатываешь содержимое коллекции.
— Более-менее да. В Джаве у нас есть не так много вариантов: мы либо пишем for-циклы с преобразованием, либо мы пишем оптимизированный for-цикл, где мы заранее считаем (и это было моим baseline), какие именно мы операции произведем над каждым элементом. На самом деле мы умножаем на 2 и прибавляем 6 в этом случае. Это можно делать на стримах, а в Котлине — двумя методами: sequence'ами и не sequence'ами. Несиквенсами, понятно, получается очень медленно из-за дикого оверхеда на всем. Мы создаем кучу ненужных коллекций и всё такое. А с сиквенсами работает быстро. Быстрее, чем стримы в джаве. Но главное, что с сиквенсами, если запускать под Граалем, у тебя результат улучшается до baseline.
— В смысле, до циклов?
— Да, до одного максимально-оптимального цикла.
— Мне кажется, это та штука, которую в GraalVM хотели сделать частью платной редакции.
— Я тоже так думаю. В JDK10 с JVMCI оптимизация даже близко не так хороша, как в GraalVM EE, но заметно лучше, чем на обычном C2.
— Я-то думаю, ты пошел улучшил Community Edition до не-Community Edition, и думаю, что тебя вечером убьют.
— Нет. Я, к сожалению, даже не смотрел код. Нет времени. Я, конечно, вру в этом месте, но у меня нет времени.
— У тебя нет мотивации! Исходя из твоей же терминологии :-)
— Поэтому я специально сказал, что я вру.
— Хорошо. Поговорим на отвлеченную тему: как войти в айти. Тема животрепещущая, в том числе для наших читателей на Хабре. Вопрос заключается в следующем: ты всегда работал программистом?
— Нет. По образованию я психолог в бизнесе. Я закончил факультет психологии в Высшей Школы Экономики по специальности «психолог в бизнесе». И то, что я сейчас скажу, никаким другим людям, наверное, не подходит: когда я закончил учиться, я пошел работать сначала в техподдержку, а потом стал сисадмином, у меня неплохо получалось. В 2008 году был кризис, меня сократили, и я стал искать работу, меня позвали попробовать пойти программистом за совсем небольшие деньги. Меньше, чем я получал админом. Я пошел, попробовал, и случайно у меня получилось. Я стал программистом от безысходности.
— А на чем ты программировал?
— Первые месяца 4 программировал на C++ Builder, а потом у нас там внутри открыли маленькие курсы по Java, на которые я, по-моему, ходил один, честно говоря. Java меня воткнула больше, чем C++ Builder, особенно учитывая то, что, когда я писал в C++ Builder, я вообще ничего не понимал. Я натаскивал иконочки и пытался связывать действия. У меня там даже приложение написано, которое с базой работало. Я уже не помню, как оно было написано, я просто знаю, что оно до сих пор работает.
— Там были компоненты — VCL, вот это вот.
— В общем, да. Но с базой я работал реальными запросами, я даже их генерировал где-то там, собирал по каким-то правилам. Это было что-то страшное, у меня был один большой класс с окном и второй класс с SQL, который собирался и выполнялся. Сейчас бы я, наверное, поостерегся так писать.
— Особенно на C++.
— Да на чем угодно, особенно на Java, тут так не принято. На C++ нет какого-то стандарта, как принято, поэтому, в принципе, можешь делать, как хочешь. А в Джаве всякие MVC. Хотя, когда ты собираешь интерфейсик в NetBeans, то видишь такую портянку кода, которую ты сам бы никогда не написал. Не потому, что плохо, просто очень сложно. Там все эти GroupLayout или BorderLayout. Я не могу их запомнить, они невероятно сложные, с моей точки зрения, до сих пор не понимаю, как это работает. Хорошо, что я десктоп давно не писал, меня бы уже не брали никуда как десктопо-писателя.
— А Джава на десктопе еще жива, кроме IDE-шек?
— Спорный вопрос. Я бы, наверное, сейчас выбрал какой-нибудь Electron.
— Я бы тоже. Тем более что ты можешь одновременно писать и на электроне, и на Java.
— Я могу писать всё на Котлине, из этого генерируется электрон потом. С моим-то языком всё опять-таки совсем просто: Котлин хорошо компилируется в JavaScript. Подключай библиотечки и всё.
— А с моим языком под названием GraalVM всё еще проще, ты можешь Electron скомпилировать Граалем и запускать JavaScript через полиглот-рантайм.
— Ты будешь вынужден страдать от джаваскрипта. Если без шуток, ты, конечно, можешь. На Nashorn ты мог сделать очень похожую вещь. У нас же есть Truffle-компилятор для JavaScript? Ты можешь сейчас то же самое продолжать не Насхорном, а Трюфелем.
— Тут же вопрос в том, что, если у тебя Nashorn, ты должен руками стек собирать и мучаться. А тут ты просто можешь скопипастить готовый Electron, и он у тебя запустится.
— А ты уверен, что запустится?
— Я видел в чатике, как люди запускали старую версию Electron.
— А почему старую?
— Там постоянно апается версия Node.js, и в Graal своя собственная версия Node.js, она не совсем без патчей. Их нужно постоянно выравнивать между собой.
— Все эти нейтив биндинги поддерживаются?
— Да. Но иногда они всё-таки нехорошо работают.
— Я тут писал маленькое приложение на электроне для себя. Я взял целую пачку новых незнакомых технологий — Node.js, Electron Builder, SQLite и ORM к нему. Я не знаю, будет ли это всё работать под Трюфелем, потому что кто знает — нейтив биндинги к SQLite — они еще недавно на 10й Ноде не собирались. Я засабмитил баг-репорт, сказал, что не работает. И меньше чем через месяц они добавили поддержку.
— В целом, наверное, предполагается, что хороший код должен хорошо работать.
— Наверняка. Так вот я лучше на Котлине. С другой стороны, если Java FX, и, в принципе, наверное, с появлением 10-й Джавы всё становится не очень страшно. Ты можешь собрать нормальное красивое приложение на Джаве, засунуть туда прямо JRE, обрезанную и кастрированную. Оставить только то, что тебе нужно — может, будет и неплохо. Не знаю, нужно ли это кому-то. Я вообще не понимаю, нужен ли сейчас хоть кому-то вообще десктоп, кроме редких ситуаций.
— Есть набор кейсов, когда нужен десктоп и больше ничего другого.
— Это когда человек по каким-то причинам сидит без интернета, а ему нужна автоматизация каких-то действий, видимо. Управлять чем-то, например.
— Или у тебя какой-то desktop environment в операционной системе, и тебе хочется, чтобы у тебя была максимальная супер-отзывчивость. Например, у тебя есть какой-то to do list, куда ты постоянно что-то записываешь. Одно дело, когда ты открываешь браузер, переходишь на вкладку, тратишь время, чтобы это развернуть и переключиться. Главное, что, когда ты меняешь вкладки, ты меняешь контекст. Либо у тебя просто хоткей на клавиатуре — ты нажимаешь F1, и у тебя всё быстро выползает.
— Мне кажется, что правда жизни заключается в том, что для этого нужен терминал. Чтобы по-настоящему быстро и отзывчиво всё работало – это в терминальных CLI-приложениях. Я это знаю, я использую Task Warrior, потому что он идеален. Он умеет всё, в том числе считать за тебя приоритеты по заданным правилам.
— Мы не договорили про «войти в айти». То, что ты изучил синтаксис Джавы, не значит, что у тебя после этого какая-то работа будет. Что дальше делать?
— Ты слышал, что у меня нерелевантный опыт?
— Делись им дальше.
— У меня проблема, я вообще никогда в жизни джуниоров не нанимал.
— Но ты же был джуном когда-то. Вот ты выучил синтаксис, дальше что?
— Дальше пришел парень из другой команды, сказал: «Кажется, у тебя есть голова на плечах, хочешь у меня поработать?» Я сказал: «Хочу». Я абсолютно не верил, что у меня что-то получится. Всё началось с каких-то тривиальных задачек, баг какой-нибудь поправить, из сурового код ревью. Меня спрашивают: «Как ты вот это как собираешься делать?» Я рассказываю, как. Мне говорят: «Неправильно, здесь нужен адаптер. Знаешь, что это такое?» «Нет». «Вот тебе книжка про адаптеры, иди читай».
— Связанный с этим вопрос: ты учился у коллег, они тебя научили, ты стал хорошим специалистом. Как понять свою экспертность? Как понять, что ты что-то можешь?
— Я знаю только один способ, который, по крайней мере, у меня работал: сравнивать себя с другими. Пока я работал в той конторе (5 лет, кстати), мне никогда не казалось, что у меня хоть сколько-то достаточный уровень, потому что люди, которые меня окружали, были и опытнее, и круче. А потом я пришел в следующее место и за месяц стал тимлидом, потому что внезапно выяснилось, что я знаю не меньше, а где-то больше, чем другие, и при этом еще умею неплохо об этом рассказывать, умею обосновывать свою точку зрения, и с другими людьми тоже умею соглашаться.
— И в таком случае надо решить, что та компания, где ты сейчас работаешь — это плохо, потому что все на уровень ниже тебя, и дальше идти или что? Что человеку, который первый раз попал в эту ситуацию, делать?
— Работать, пока интересно и пока есть какие-то перспективы. Я зациклен на деньгах, но очень ограниченно. Денег должны платить столько, чтобы хватало на все твои потребности. Обычно потребности со временем растут. У меня приближается третий ребенок, поэтому потребности еще немного вырастут. В общем не то чтобы я просто гоняюсь за деньгами. На следующую работу я иду даже с понижением по деньгам.
— Более широкий вопрос: многие люди устраиваются в какой-нибудь мелкобанк, чувствуют, что они могут делать какие-то простые задачи — генерить репорты из SQL базы данных по шаблону, и там остаются до конца жизни. Не очень хорошо карьера складывается.
— Им же хорошо? Единственный важный вопрос — это хорошо ли им. Нет никакого абстрактного правильного для всех пути, как правильно жить. Для меня правильно — двигаться вперед и искать интересные задачи. Для кого-то правильно сидеть на месте и выполнять ту работу, которая всегда хорошо получается, и получать за это деньги. Все люди нужны.
— Кстати! Ты знаешь столько всяких интересных вещей и можешь это рассказать. Почему же ты не бываешь у нас на конференциях каждый год с каким-нибудь новым докладом?
— Мне не кажется, что я знаю достаточно, чтобы много рассказывать.
— Но ты всё-таки пришел!
— Случайно получилось так, что у меня есть более-менее уникальная экспертиза для отрасли. Крайне мало кто реально пишет бэкенд на Котлине. Похоже, что никто из них не горит желанием рассказывать об этом. И у них, вероятно, и нет вот этой жилки евангелизма. У меня всегда есть желание научить других правильно жить (или хотя бы попытаться). Поэтому мне, конечно, интересно. Более того, в этом докладе в какой-то степени заинтересован я сам, потому что следующий работодатель, к которому я приду и попрошу писать на Котлине, скажет: «С чего бы?», я скажу, что вот, я делал доклад на Joker, давайте посмотрим.
— Как сформулировать тот момент, когда ты понимаешь, что тебе экспертности хватает идти делать доклад?
— Никак. Доклад делается не из-за того, что у тебя есть экспертность, а из-за того, что у тебя есть какой-то опыт и желание о нем рассказать. Желание рассказать у меня есть уже с первого раза, когда я попал на JPoint. А вот осознанная тема «для рассказать» у меня возникла не так давно. Такая тема, чтобы можно было минут 45 рассказывать.
— Почему конференции? Почему они нужны? Из того, что ты вообще на них ходишь, получается, что они тебе нужны.
— Нет, из того, что я на них хожу, получается только то, что я на них хожу.
— Но тебе же они зачем-то нужны?
— Не знаю, насколько честно я готов отвечать на этот вопрос. Я не уверен, что я на конференции хожу за информацией. В некотором плане, я хожу на конференции, чтобы ты меня знал.
— Это нормальная идея.
— Когда я говорю «ты», имеется в виду еще куча людей, которые меня запоминают. Мне полезно вообще, чтобы рынок меня знал просто с точки зрения моей стоимости, особенно если я произвожу хорошее впечатление. А я стараюсь это делать, потому что я на самом деле вроде бы не так мало знаю, и мне постоянно не хватает интересной работы. Я постоянно нахожусь в поиске более интересной работы. Крайне редко появляется что-то, что кажется более интересным, чем то, что есть у меня сейчас.
С другой стороны, я хожу на конференции, чтобы лазить в кишочки. Такой возможности нет вообще нигде. Я ходил слушать про то, как устроен Azul Zing, потому что это интересно. Да, я вряд ли смогу использовать эти знания, но это просто интересно. Это вряд ли можно прочитать в какой-то книжке. У меня еще проблема: я достаточно мало читаю книжки. Я предпочитаю читать художественную литературу. Я, наверное, один из немногих хоть сколько-то серьезных технарей, которые вот так вот живут. Я читаю референсы, вайтпеперы, но почти никогда не читаю книги. А в референсах и вайтпеперах редко бывает такая информация.
— Да и в книгах не так часто такая информация бывает.
— Книги мне прям тяжело даются, честно говоря. Последняя значимая книжка, которую я прочел по Java — «Java Concurrency in Practice», а по Java экосистеме — «High-Performance Java Persistence», Vlad Mihalcea (это очень хорошая книжка). Но обычно это очень тяжелое чтение, и мне не дается.
— Стоит ли читать доку Джавы?
— Это зависит от твоего способа обучения. Люди делятся на два типа по тому, как они учатся: некоторые предпочитают сначала написать, потом понять, как работает, а некоторые сначала читают, как писать, а потом уже пишут. Я отношусь к первому типу. Я всегда начинаю с экспериментов и не погружаюсь глубоко. Глубоко я погружаюсь гораздо позже. Со мной работала замечательная девушка, которая, прежде чем написать первую строку на Котлине, пошла и прочитала доку по Котлину.
— Наверное, я бы так, кстати, и сделал.
— Это замечательный путь, я ничего против не имею.
— Мне тоже очень интересно, как делают люди типа тебя, которые сразу могут нормально написать.
— Нет задачи написать нормально, есть задача написать. Это очень важно. Вообще задача написать нормально возникает далеко не всегда, особенно, когда ты учишься. Когда я чему-то учусь, я не могу просто осмыслить кучу информации и потом пойти писать. Я всегда начинаю с экспериментов. Может быть, ты знаешь, что я иногда пишу подкаст. В первом выпуске, который мы записали и опубликовали, я рассказывал о том, что я успеваю всё изучать только потому, что я никогда не откладываю это на потом. У меня нет задачи что-то прочитать и, значит, я экономлю кучу времени, потому что я сразу сажусь и начинаю использовать какую-то технологию, либо в рабочем проекте, либо в каком-то домашнем, в тестовом. Потом, если понадобится, я углублюсь. Но для начала я смогу рассказывать, что я понимаю, как этим пользоваться. На следующем этапе я могу рассказывать, что я знаю, как это работает. Спрингом я начал пользоваться до того, как понял, как он работает. Наверное, лет за 6.
— Кажется, нам пора сворачиваться :-) Спасибо большое! Увидимся на Joker, обязательно приду послушать твой доклад.
Комментариев нет:
Отправить комментарий