Хабрахабр

Интервью c Аароном Паттерсоном, спикером конференции RubyRussia 2018

Привет! Продолжаем серию интервью со спикерами конференции RubyRussia. Аарон Паттерсон (он же tenderlove) — член Ruby core team и Rails core team, ведущий инженер-программист в маленьком стартапе под названием GitHub. Павел Аргентов пообщался с Аароном перед его второй поездкой в Россию.

Какова твоя личная ruby-история? Начнем со стандартного вопроса. Расскажи про свои достижения? Как ты сел на этот поезд? Я тогда был Java-программистом. Получилось ли сделать мир лучше?
Ruby я открыл для себя в 2006-м году. Начнем даже раньше: я был программистом на Perl, а затем стал программистом на Java, но джавистом я быть не хотел.

Почему?

Было много того, что есть в Rails: можно было просто менять код, перезагружать страницу и проверять, что вышло. Когда я писал на Perl, у нас уже был собственный веб-фреймоворк. Когда мы перешли на Java-разработку, стало так: нужно все перекомпилировать — пройдет 10 минут, прежде чем можно будет проверить все только что сделанные изменения. Все просто работало. Ожидался выход Perl 6. Мне нравятся динамические языки, такие как Perl, больше, чем Java. Подумал: «Ничего себе! И вот, пока я ждал Perl 6, я узнал о Ruby. Ну знаешь, просто ради фана. Вот то, что мне нужно!» Так я и начал заниматься Ruby — в свободное время, например, для сайд-проектов. Наконец, в 2008 году я уже получил на Ruby работу. С этого все начиналось.

Это уже были Rails?

— Мы будем использовать Rails. Да, мой приятель решил начать стартап. Я такой: — Да, конечно, с удовольствием буду работать на “рельсах”! Хочешь работать с нами в одной компании? Вот так я и начал.

Поэтому при любом удобном случае прямо на рабочем месте я писал опенсорс. Честно говоря, мне не нравилась моя работа в этой компании. Потом я заканчивал дело за пару часов, а остаток времени использовал для опенсорса. Это делалось так: — Ок, проект займет 2 дня.

Оставьте меня, плиз, в покое! То, что у нас называется: «Не бей лежачего!» Я сижу здесь спокойно, починяю примус.

Итак, тут я начал много работать с опенсорсом. Ага! Так я вообще вошел в опенсорс. На этой работе я начал писать Nokogiri и вообще работать над своим Ruby-опенсорсом. Просто “вносил посильный вклад”, пока однажды не вступил в команды Ruby Core и Rails Core.

Так как же ты ты в конечном итоге оказался в Rails Core Team?

Находили баги, я их исправлял и отсылал патчи. Мы просто находили ошибки и разрабатывали Rails-приложения. В конце концов, они устали от того, что я просто гоню пулл-реквесты. Я просто слал патчи.

Типа, теперь бери дело в свои руки, да?

В целом это было как brute force атака! Да, точно!

Так каков твой общий вклад в Rails? Звучит разумно!

В основном — над Active Record. Я много работал практически над всеми частями фреймворка. Причина такой привязанности — это делает чьи-то приложения лучше. Особенно мне нравится делать багфиксы и улучшать производительность. Вот почему мне нравится на это работать. Все рады, если приложение станет лучше, а для этого не нужно ничего делать.

А «большие» вещи архитектурировать не приходилось? Ты делаешь какие-то «небольшие» доводки, которые заставляют все работать.

Например, архитектура работы c URL, ассоциациями, штуковины внутри маршрутизатора — как-то так. Обычно всякий раз, когда я делаю в Rails что-то архитектурное, это что-то внутри. Они могут быть замечены пользователем, но это не в виде: “Вот она, настоящая Вещь!” Я стараюсь придерживаться такого стиля. Ни одна из этих вещей не будет обязательно заметна. Я, скорее, говорю про себя: «Ну ладно, сделаем эти твои Прекрасные Фичи. Думаю, что на самом деле это хорошо, потому что Дэвиду (DHH — П.А.) нравится делать Новые Блестящие Прекрасные Фичи. Глядишь, и правда выйдут прекрасные!»

Вот например, твоя презентация на конференции будет про определенные глубокие инженерные части Ruby вообще и Rails в частности. Да, кто-то должен делать всю ручную работу. О чем презентация на самом деле?

До конца еще всю речь не выдумал. На самом деле я расскажу о внутренностях Ruby.

GC, производительность, все такое, жизнь, вселенная, 42?

В основном, о байт-коде в виртуальной машине и о том, как это относится к сборщику мусора. Думаю поговорить о сборщике мусора, процессе компиляции Ruby и байт-коде. Не предполагаю много рассказывать о Rails. О некоторых улучшениях производительности, которые я сделал в GC.

Наши организаторы подумали, да и переименовали всю затею в основном из-за того, что Мац заявил, что он никогда не посещает конференции со словом “Rails” в названии. Наша конференция раньше называлась «Rails Club». Итак, теперь мы «Ruby Russia»!

Итак, я буду говорить о внутренностях Ruby!

На твой взгляд, что должны делать программисты на Rails для достижения лучшей производительности в своем коде?

Первая, общими словами, — не делай ничего особенного. Существует несколько стратегий. Запусти его, получи клиентов, обратную связь и т.д. Просто пиши свое приложение. Никогда не работай с узкими местами, пока реальная работа с клиентами их не выявит. Сразу проанализируй обнаруженные узкие места. Это время можно было бы использовать для новых фич. Если ты занимаешься узкими местами, которые на самом деле таковыми не являются, это напрасная трата времени. Во-первых, просто посмотри на запросы к базе данных, которые делает страница. Однако думаю, многие сказали бы то же самое, так что давай поговорим о том, что реально влияет на производительность. Сами запросы — автоматизировать и сокращать. Это первая линия обороны — старайся сократить время, затрачиваемое на определенные запросы. Ха! Ты не поверишь, как часто мы забываем просто добавить индекс. Итак, сделай хотя бы индекс в нужном месте.

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

Первая из них, я думаю, это знать сам язык Ruby. Есть пара таких штук. Вторая — хорошо разобраться в UNIX. Изучите язык очень тщательно.

Вот лично я пришел в Ruby из мира UNIX. Ты первый «мой» спикер, который говорит, что надо знать UNIX. Я пришел к Ruby, как к еще одному Perl-у, чтобы делать свои сисадминские дела, и только потом обнаружил, что это еще и веб-язык. Я занимался Linux, FreeBSD и тоннами кода на Perl. Как и почему? И вот, ты говоришь, что надо знать UNIX.

Ты… Важно изучать стандарты POSIX и о то, как они взаимодействуют с операционной системой, потому что ты столкнешься с этим, как только начнешь масштабирование.

… должен знать, кто такой Генерал Фейлер и почему он читает мой файл?

Нужно знать, что меняет производительность. Ха-ха, да! Они будут иметь значение, потому что приложение развертывается на сервере UNIX, поэтому нужно понимать, как приложение будет взаимодействовать с ОС, на которой оно будет запущено. Возможно, не надо специально заучивать это наизусть, но следует знать, что они (системные вызовы — П.А.) существуют, и как их гуглить, потому что с этим хозяйством обязательно столкнешься. Если возникнут какие-либо проблемы, всегда можно начать с этого места. Другой важный момент состоит в том, что если ты получил этот навык в UNIX, ты можешь применить их, например, в других языках. Это, пожалуй, главное, что я рекомендую программистам изучать.

Возможно ли быть хорошим программистом в Ruby, не зная ничего вне пределов Ruby? Как думаешь, полезно ли рубисту знать какой-нибудь другой язык?

Честно говоря, я не знаю. Хороший вопрос. Однако я не знаю, нужно ли обязательно изучать другие языки, чтобы стать хорошим программистом на Ruby. Все известные мне хорошие рубисты знают другие языки. Я думаю, что просто так бывает, что люди учатся другим языкам.

С медицинской точки зрения, чем больше языков знает человек, тем сильнее это оттягивает наступление его Альцгеймера. Хорошее наблюдение!

Ха-ха!

После 40 приходится думать о таких вещах...

Мне это знать полезно! Я приближаюсь к 40 годам!

Ruby — это язык с великим прошлым. Давай поговорим о самом Ruby. Не так давно я был в Санкт-Петербурге на одной из крупнейших ИТ-конференций, виданных мной в России. А есть ли у него будущее? Мне постоянно приходилось «Ruby-апологетикой»: Ruby НЕ НАСТОЛЬКО мертв, на Ruby все еще пишут. Местное руби-сообщество на этой конференции представлено не было. У каждого большого языка на рынке сейчас есть какие-то инструменты для веб-разработки. У Ruby есть, между прочим, лучший из известных веб-фреймворков — и все такое. Каково место Ruby в этой экосистеме и имеет ли «Ruby с большим прошлым» будущее? Go, Rust, что угодно.

Есть много разных языков, для которых есть веб-фреймворки, но я все же считаю, что если посмотреть на них с точки зрения эргономики разработчика, Ruby в любом случае окажется в топе. Я думаю, есть несколько аспектов ответа на этот вопрос. Проблема в том, что Руби уже не «новенький и блестящий». Его легко использовать, и легко продать результат. Они хотят сесть на следующий после Rails поезд. Люди хотят увлечься чем-то новым.

Хотят запаха новой машины!

О будущем… В Ruby появилось много новых разработок, особенно это про JIT и то, с чем работает Koichi: guilds. Да! Если мы приложим должные усилия, будущее обязательно будет. Я бы сказал, что у Ruby определенно есть будущее, но для этого всем придется поработать.

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

Трудно ответить, потому что я занимаюсь только проблемами веб-разработки. Хороший вопрос!

Ребята из Python-сообщества, например, любят хвастаться своими успехами в научных вычислениях. Я спрашиваю, потому что это мой личный интерес.

Но я думаю, что реальным альтернативным вариантом для Ruby является системное администрирование. Я знаю, что есть группа, работающая над научными инструментами в Ruby.

Как мы можем привлечь к нашему сообществу разработчиков из других языков?

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

Знаешь, есть поговорка: «все, что можно переписать на JavaScript, будет обязательно переписано на JavaScript». Пришло время холиварного вопроса, о JavaScript. Мы говорили об эргономике разработки Ruby. Считаешь ли ты, что Rails также будут переписаны на JavaScript? Один из очень известных российских программистов сказал, что «многие языки хороши, но только у Ruby есть Rails». Это лучшее, что есть в Rails. Как мы можем конкурировать с JavaScript? Однако JavaScript-разработчики склонны подвергать это сомнению. Или нам следует устроить с ним симбиоз?

Если посмотреть на веб-фреймворки для JavaScript, я не думаю, что они достаточно сравнимы с Rails с точки зрения эргономики разработки. Это правда, что только у Ruby есть Rails. Мы должны быть частью сообщества JavaScript. Дело в том, что, поскольку мы пишем веб-приложения, нам придется работать с JavaScript. Если на сервере можно запустить любой язык, почему это должен быть именно JavaScript? Нам полезно иметь симбиоз. Удобство разработки все еще на нашей стороне, и оно особенно ценится в Rails-сообществе. Но язык хорош, и я думаю, нам нужно работать симбиотически. Итак, ты пришел на IT-конференцию, и тебе пришлось там работать представителем Ruby?

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

Лично я считаю, что программирование на Ruby намного проще и приятнее, чем на других языках. Для нас же польза, если мы будем работать вместе с другими языками, а не соперничать с ними. Мы говорим о других языках программирования и должны ли мы их знать. Почему нет? Какие-нибудь вроде Java, Haskell или что-нибудь еще функциональное типа Elixir или Lisp, что-нибудь такое. Я считаю, важно, чтобы рубисты изучали другие языки. Хорошим свойством Ruby является то, что мы можем использовать в наших программах техники из различных языков. Думаю, полезно изучать разные парадигмы, потому что, узнавая новое, ты можешь утащить это и использовать на своем языке.

Да, у нас есть, например, инструменты для функционального программирования или выполнения map/reduce или чего-нибудь-еще.

Если используешь язык, который поощряет эти приемы, возможно, ты найдешь лучший способ решить поставленную задачу. Да, мы можем все это использовать. Честно говоря, я трачу 50% своего времени на программирование на Си. Я не уверен, что прям вот нужно изучать другие языки, чтобы быть хорошим рубистом, но мне это изучение точно помогает.

Си делает пальцы сильнее!

Я программирую на Си, чтобы другие могли программировать на Ruby.

Внутренности Ruby написаны на чистом Си, не ++?

Было бы неплохо, если бы больше этого кода было написано на Ruby, но, честно говоря, некоторые из основных вещей из соображения производительности нужно писать именно на Си. На чистом. Поэтому я работаю над инструментами профилирования памяти в Ruby. Одна из вещей, которыми я занимаюсь… Нам нужно улучшение профилирования памяти. На работе я пишу много сишного кода. Поскольку все внутренности написаны на Си, мне приходится и инструменты писать на Си.

Как дела у Ruby с FFI и тому подобным?

Если что-то сложнее… То все сложнее. FFI работает достаточно хорошо, если у тебя в работе библиотека на Си, в которой нужны одна-две функции. Однако все равно придется делать такие загадочные вещи, как управление памятью. Когда работаешь с FFI, ты в основном пишешь код на Си, который похож на Ruby. А в остальных случаях переключаюсь на Ruby. Я лично нахожу, что между этими мирами легче переключаться, если используешь Си для управления памятью и т.д.

В Ruby у нас есть интерфейсы к другим языкам?

Я видел парня, который занимался научными задачами, поэтому он интерфейсил с Python. Некоторые интерфейсы с JavaScript.

Он взаимодействовал непосредственно с рантаймом языка?

Не типа шеллинга или чего-то в этом роде… Проект еще очень экспериментальный. Да, именно. Когда он дает демоверсии, он говорит, что «все работает, но может и упасть!»

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

Причина, по которой люди идут в Rust… они хотят иметь язык, который имеет больше возможностей защиты, чем дает Си. Мне нравится Rust, думаю, что это очень хороший язык. Я лично большой поклонник Rust, люблю его. Было бы действительно потрясающе переписать Ruby на Rust.

Он безопаснее, быстрее или как? Чем он может быть полезен?

Я не уверен, сильнее ли он оптимизирован, чем, чем Си, но он определенно безопаснее. Думаю, безопаснее. Когда я пишу Си-код, я почти уверен, что он не SEGV-нется, но уверен не на все 100%. Это то, что мне в нем нравится. Когда я пишу на Си, я почти уверен, что не будет утечки памяти. Но когда я пишу на Rust, я уверен гораздо больше. Вот почему мне лично предпочтителен Rust, а не Си. С Rust ясно как белый день, что утечки памяти не будет. Есть целый проект под названием «Helix» — специально для этого. Еще я начал изучать Rust, потому что хочу писать на нем расширения для Ruby. Использовать Rust для такого — это пушка по воробьям. Часто, когда я пишу на Си, это как бы: «ОК, у меня есть библиотека на Си, и я должен получить к ней доступ из Ruby, написав пару костылей». Rust будет нашим новым Си. В моем идеальном мире все, вся система однажды будет переписана на Rust. А операционная система будет сделана на Rust. Если тебе нужно быстро решить проблему, ты пишешь на Ruby. И всем будет щастье.

Достаточно ли Rust зрел для этого?

Думаю, вполне. Ну, не знаю. В Mozilla им пользуются — и довольны.

Каков шанс «увидеть регистры», запустив программу на Rust?

Надеюсь, низкий! Ха-ха, не знаю! Увидеть такое совсем не смешно.

Особенно, когда запускаешь что-то в браузере.

Выскакивает сообщение о креше, и ты такой: «ОК». Да. У нас на работе есть некоторые штуки на C++, и иногда, когда я получаю сбои, я просто такой: «Хм...» Ха!

— это была моя любимая шутка, когда я переключился с Си на Ruby... Я хочу программировать на языке, а не на макроассемблере!

Всякий раз, когда я пишу на Си, стоит вопрос, о чем я должен задумываться. На самом деле ты прав. С Ruby мне не нужно думать обо всем этом (низкоуровневом хозяйстве — П.А.). Я в самом деле не думаю о решаемой задаче. Вот одна из причин, по которой я так сильно люблю Ruby! Я просто сосредоточен на логике программы, и я делаю дело. 3, это было еще до того, как там появились дженерики. Когда я был джавистом во времена Java 1. Потом я начал изучать Ruby, там map уже был как в Perl… Каждый раз, когда приходилось писать что-то вроде map — например, коллекции или итераторы, надо было сделать «iterator.next()», а потом кастить полученное значение… Только затем выполняешь нужную операцию.

У меня прямо в руках есть объект точно того типа, который мне нужен! … О, чудо!

В Java мне пришлось бы написать строк 15 кода, чтобы добиться того, что я могу сделать одной строкой в ​​Ruby. Да, точно. Вместо того, чтобы писать всю эту дрянь! Писал бы на Ruby, закончил бы работу намного быстрее! Я тратил часы на лишние движения! Понимание этого очень расстраивало меня на той работе.

Экзистенциальный ужас!

Это был поворотный момент. Именно! Я не могу пилить яву до конца своей жизни! Мне нужно было найти работу на Ruby.

Можно ли утверждать, что Ruby улучшает ум программиста?

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

Я попытался освоить ООП. Я помню свое собственное впечатление, когда я начинал в 90-е годы. Читал книги, выучил «святую троицу ООП». Пробовал заняться C++. Потом я попытался поработать на Java, заработал немного денег на Perl. И затем я снова обнаруживаю себя в процессе освоения все тех же «макроассемблерных» трюков. И только в Ruby я наконец понял, как работает ООП.

Если подумать о других ООП-языках, таких как C++ или Java, то в них не все есть объект. Дело говоришь. Все еще есть примитивы, а с ними приходится иметь дело иначе, чем с объектами. Например, все еще есть просто ints. Приходится заниматься только ООП. В Ruby на самом деле все — объект. Я действительно не сильно задумывался об этом, пока ты не спросил. Больше упражнений, больше смысла.

Это формирует разум. Язык разработан так аккуратно, что он просто заставляет думать в нужном направлении. Синтаксис сам объясняет, что ты делаешь.

Это, в целом, как бы просто хак для OOП-подобных вещей. Я работал с OOП в Perl. Но у нее среди прочего есть не-объекты. Java, конечно же, реализует OOП. Ruby в нашем списке — первый язык, на котором все действительно является объектом.

Какими словами ты воодушевил бы и молодых программистов, и старых?

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

После выходных возвращаюсь к работе, открываю свой Emacs с Ruby, и говорю себе: «О боже, как прекрасно вернуться на родину!» По выходным я занимаюсь небольшими упражнениями на других языках.

Мне всегда приятно возвращаться. Да, думаю, что это хорошо — переходить на другие языки, поработать там, накопить некоторые наблюдения. Я чувствую, что в Ruby я у себя дома.

Так что увидимся на конференции! Задать Аарону свои вопросы лично можно будет уже 6 октября. Все подробности на сайте.

Прочитать оригинал на английском можно на hype.codes.

И огромное спасибо компаниям, которые подерживают главное Ruby-событие в России:

Генеральный партнер — Toptal
Золотые партнеры — Gett и Cookpad
Серебярные партнеры — Instamart, UCHi.ru, JetBrains и Qlean
Партнер афтепати — Teachbase
Бронзовые партнеры — Bookmate и InSales

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть