...

пятница, 28 сентября 2018 г.

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ха-ха!

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

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

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

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

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

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

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

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

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

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

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

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

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

Это правда, что только у Ruby есть Rails. Если посмотреть на веб-фреймворки для JavaScript, я не думаю, что они достаточно сравнимы с 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 у нас есть интерфейсы к другим языкам?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я работал с OOП в Perl. Это, в целом, как бы просто хак для OOП-подобных вещей. 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

Let's block ads! (Why?)

Комментариев нет:

Отправить комментарий