Русскоязычный подкаст о языке Ruby

S08E02 — RailsClub 2016: интервью с Алексеем Тактаровым

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции.

Первое интервью было с Лешей Тактаровым

Алексей Тактаров

Ссылки


Расшифровка эпизода, опубликованная на Habrahabr

Как ты пришел к Ruby ?

Моя история знакомства с этими технологиями довольно нетипичная. Я начинал свою карьеру как человек, который делает системные тулзы. Я и с фронтендом тогда не встречался, просто занимался нативными интерфейсами для Windows. Какое-то время потратил на то, чтобы делать программы, которые работают с большим количеством потоков, которые работают с concurrency и так далее. А затем как-то плавно перешел во фронтенд, тогда как раз появился хайп. С Ruby и рельсами я начал работать уже после этого, и для меня это было небольшим откровением, потому что не все вещи, которые там работают, работают так как я привык. Лучший пример: в некоторых средах, где ты всегда должен следить за ресурсами, если ты что-то взял в одном потоке и работаешь, то должен быть уверен, что в другом потоке не будет проблем с этим - в ruby все эти проблемы обходили стороной. Я столкнулся с совершенно другими концепциями. И это было клево!

Если говорить конкретно - я пришел на проект как фронтендер, делал только фронтенд задачи. А потом у нас не стало бэкендера :) Он ушел, некому было решать его задачи, и я решил попробовать. Было необычно: обсудить было не с кем, человек который мне помогал был этаким мудрецом. Я приходил к нему раз в неделю, он говорил какие-то магические слова о том, что мне делать. Потом я уходил, вздыхал, думал: “О боже, что происходит”.

Через какое-то время мне вроде удалось постичь эту мудрость, хотя наверное не всю. Ту часть, которая заложена во фреймворке и языке, я почувствовал этот вкус.

Где и чем ты сейчас занимаешься?

Из личного - готовлюсь к свадьбе. Работаю над своим проектом, который еще слишком сырой, чтобы про него рассказывать. А еще работаю с партнером в команде, которая называется These Guys. Мы специализируемся на быстрой разработке MVP. Стараюсь по-максимум применить тот опыт, который я получил работая со Злыми марсианами, и с другими командами. Но сейчас я больше ориентируюсь сейчас не на решение технических задач, а на решение бизнес задач, продумываю как оптимально все построить для клиента.

То есть ты сейчас открыл свою компанию?

Да. Хотя сказать об этом вслух мне сейчас очень страшно, почему-то :)

Что тебе не нравится в текущей реализации рельсов с точки зрения фронтенда?

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

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

Я всегда пытаюсь смотреть шире. Когда я вижу хайп вокруг фронтенда, я всегда пытаюсь найти и хорошие, и плохие стороны. Хорошо, что все развивается и движется, много идей, много что можно сделать такого, что поможет следующему поколению разработчиков. Но на это нужно смотреть с опаской, смотреть на то, действительно ли все так, как кажется? Это касается и компаний: какой они выбирают стек, как они общаются со своими разработчиками. Например, разработчики брали какой-то популярный сейчас стек, а потом все разваливалось. Компания переставала работать, потому что технология была сырая. У вас было такое?

Я стараюсь придерживаться золотой середины. Недавно прочитал статью Равиля Байрамгалина из марсиан про новый рендерер. В ней интересна даже не сама реализация, а то, что идет в начале статьи: у DHH нет большого количества времени, чтобы уделять его разработке, но он записывает и рассказывает много идей, которые могут подхватить другие разработчики, чтобы успешно развивать фреймворк. Мне кажется, это здорово. Круто, когда есть видение, когда DHH понимает куда идти. Возможно будут разногласия, где-то это будет не совсем правильный путь. Но мне нравится, когда есть понимание общей миссии. В рельсах такое видение есть, нужно пережить хайп и двигаться дальше. Мне кажется у нас все получится, моя позиция вполне позитивная :)

Если говорить про хайп во фронте. Что сейчас является хайпом, а чем реально можно пользоваться? На что, по твоему мнению, стоит обратить внимание? И что будет интересно дальше?

Какое-то время назад мы с друзьями организовали в Ростове небольшую тусовочку, которая называется Code Hipsters. Это, в основном, лента новостей во вконтакте и в Телеграмме, мы пишем про всякие модные штуки во фронтенде (это и пытаемся обыграть в названии). Сейчас я немного отошел от дел, всем занимается мой друг Витя. У него прекрасный стиль, мне очень нравится как он пишет. Иногда мы собираемся и понимаем, что мы не читали за прошедшую неделю ничего нового :) Видимо, немного устали.

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

Во-вторых, компонентный подход. Он пришел давно, все его приняли, и это здорово.

В-третьих, FRP. В этом вопросе есть большая пропасть между теорией и практикой. Наверняка что-то появится, чтобы ее преодолеть.

Возвращаясь к вопросу о рельсе как фреймворке и к фронту. Что бы ты добавил а рельсу или убрал из нее, с точки зрения фронтенд разработки? Может вообще убрал бы фронт из рельсы?

Я бы не убирал фронт. Мне кажется, решение которые есть сейчас, позволит нам выжить в 80% проектов, по крайне мере таких, которые есть на рынке. Ингода очень удобно иметь такой функционал.

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

Я слышал, что не любят турболинкс, хотя я к ним отношусь вполне нормально, использую их в некоторых проектах.

Да, иногда приходится потратить много времени на то, чтобы сообразить, как все правильно делать. Но это приучает к порядку. Мне было проще: я не писал скрипты, я сразу начал писать single page applications. Приходилось думать о том, как выделять ресурсы, как их правильно тушить, о сервисах, о жизненном цикле приложения, о том, что оно может работать продолжительно время. Когда ты делаешь простой мультистраничный сайт с вкраплением скриптов, ты об этом не задумываешься.

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

Не знаю, что я бы добавил прямо в рельсы. Есть тенденция выкидывать все ненужное, облегчать, оставлять рельсы только для API. Правильно?

Там есть отдельная ветка, связанные именно с Rails API разработкой, отключением ненужных вещей.

Да, это касается и сборки. Если ты запускаешь рельсовый проект, наверное было бы здорово уметь как-то управлять процессами, которые запускаются. Сейчас это не просто rails сервер, или какой-нибудь Sidekiq. Было бы клево уметь мониторить процессы, которые запускаются для сборки, которые Node.js-процессы запускаются. Было бы круто что-то такое придумать. Хотя и здесь можно в принципе предложить решения вроде Foreman или Hivemind.

Раз мы начали говорить про инструменты: за какими ты сейчас следишь? Какие проекты тебе нравятся, на какие стоит обратить внимание?

В некоторых случаях я пользуюсь Webpack, меня он вполне устраивает. Я понимаю весь юмор, который стоит за тем, что у него сложная конфигурация. Мне кажется главной концепция, что модули это клево. Я долго пользовался сборщиком Brunch. Его всегда обходили стороной, он оставался в тени. Но для меня это идеальный инструмент, когда нужно что-то очень быстро накидать, когда нужны просто модули в стиле common js, когда нужна очень быстрая сборка. Потому что он действительно работает очень быстро. Меня поразило, что многие ребята, которые делают фреймворки, начинают лепить boilerplate и command line tools, например Ember CLI, или штука для React, которая появилась недавно. В случае с Ember меня поразило то, что ты очень жестко привязан к сборщику, ты не можешь выбрать другой сборщик кроме Broccoli (который я тогда вообще не смог настроить, и он собирал все ну очень долго). По крайней мере, на моей машине это работало вечность.

У меня был опыт работы с Ember, мы проект свой до конца собирали на Brunch. Даже учитывая то, что пришлось очень много портировать под себя, потому что все комьюнити перешло на Ember CLI и , мы все равно пользовались Бранчем, терпели. В нашем случае, мы пожертвовали удобством в пользу скорости и быстрой сборки, потому что у нас было много файлов и мы не могли себе позволить ждать вечность.

Ты не пытался влиться в open source историю и начать помогать каким-то проектам? Если да, то куда ты коммитил?

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

У меня есть несколько своих open source проектов (если можно так сказать). Возможно, они не очень интересны, не получили много звездочек на гитхабе, но все же. Я писал враппер для работы с принтерами под Node.js, для одного из моих хобби-проектов. Я делал что-то вроде распределенной печати фотографий из Инстаграма, нашел прикольный маленький принтер для фотографий и подключил его к Raspberry. Благо на Raspberry работал Node.js, пришлось его собирать. Написал что-то вроде агентной системы (не знаю, правильный это термин или нет). Идея была в том, чтобы подключать такие принтеры-устройства и потом печатать фотографии на произвольной станции. Все это легло в основу моего дипломного проекта, который я полностью выложил на гитхаб, я этим в какой-то степени горжусь. Иметь гитхаб это здорово, и использовать его для образования тоже. Вообще дипломный проект получился довольно прикольный.

Где ты берешь информацию о фронте: ресурсы, твиттер-аккаунты, за которыми ты следишь, новостные сайты? Про Ruby мы все знаем куда смотреть, на что подписаться, а с фронтовой частью лично у меня с ходу ничего не приходит на ум

На первом месте для меня стоит Code Hipsters. Даже если если я не читаю статьи, не ищу их, я все равно пользуюсь телеграмом и читаю канал Code Hipsters c огромным удовольствием. Конечно, я немного по-другому его воспринимаю, потому что это мои друзья.

Еще?

Твиттер, особенно англоязычный помогает. Не назову какие-то конкретные аккаунты, это накопившийся за долгие годы слой информации. Иногда ты можешь листать ленту, и если произошло что-то действительно трендовое во фронтенде - ты это сразу увидишь, все лента будет заполнена этим.

Еще мне нравятся подкасты. Я слушаю Вебстандарты. Кстати, в недавнем выпуске они спрашивали, кто какие подкасты слушает - оказалось, что никто ничего не слушает :).

FrontFlip, наверное?

Нет, не пошло, вообще не получается слушать русскоязычные подкасты. Я слушаю The Changelog, еще мне нравится подкаст от Thougtbot. Еще Giant Robots, мне очень нравится стиль, атмосфера. Обычно это два спикера, и создается впечатление, что они просто встречаются на выходных, обсуждают, что у них произошло, забывают что есть тема для подкаста. Но это все равно интересно слушать. Это даже два подкаста, один скорее про бизнес (это подкаст от одного из создателей foreign key и еще какой-то платформы. А про разработку это подкаст парня который тоже будет на RailsClub, который поддерживает Phoenix для Elixir.

А про фронтенд это The Changelog.

О чем ты будешь рассказывать на RailsClub нам, бэкенд разработчикам?

О том, что фронтенд ускакал далеко и фреймворк за этим не поспевает. Я буду рассказывать о том, как собирать фронтенд в окружении рельс, какие есть решения, какие есть проблемы. И почему это на самом деле нужно. Буду стараться опираться на свой личный опыт.

Как я понимаю, ты не был раньше на RailsClub. Что ты ждешь от конференции?

Много интересных знакомств. Я бы хотел увидеть много ребят с горящими глазами. Да и вообще ребят, которые готовы пообщаться, не только на тему конференции. Конференции интересны людьми.

У меня была интересная ситуация: в прошлом году мы поехали на Frontend Union Conf, она была в прошлом августе в Москве, в этом где-то в Прибалтике. Мы приехали всей тусовкой, но так устали с дороги, что очень сложно было поймать волну докладов, мы слушали одним ухом. Драйв начался на афтепати. Мы познакомились с парнем из SoundCloud Jan Monschke. Я не помню, какой у него был доклад, но общение после конференции запомнилось. Он клевый чувак, рассказал нам про свои проекты. Речь зашла о Brunch, сборщике о котором я уже говорил. И выяснилось, что он был одним из чуваков, которые начали этот проект. Да ладно!? Это именно то, для чего нужно ехать на конференции: общение. Ну и доклады тоже :)

Помимо разработки, чем ты увлекаешься? Читаешь, поешь, играешь на чем-то, ходишь в горы?

Сode Hopsters, хотя это скорее связано с работой. Я могу сказать, что меня вдохновляют (и в работе, и в жизни) многие вещи, которые я узнал когда был ребенком. В детстве мне нравились всякие штуки, механизмы. У меня была небольшая мастерская, в которой я делал из дерева всякие луки, арбалеты. К сожалению, у меня не было наставника, который показал бы как можно подключить все это к электричеству, как делать более продвинутые штуки.

Когда-то я наткнулся на книгу, которая называется Код, ее написал Charles Petzold. Книга была интересна тем, что рассказывала о детстве: представьте себе, что у вас есть друг, вы живете в домах напротив. И вы захотели общаться, подавая друг другу тайные знаки. Вы достаете фонарик, начинаете рисовать на стене его дома буквы. Потом он плавно переходит к кодам и азбуке Морза, азбуке Брайля, рассказывает про телеграф. Если ты хочешь делать телеграфную связь, то тебе нужен повторитель, а повторитель можно сделать на основе реле… И тут начинается самое интересное. По книге можно сделать всякие logiс gate и тд. Спойлер: книга заканчивается тем, что он показывает как на ассемблере писать прототип операционной системы. Эта книга - идеальное описание того, что меня вдохновляет, вот такие мысленные эксперименты.

Еще мне нравится, когда код как-то переплетается с дизайном. Могу посоветовать книгу “ The Nature of Code”, она написана обычным языком, но показывает как писать processing, как моделировать натуральные системы, типа стаи птиц и так далее. Такие вещи меня сильно вдохновляют. Я думаю, это в какой-то степени определяет то, какой я разработчик, то, как я работаю и живу.

Сколько у тебя проектов и какой ты сейчас используешь фронтенд стек?

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

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

Если вдаваться в подробности, то я пользуюсь Slim, пишу на SCSS.

Я заметил, что когда долго пишешь single page приложения, фронтенд меняет тебя. У нас был сложный проект: отдельный бэкенд и много single page приложений. Все они были написаны на ember.js.

Вообще у ember интересный путь, от момента как созрела идея, до момента когда вокруг него начало появляться комьюнити и он начал тягаться с react по производительности. Я очень доволен этим фреймворком, в нем все есть для быстрого старта. Какие-то вещи смущают, особенно это касается Convention Over Configuration. Ребята, которые делали Ember (Ехуда Кац из Rails Core Team), вдохновлялись рельсами и постарались перенести много принципов. Мне кажется, что не все получилось здорово. Convention Over Configuration во фронтенд проектах, на мой взгляд, - это очень сомнительно. Мне проще написать больше фронтового кода, чем полагаться на какие-то вещи, которые встроены во фреймворк. С другой стороны, очень много удобных help'еров, можно быстро стартовать проект и так далее.

Возвращаясь к теме multipage. Я заметил за собой, что на рельсовых проектах, которые не используют внешний сборщик, а полностью полагаются на assets pipeline, я начинаю организовывать свои фронтендные файлы в какую-то структуру, писать сервисы, организовывать все в некое подобие view. Хотя это просто чистые ES6 классы, которые получают в конструкторе рутовую ноду, от которой можно работать. Такой облегченный backbone view, но только без всего, просто для изоляции. Я думаю, что это хорошая тенденция. Это позволяет и кодовую базу держать в хорошем состоянии, и избегать эффектов, которые часто вылезают при ее разрастании.

Сейчас идет какое-то противоборство Angular и React. Ты на чьей стороне, на темной или на светлой? И что есть темная, а что есть светлая?

С Angular я практически не работал. Понимаю, к чему ты клонишь, но об этом сложно рассуждать. Я считаю, что эти споры лишены смысла. Не нужно искать кто главный, кто прав, кто нет. Нужно понимать, кто в какой ситуации хорош, где что лучше использовать. Если будет приложение, в котором я буду видеть четкую структуру, переходы, роуты, авторизацию, загрузки и так далее - я, наверное, положился бы на Angular. Хотя в глаза его никогда не видел, но я предполагаю, что там очень много поддержки для таких вещей. Если бы нужно было писать какой-то виджет, встраиваемую часть, какое-то простое приложение, с небольшим количеством состояний, в этом случае, наверное, выберу React. Я не стал бы ориентироваться на измерения производительности и какие-то фичи типа серверсайд рендеринга. Я считаю, что эти вопросы слишком много обсуждают, серверсайд рендеринг того не стоит. В реальности это нужно в 10% случаев, по крайней мере, мне так кажется. Поэтому я бы смотрел на те вещи, которые фреймворк предлагает: на то, что будет полезно для команды, для всего проекта, для компании.

То есть ты занимаешь в этой войне нейтралитет?

Да! Если бы меня попросили посоветовать что-то следующему поколению, я бы посоветовал прочитать интересную статью про то, каково быть 40-летним разработчиком. Автор очень интересно рассказывает про всю свою жизнь, чему его научила работа больше чем в 10 компаниях. Он говорит очень важную мысль: не полагайтесь на хайп, это ложное чувство, старайтесь смотреть на все трезвым взглядом. Оценивайте, не полагаясь на кратковременные чувства. Я считаю, это очень мудро. Я бы тоже хотел придерживаться такой позиции.


Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

comments powered by Disqus