Отсчет до конференции RailsClub 2017 идет на дни, а мы продолжаем публиковать разговоры с нашими спикерами. Павел Аргентов расспросил Никиту Шильникова, разработчика Dry-rb и Rom-rb, о работе, книгах и состоянии дел в Ruby-сообществе.
Как ты начал программировать на Ruby?
Все было просто. Я до этого не программировал за деньги. Вначале я был менеджером, и мне предложили работать программистом. Я пошел. Там были Ruby и Oracle (они там и сейчас есть). С тех пор я так в одном месте и работаю, уже 7 лет, переключаясь между задачами.
У тебя есть “профподготовка” или ты учился сам?
У меня техническое образование. В институте я изучал C++, Prolog и ассемблер. До того, как я устроился на работу, я знал Javascript и С++, постольку-поскольку.
Ты сразу занялся веб-разработкой, или было что-то другое?
Там, куда я пришёл работать, был веб, были рельсы. Ядро системы было в Oracle, а интерфейс на Rails, плюс немного Javascript-а. Rails неплохо работают с “хранимками”, ну то есть когда в них нет бизнес-логики :) (хранимые процедуры — П.А.).
Сейчас ты так и работаешь в вебдеве?
Фактически да.
А как ты вышел на опенсорс?
На одной конференции — точно не помню — вроде DevConf, была секция про Ruby. Там Кирилл Мокевнин рассказывал про DDD, и я понял, что все, чем мы на работе занимаемся — это Domain Driven Design. Кирилл рассказал что в ActiveRecord есть проблемы с отображением сущностей предметной области на реляционную базу, что есть ребята, которые делают ROM, а сначала сделали DataMapper. Это меня заинтересовало, и с того времени (2012 год) я начал следить за ROM. В 2015 году вышла версия 1.0. Мне как раз подвернулся новый проект — я использовал Rails, потому что уже с ними работал. Выкинул оттуда ActiveRecord, вставил ROM и начал с этим бороться. В ходе этой борьбы я пришел к коммитам в опенсорс-проекты ROM и dry-rb.
ROM и dry-rb известны заимствованиями из FP. Как ты считаешь, насколько важно добавлять в Ruby приемы функционального программирования?
Я не фанат какого-то конкретного языка программирования. Я за то, чтобы для каждой задачи выбирать подходящий инструмент. Есть языки общего назначения, которые могут решать разные задачи, и в них есть сильные и слабые стороны. Сам Ruby, который появился больше 20 лет назад, изначально был объектно-ориентированным. Однако на него оказал очень сильное влияние LISP. Даже Матц говорил, что хотел сделать смесь Perl и LISP. А LISP — это первый функциональный язык. Выходит, если покопаться поглубже, у Ruby есть функциональные предки. Мне кажется, мы так зациклились на ООП, что не дали развиваться в Ruby другим инструментам. Я считаю, что нужно посмотреть на другие языки программирования и заимствовать то, применимо к Ruby. Можно ли совместить FP и OOP? Мы пробуем.
А почему dry gems называются именно DRY?
Вообще, это просто trademark. Суть гемов — решать отдельные задачи. К примеру, dry-types описывает типы, типы можно переиспользовать разными способами в разных местах. В этом один из смыслов названия.
В какую сторону будет развиваться Ruby вообще и рельсы в частности?
Стандартный вопрос. Матц, например, боится того, что случилось с питоном: с Python 2 на Python 3 был слишком большой скачок, не хотелось бы такого повторения в Ruby. А вот переход с Ruby 1.8 на 1.9 был ощутимым, но не болезненным. Я не думаю, что в Ruby будут серьезные изменения, которые сломают обратную совместимость. Про Rails не могу сказать чего-то конкретного.
Чего, на твой взгляд, не хватает в Ruby?
Тут могу сказать вполне определенно чего не хватает мне: pattern matching. Помимо приложений я пишу библиотечный код — там использовать pattern matching было бы просто здорово. С точки зрения приложений можно добавить примитивы многопоточного программирования, избавиться от GIL. Еще не хватает немутабельных структур: идея немутабельности позволяет размышлять о коде гораздо проще, а это было бы полезно для новичков. В dry-struct, например, мы эмулировали немутабельность. Наверное, было бы здорово, если такие инструменты были и в самом языке.
На твой взгляд, самые заметные явления в экосистеме Ruby кроме dry и rom?
Hanami — очень интересный проект. Это нужный инструмент с хорошей документацией, который понятно где и как использовать. Это очень здорово, что у нас появилась альтернатива рельсам, и она не заключается в создании доморощенного фреймворка.
Зачем же нам очередные рельсы?
Я повидал всякого, работая над одним большим проектом. Начинал с выкидывания SQL из шаблонов. В рельсах вообще есть много вопросов без ответа — о том, как развивать большой и долгий проект. Мы научились с этим работать но не пришли к единым стандартам, поэтому было бы круто иметь фреймворк, где все что, нужно, стандартизировано. Серьёзная проблема в Rails — ActiveRecord, спорный паттерн с определенными недостатками. Например, с него сложно слезать. А еще, чем больше “прячешь” от него бизнес-логику, тем он лучше работает.
Какие ты мог бы посоветовать сайты\курсы\книжки для начинающих и для опытных рубистов?
Я бы посоветовал новичкам работать со сложными книгами так: прочитать первый раз, чтобы что-то отложилось в голове, и по мере работы возвращаться к ней как к справочнику. Отличный пример — “Шаблоны проектирования архитектуры корпоративных приложений” Мартина Фаулера. Книга написана в 2002 году и до сих пор актуальна, многие классы в рельсах реализуют какие-то паттерны из нее. Лично у меня на первое место сейчас вышла другая книга для опытных программистов — Martin Kleppmann, “Designing Data-Intensive Applications”. Это не очень глубокая, но отлично написанная книга, с кучей ссылок по интересующим темам. Автор занимается в основном изучением распределенных систем, он писал эту книгу 4 года, и она посвящена работе с данными в различных системах. Там дано внятное, хорошее описание многих аспектов работе с данными, и она не привязана к конкретному языку. Если хочется повысить свой уровень как разработчика, это самое то.
Назови самую большую проблему Ruby сообщества?
Нам нужно показать, что мы все еще не раскрыли весь потенциал языка, и, хотя ему уже 20 с лишним лет, мы можем применять новые подходы как в старых задачах, так и в новых, развивающихся областях!
Интересно? А в докладе Никиты про типы в Ruby будет еще интереснее! Откладывать покупку билета уже некуда, остались последние места! Регистрация тут, цена билета — 9000 рублей.
Организатор конференции: Evrone
Спасибо лучшим компаниям, которые нас поддерживают! Например, Рево — международной fintech компании, которая более 5 лет создаёт передовой сервис оплаты частями в партнёрстве с крупнейшими торговыми сетями и интернет магазинами. Никакого пластика. Никаких бумаг. Просто. Быстро. Современно.
Ждем вас на конференции, до встречи!
Как ты начал программировать на Ruby?
Все было просто. Я до этого не программировал за деньги. Вначале я был менеджером, и мне предложили работать программистом. Я пошел. Там были Ruby и Oracle (они там и сейчас есть). С тех пор я так в одном месте и работаю, уже 7 лет, переключаясь между задачами.
У тебя есть “профподготовка” или ты учился сам?
У меня техническое образование. В институте я изучал C++, Prolog и ассемблер. До того, как я устроился на работу, я знал Javascript и С++, постольку-поскольку.
Ты сразу занялся веб-разработкой, или было что-то другое?
Там, куда я пришёл работать, был веб, были рельсы. Ядро системы было в Oracle, а интерфейс на Rails, плюс немного Javascript-а. Rails неплохо работают с “хранимками”, ну то есть когда в них нет бизнес-логики :) (хранимые процедуры — П.А.).
Сейчас ты так и работаешь в вебдеве?
Фактически да.
А как ты вышел на опенсорс?
На одной конференции — точно не помню — вроде DevConf, была секция про Ruby. Там Кирилл Мокевнин рассказывал про DDD, и я понял, что все, чем мы на работе занимаемся — это Domain Driven Design. Кирилл рассказал что в ActiveRecord есть проблемы с отображением сущностей предметной области на реляционную базу, что есть ребята, которые делают ROM, а сначала сделали DataMapper. Это меня заинтересовало, и с того времени (2012 год) я начал следить за ROM. В 2015 году вышла версия 1.0. Мне как раз подвернулся новый проект — я использовал Rails, потому что уже с ними работал. Выкинул оттуда ActiveRecord, вставил ROM и начал с этим бороться. В ходе этой борьбы я пришел к коммитам в опенсорс-проекты ROM и dry-rb.
ROM и dry-rb известны заимствованиями из FP. Как ты считаешь, насколько важно добавлять в Ruby приемы функционального программирования?
Я не фанат какого-то конкретного языка программирования. Я за то, чтобы для каждой задачи выбирать подходящий инструмент. Есть языки общего назначения, которые могут решать разные задачи, и в них есть сильные и слабые стороны. Сам Ruby, который появился больше 20 лет назад, изначально был объектно-ориентированным. Однако на него оказал очень сильное влияние LISP. Даже Матц говорил, что хотел сделать смесь Perl и LISP. А LISP — это первый функциональный язык. Выходит, если покопаться поглубже, у Ruby есть функциональные предки. Мне кажется, мы так зациклились на ООП, что не дали развиваться в Ruby другим инструментам. Я считаю, что нужно посмотреть на другие языки программирования и заимствовать то, применимо к Ruby. Можно ли совместить FP и OOP? Мы пробуем.
А почему dry gems называются именно DRY?
Вообще, это просто trademark. Суть гемов — решать отдельные задачи. К примеру, dry-types описывает типы, типы можно переиспользовать разными способами в разных местах. В этом один из смыслов названия.
В какую сторону будет развиваться Ruby вообще и рельсы в частности?
Стандартный вопрос. Матц, например, боится того, что случилось с питоном: с Python 2 на Python 3 был слишком большой скачок, не хотелось бы такого повторения в Ruby. А вот переход с Ruby 1.8 на 1.9 был ощутимым, но не болезненным. Я не думаю, что в Ruby будут серьезные изменения, которые сломают обратную совместимость. Про Rails не могу сказать чего-то конкретного.
Чего, на твой взгляд, не хватает в Ruby?
Тут могу сказать вполне определенно чего не хватает мне: pattern matching. Помимо приложений я пишу библиотечный код — там использовать pattern matching было бы просто здорово. С точки зрения приложений можно добавить примитивы многопоточного программирования, избавиться от GIL. Еще не хватает немутабельных структур: идея немутабельности позволяет размышлять о коде гораздо проще, а это было бы полезно для новичков. В dry-struct, например, мы эмулировали немутабельность. Наверное, было бы здорово, если такие инструменты были и в самом языке.
На твой взгляд, самые заметные явления в экосистеме Ruby кроме dry и rom?
Hanami — очень интересный проект. Это нужный инструмент с хорошей документацией, который понятно где и как использовать. Это очень здорово, что у нас появилась альтернатива рельсам, и она не заключается в создании доморощенного фреймворка.
Зачем же нам очередные рельсы?
Я повидал всякого, работая над одним большим проектом. Начинал с выкидывания SQL из шаблонов. В рельсах вообще есть много вопросов без ответа — о том, как развивать большой и долгий проект. Мы научились с этим работать но не пришли к единым стандартам, поэтому было бы круто иметь фреймворк, где все что, нужно, стандартизировано. Серьёзная проблема в Rails — ActiveRecord, спорный паттерн с определенными недостатками. Например, с него сложно слезать. А еще, чем больше “прячешь” от него бизнес-логику, тем он лучше работает.
Какие ты мог бы посоветовать сайты\курсы\книжки для начинающих и для опытных рубистов?
Я бы посоветовал новичкам работать со сложными книгами так: прочитать первый раз, чтобы что-то отложилось в голове, и по мере работы возвращаться к ней как к справочнику. Отличный пример — “Шаблоны проектирования архитектуры корпоративных приложений” Мартина Фаулера. Книга написана в 2002 году и до сих пор актуальна, многие классы в рельсах реализуют какие-то паттерны из нее. Лично у меня на первое место сейчас вышла другая книга для опытных программистов — Martin Kleppmann, “Designing Data-Intensive Applications”. Это не очень глубокая, но отлично написанная книга, с кучей ссылок по интересующим темам. Автор занимается в основном изучением распределенных систем, он писал эту книгу 4 года, и она посвящена работе с данными в различных системах. Там дано внятное, хорошее описание многих аспектов работе с данными, и она не привязана к конкретному языку. Если хочется повысить свой уровень как разработчика, это самое то.
Назови самую большую проблему Ruby сообщества?
Нам нужно показать, что мы все еще не раскрыли весь потенциал языка, и, хотя ему уже 20 с лишним лет, мы можем применять новые подходы как в старых задачах, так и в новых, развивающихся областях!
Интересно? А в докладе Никиты про типы в Ruby будет еще интереснее! Откладывать покупку билета уже некуда, остались последние места! Регистрация тут, цена билета — 9000 рублей.
Организатор конференции: Evrone
Спасибо лучшим компаниям, которые нас поддерживают! Например, Рево — международной fintech компании, которая более 5 лет создаёт передовой сервис оплаты частями в партнёрстве с крупнейшими торговыми сетями и интернет магазинами. Никакого пластика. Никаких бумаг. Просто. Быстро. Современно.
Ждем вас на конференции, до встречи!
