Всем привет! Мы вовсю готовимся к RailsClub, который состоится 23 сентября (ааааа, это уже на следующей неделе!!). Программа на сайте, 500 крутых рубистов уже зарегистрировались, ждем только тебя! Еще можно успеть заскочить в последний вагон и поучаствовать в главном Ruby событии года в России.
У Павла Аргентова получилось очень интересное интервью с потрясающим человеком. Luca Guidi — семьянин, независимый OSS разработчик, автор Ruby фреймворка Hanami.
Каков твой программистский опыт? Как ты попал во вселенную Ruby?
Программировать я начал ещё подростком, в старших классах школы. Профессиональная карьера стартовала около пятнадцати лет назад — я работал вебдевом на Java, что было ужасно. Это продолжалось пару лет, это была боль. Затем я переключился на Ruby, потому что появились Rails. Rails в те времена произвели революцию: веб-разработка стала сопряжена с меньшими страданиями. С тех самых пор, а это было ещё в эпоху до версии 1.0, Ruby является моим главным языком. Кроме Ruby я изучил Go и пару капель Elixir-а: последний мне интересен, а Go я использую для работы.
Не кажется ли тебе, что Ruby — лучший OO-язык, чем другие языки этой разновидности?
Если смотреть на вещи с позиции объектно-ориентированного программирования, многое в Ruby выглядит для разработчика более натуральным, и да, Ruby — лучший ОО-язык. Думаю, Java в этом отношении подобна эдакому C без изысков. Ruby с самого начала поразил моё воображение тем, что всё есть объект. Даже числа. Начинающему рубисту приходится к этому привыкать, но усвоив это положение, получаешь доступ ко всевозможным трюкам вроде полиморфизма: например, передаёшь по цепочке объекты, которые ведут себя как целые числа. Образуется приятная гибкость в проектировании сигнатур методов при возможности максимальной сосредоточенности на имплементации.
С другой стороны, я думаю что Ruby напрасно лишён интерфейсов. Из-за этого невозможно строго определить, какое именно поведение ожидается от метода, что было бы особенно полезно для авторов библиотек. Я надеюсь когда-нибудь это починят. Также не думаю, что в будущем Ruby сыграют заметную роль библиотеки, в которых будет реализовано то, чего нет в ядре языка. Новые фичи по-настоящему заработают только тогда, когда станут частью ядра Ruby. И конечно, реализация должна быть сделана как следует.
Каковы, по твоему мнению, сильные и слабые стороны Ruby? Есть ли в Ruby жизнь вне Rails?
Исторически сложилось, что самая сильная сторона Rails — монолитность, сам факт, что “Рельсы” стали “большой” платформой. Это сыграло свою роль не только в экосистеме Ruby, но и в индустрии веб-разработки в целом.
Можно заметить, что с приходом Rails язык получил невероятное распространение. Огромное количество людей стали его использовать. Это сформировало к Ruby должное доверие. Плохо то, что Rails целиком поглотили Ruby, что создало излишнее единообразие. Есть куча программистов, которые знают Rails, но совсем не знают Ruby как язык. Куча гемов по умолчанию подразумевает, что ты используешь Rails. Такая ситуация может здорово навредить языку. Если попытаться работать вне Rails, например с Hanami или с системной автоматизацией, обязательно возникнут проблемы.Так что скажу, что Rails это и главное благословение, и в то же время главное проклятие для Ruby комьюнити.
Продолжая тему борьбы добра со злом, скажу, что в Ruby сейчас самый удачный момент для развития экосистемы. Хорошая новость в том, что если у тебя в руках 5-8-летнее Rails-приложение, то несмотря на некоторые проблемы с переходом на новые версии Rails, все работает — потому что изначальные приёмы работы с фреймворком не менялись уже более десятилетия. Поэтому у тебя все ок. Плохая новость — экосистема и язык, которые принципиально не эволюционируют и предлагают только один путь решения всех задач, в конце концов сойдут на нет. Тем не менее, сейчас происходит много вещей, полезных в этом отношении. Во-первых, Hanami в этом году дошел до версии 1.0; все больше приложений начинают использовать его в продакшн. Во-вторых, ROM, у которого вышла уже версия 4.0. В третьих, Dry-rb — набор компактных библиотек для таких вещей, как обработка данных и тому подобного. Развитие всего этого — отличная новость. У нас появляется выбор: если тебе как разработчику подходят Rails — Rails даст уверенность. Если же Rails не подходит — есть рабочие альтернативы.
Ты написал Hanami. Зачем нам еще один web framework?
В экосистеме Ruby уже довольно много веб фреймворков, но почти все они являются клонами Sinatra. Hanami отличается тем, что не повторяет Sinatra. Он впитывает хорошие идеи Rails и приводит в порядок те моменты, которые стоит улучшить. Я хочу посоветовать даже тем, кто не планирует переходить с Rails никогда и никуда, пристально посмотреть на Hanami и другие фреймворки, чтобы научиться чему-то новому.
Какие гемы/идеи ты считаешь наиболее полезными в Ruby?
Напоминаю про ROM and Dry-rb — это очень интересная смесь функционального и объектного программирования. Особенно это заметно в библиотеках Dry. Они очень круты, считаю что всем нужно обратить на них внимание. Причём, не из-за хайпа, а потому что это поможет понять многое про иммутабельность и детерминированные объекты. Важно уметь конструировать сущности так, чтобы подавая что-то на вход, на выходе мы получали предсказуемый результат.
На что в FP, по твоему, стоит обратить внимание рубистам, которые в основном занимаются OOP?
Снова, иммутабельность и композиция. Не обязательно под соусом чистых функций. Определенно стоит посмотреть, как устроен Elixir. Моя идея заключается в том, что стоит сочетать FP и OOP. Пример, который я могу привести — функциональные объекты. Это объекты, которые, подобно функции, принимают на вход некоторые данные и возвращают результат, но кроме всего прочего имеют некоторое хранимое состояние или способ вызова, при котором нет необходимости постоянно передавать всё это состояние и прочие зависимости в параметрах. В то же время, по определению, функциональный объект призван качественно выполнять одну единственную задачу, что согласуется с принципом single responsibility.
Таким образом, сочетая композицию и иммутабельность, функциональный объект всегда ведет себя предсказуемо. Это все еще экспериментальная и спорная концепция, но именно это я и хочу показать в своем докладе на RailsClub. Это будет доклад про наше будущее — про новый способ делать веб-приложения с Hanami.
Так о чем же ты будешь говорить на RailsClub?
Буду говорить о том, как совмещать OOP и FP. Как это стало движущей идеей в Hanami 1.0. Если конкретнее, то я буду говорить об actions. Actions — это объекты, которые “показывают” один единственный метод, принимающий ввод и возвращающий вывод — HTTP-response, отвечающий спецификации Rack. Есть ещё валидаторы, которые ведут себя аналогичным образом. Идея в том, чтобы оценить то, что мы имеем сейчас — и стандартизировать поведение в версии 2.0. Ещё идея — пытаться построить приложение для каждого юзкейса, для каждой фичи, которая есть в монолитных приложениях — сделать что-то вроде конвейера из функций, скомбинированных друг с другом. Когда принимаешь данные на вход, валидируешь, приводишь типы, манипулируешь, обрабатываешь и потом возвращаешь что-то пользователю. Что-то такое я и хочу показать, хочу стандартизировать находящийся в нашем распоряжении набор объектов. Это уже выходит за пределы MVC, потому что в MVC ты делаешь запрос к контроллеру, ты делаешь бла-бла-бла, и ты совершенно не знаешь, что происходит там внутри. А мы все хотели бы иметь четко определенный воркфлоу, знать когда и где к нам вернется ответ. На этом уровне наша цель — создать конвейер преобразования данных. Если описывать, что делает то или иное приложение, получается, что оно принимает данные на вход, как-то их обрабатывает при помощи базы данных и выдает то, что получилось, на выход. Если мыслить в терминах преобразования данных, все можно разбить на последовательные шаги. Если предыдущий шаг выполнен успешно, можно переходить к следующему. Если нет, разбираемся с исключениями и ошибками, которые вернул предыдущий шаг. На мой взгляд, все это можно и нужно стандартизировать.
Что посоветуешь почитать начинающим и опытным рубистам?
Рекомендую “Practical Object-Oriented Design in Ruby” от Sandi Metz. Там нет ничего про FP, но это важная книга, которая помогает понять OOP-часть. Было бы неестественно использовать Ruby как чисто функциональный язык, никто не отменял все те хорошие OOP-вещи, которые в Ruby уже есть, и они отлично описаны в книге.
Вторая книга — “Exceptional Ruby” от Avdi Grimm. Это короткая книжка, которая разбирает, почему в экосистеме Ruby мы используем exceptions для сигнализации ошибок. В теории exceptions должны использоваться для действительно исключительных ситуаций, типа “ой, у нас пропала база данных”, но никак для таких вещей как проверка базы данных на консистентность. В новых языках программирования типа Go и Elixir мы никогда не встречаемся с exceptions, только с errors, и это делает виртуальную машину менее тяжелой. А еще такой подход делает код более естественным. Эта короткая, но очень серьёзная книга показывает концепцию, которая сильно повлияла на мой образ мыслей.
Еще я предлагаю почитать о том, как работает функциональное программирование, и что мы можем позаимствовать оттуда. Не могу назвать конкретную книгу, лично я просто учил Elixir по гайдам. Очень полезно иметь представление о том, что происходит вне Ruby-сообщества.
Как бы ты пригласил программистов к участию в Open Source?
Это вопрос отдачи. Например, Rails, как open source проект, бесплатны в том смысле, что мы не платим денег за их использование, но при этом они помогают нам зарабатывать деньги. Поэтому нужно осознать ту ценность, которую принцип open source несёт для разработчика и его компании, и начать отдавать что-то взамен. Это не значит, что следует заниматься open source фултайм — достаточно просто помогать другим время от времени. Я, например, начинал заниматься Hanami по 30 минут каждый день, я вообще большой поклонник концепции маленьких шажочков. Open source не обязан становиться второй работой. Быть open source разработчиком это в большей степени про отношение, а не про конкретные коммиты в проекты. Например, добавить пару слов в устаревшую документацию занимает 5 минут, но может быть очень полезно для сообщества. Нашел баг — заведи issue. А есть еще и меркантильная сторона: то, что ты контрибьютишь в популярные проекты, отлично выглядит в резюме. Да, при таком подходе приходится работать асинхронно, но я думаю что это будущее, которое нас ждет. Учишься быть терпеливым, проникаешься этой философией, привыкаешь адаптироваться под разные условия и концепции. Open source поможет быстрее освоиться на новых местах работы, лучше узнать Ruby, научит читать чужой код. Короче говоря, получаешь очень много навыков, которые здорово помогут тебе текущей работе. Или — найти новую, если заскучаешь на этой. Open source помогает не только быть хорошим программистом, но еще и учит куче важных вещей помимо программирования, которые могут очень сильно пригодиться.
Если вы хотите поговорить с Лукой лично (а это очень вдохновляет!), откладывать покупку билета уже некуда! Регистрация тут, цена билета — 9000 рублей.
Читать интервью на английском — на hype.codes
Спасибо компаниям, которые поддерживают конференцию:
До встречи на RailsClub!
У Павла Аргентова получилось очень интересное интервью с потрясающим человеком. Luca Guidi — семьянин, независимый OSS разработчик, автор Ruby фреймворка Hanami.
Каков твой программистский опыт? Как ты попал во вселенную Ruby?
Программировать я начал ещё подростком, в старших классах школы. Профессиональная карьера стартовала около пятнадцати лет назад — я работал вебдевом на Java, что было ужасно. Это продолжалось пару лет, это была боль. Затем я переключился на Ruby, потому что появились Rails. Rails в те времена произвели революцию: веб-разработка стала сопряжена с меньшими страданиями. С тех самых пор, а это было ещё в эпоху до версии 1.0, Ruby является моим главным языком. Кроме Ruby я изучил Go и пару капель Elixir-а: последний мне интересен, а Go я использую для работы.
Не кажется ли тебе, что Ruby — лучший OO-язык, чем другие языки этой разновидности?
Если смотреть на вещи с позиции объектно-ориентированного программирования, многое в Ruby выглядит для разработчика более натуральным, и да, Ruby — лучший ОО-язык. Думаю, Java в этом отношении подобна эдакому C без изысков. Ruby с самого начала поразил моё воображение тем, что всё есть объект. Даже числа. Начинающему рубисту приходится к этому привыкать, но усвоив это положение, получаешь доступ ко всевозможным трюкам вроде полиморфизма: например, передаёшь по цепочке объекты, которые ведут себя как целые числа. Образуется приятная гибкость в проектировании сигнатур методов при возможности максимальной сосредоточенности на имплементации.
С другой стороны, я думаю что Ruby напрасно лишён интерфейсов. Из-за этого невозможно строго определить, какое именно поведение ожидается от метода, что было бы особенно полезно для авторов библиотек. Я надеюсь когда-нибудь это починят. Также не думаю, что в будущем Ruby сыграют заметную роль библиотеки, в которых будет реализовано то, чего нет в ядре языка. Новые фичи по-настоящему заработают только тогда, когда станут частью ядра Ruby. И конечно, реализация должна быть сделана как следует.
Каковы, по твоему мнению, сильные и слабые стороны Ruby? Есть ли в Ruby жизнь вне Rails?
Исторически сложилось, что самая сильная сторона Rails — монолитность, сам факт, что “Рельсы” стали “большой” платформой. Это сыграло свою роль не только в экосистеме Ruby, но и в индустрии веб-разработки в целом.
Можно заметить, что с приходом Rails язык получил невероятное распространение. Огромное количество людей стали его использовать. Это сформировало к Ruby должное доверие. Плохо то, что Rails целиком поглотили Ruby, что создало излишнее единообразие. Есть куча программистов, которые знают Rails, но совсем не знают Ruby как язык. Куча гемов по умолчанию подразумевает, что ты используешь Rails. Такая ситуация может здорово навредить языку. Если попытаться работать вне Rails, например с Hanami или с системной автоматизацией, обязательно возникнут проблемы.Так что скажу, что Rails это и главное благословение, и в то же время главное проклятие для Ruby комьюнити.
Продолжая тему борьбы добра со злом, скажу, что в Ruby сейчас самый удачный момент для развития экосистемы. Хорошая новость в том, что если у тебя в руках 5-8-летнее Rails-приложение, то несмотря на некоторые проблемы с переходом на новые версии Rails, все работает — потому что изначальные приёмы работы с фреймворком не менялись уже более десятилетия. Поэтому у тебя все ок. Плохая новость — экосистема и язык, которые принципиально не эволюционируют и предлагают только один путь решения всех задач, в конце концов сойдут на нет. Тем не менее, сейчас происходит много вещей, полезных в этом отношении. Во-первых, Hanami в этом году дошел до версии 1.0; все больше приложений начинают использовать его в продакшн. Во-вторых, ROM, у которого вышла уже версия 4.0. В третьих, Dry-rb — набор компактных библиотек для таких вещей, как обработка данных и тому подобного. Развитие всего этого — отличная новость. У нас появляется выбор: если тебе как разработчику подходят Rails — Rails даст уверенность. Если же Rails не подходит — есть рабочие альтернативы.
Ты написал Hanami. Зачем нам еще один web framework?
В экосистеме Ruby уже довольно много веб фреймворков, но почти все они являются клонами Sinatra. Hanami отличается тем, что не повторяет Sinatra. Он впитывает хорошие идеи Rails и приводит в порядок те моменты, которые стоит улучшить. Я хочу посоветовать даже тем, кто не планирует переходить с Rails никогда и никуда, пристально посмотреть на Hanami и другие фреймворки, чтобы научиться чему-то новому.
Какие гемы/идеи ты считаешь наиболее полезными в Ruby?
Напоминаю про ROM and Dry-rb — это очень интересная смесь функционального и объектного программирования. Особенно это заметно в библиотеках Dry. Они очень круты, считаю что всем нужно обратить на них внимание. Причём, не из-за хайпа, а потому что это поможет понять многое про иммутабельность и детерминированные объекты. Важно уметь конструировать сущности так, чтобы подавая что-то на вход, на выходе мы получали предсказуемый результат.
На что в FP, по твоему, стоит обратить внимание рубистам, которые в основном занимаются OOP?
Снова, иммутабельность и композиция. Не обязательно под соусом чистых функций. Определенно стоит посмотреть, как устроен Elixir. Моя идея заключается в том, что стоит сочетать FP и OOP. Пример, который я могу привести — функциональные объекты. Это объекты, которые, подобно функции, принимают на вход некоторые данные и возвращают результат, но кроме всего прочего имеют некоторое хранимое состояние или способ вызова, при котором нет необходимости постоянно передавать всё это состояние и прочие зависимости в параметрах. В то же время, по определению, функциональный объект призван качественно выполнять одну единственную задачу, что согласуется с принципом single responsibility.
Таким образом, сочетая композицию и иммутабельность, функциональный объект всегда ведет себя предсказуемо. Это все еще экспериментальная и спорная концепция, но именно это я и хочу показать в своем докладе на RailsClub. Это будет доклад про наше будущее — про новый способ делать веб-приложения с Hanami.
Так о чем же ты будешь говорить на RailsClub?
Буду говорить о том, как совмещать OOP и FP. Как это стало движущей идеей в Hanami 1.0. Если конкретнее, то я буду говорить об actions. Actions — это объекты, которые “показывают” один единственный метод, принимающий ввод и возвращающий вывод — HTTP-response, отвечающий спецификации Rack. Есть ещё валидаторы, которые ведут себя аналогичным образом. Идея в том, чтобы оценить то, что мы имеем сейчас — и стандартизировать поведение в версии 2.0. Ещё идея — пытаться построить приложение для каждого юзкейса, для каждой фичи, которая есть в монолитных приложениях — сделать что-то вроде конвейера из функций, скомбинированных друг с другом. Когда принимаешь данные на вход, валидируешь, приводишь типы, манипулируешь, обрабатываешь и потом возвращаешь что-то пользователю. Что-то такое я и хочу показать, хочу стандартизировать находящийся в нашем распоряжении набор объектов. Это уже выходит за пределы MVC, потому что в MVC ты делаешь запрос к контроллеру, ты делаешь бла-бла-бла, и ты совершенно не знаешь, что происходит там внутри. А мы все хотели бы иметь четко определенный воркфлоу, знать когда и где к нам вернется ответ. На этом уровне наша цель — создать конвейер преобразования данных. Если описывать, что делает то или иное приложение, получается, что оно принимает данные на вход, как-то их обрабатывает при помощи базы данных и выдает то, что получилось, на выход. Если мыслить в терминах преобразования данных, все можно разбить на последовательные шаги. Если предыдущий шаг выполнен успешно, можно переходить к следующему. Если нет, разбираемся с исключениями и ошибками, которые вернул предыдущий шаг. На мой взгляд, все это можно и нужно стандартизировать.
Что посоветуешь почитать начинающим и опытным рубистам?
Рекомендую “Practical Object-Oriented Design in Ruby” от Sandi Metz. Там нет ничего про FP, но это важная книга, которая помогает понять OOP-часть. Было бы неестественно использовать Ruby как чисто функциональный язык, никто не отменял все те хорошие OOP-вещи, которые в Ruby уже есть, и они отлично описаны в книге.
Вторая книга — “Exceptional Ruby” от Avdi Grimm. Это короткая книжка, которая разбирает, почему в экосистеме Ruby мы используем exceptions для сигнализации ошибок. В теории exceptions должны использоваться для действительно исключительных ситуаций, типа “ой, у нас пропала база данных”, но никак для таких вещей как проверка базы данных на консистентность. В новых языках программирования типа Go и Elixir мы никогда не встречаемся с exceptions, только с errors, и это делает виртуальную машину менее тяжелой. А еще такой подход делает код более естественным. Эта короткая, но очень серьёзная книга показывает концепцию, которая сильно повлияла на мой образ мыслей.
Еще я предлагаю почитать о том, как работает функциональное программирование, и что мы можем позаимствовать оттуда. Не могу назвать конкретную книгу, лично я просто учил Elixir по гайдам. Очень полезно иметь представление о том, что происходит вне Ruby-сообщества.
Как бы ты пригласил программистов к участию в Open Source?
Это вопрос отдачи. Например, Rails, как open source проект, бесплатны в том смысле, что мы не платим денег за их использование, но при этом они помогают нам зарабатывать деньги. Поэтому нужно осознать ту ценность, которую принцип open source несёт для разработчика и его компании, и начать отдавать что-то взамен. Это не значит, что следует заниматься open source фултайм — достаточно просто помогать другим время от времени. Я, например, начинал заниматься Hanami по 30 минут каждый день, я вообще большой поклонник концепции маленьких шажочков. Open source не обязан становиться второй работой. Быть open source разработчиком это в большей степени про отношение, а не про конкретные коммиты в проекты. Например, добавить пару слов в устаревшую документацию занимает 5 минут, но может быть очень полезно для сообщества. Нашел баг — заведи issue. А есть еще и меркантильная сторона: то, что ты контрибьютишь в популярные проекты, отлично выглядит в резюме. Да, при таком подходе приходится работать асинхронно, но я думаю что это будущее, которое нас ждет. Учишься быть терпеливым, проникаешься этой философией, привыкаешь адаптироваться под разные условия и концепции. Open source поможет быстрее освоиться на новых местах работы, лучше узнать Ruby, научит читать чужой код. Короче говоря, получаешь очень много навыков, которые здорово помогут тебе текущей работе. Или — найти новую, если заскучаешь на этой. Open source помогает не только быть хорошим программистом, но еще и учит куче важных вещей помимо программирования, которые могут очень сильно пригодиться.
Если вы хотите поговорить с Лукой лично (а это очень вдохновляет!), откладывать покупку билета уже некуда! Регистрация тут, цена билета — 9000 рублей.
Читать интервью на английском — на hype.codes
Спасибо компаниям, которые поддерживают конференцию:
Генеральный партнер: Toptal
Золотой партнер: Лига Цифровой Экономики
Бронзовые партнеры: Mkdev, VoltMobi, Рево, InSales
До встречи на RailsClub!
