Привет!
Уже в конце этой недели состоится конференция RailsClub. Наши гости собирают чемоданы (вот и Аарон Паттерсон написал в своем твиттере, что едет в Россию). А мы с нетерпением ждем встречи с вами!
Мы задали пару вопросов о жизни и программировании разработчику в Evil Martians, ведущему разработчику Oh My Stats Равилю Байрамгалину. Равиль контрибьютор больше 40 опенсорсных проектов, среди которых Ruby on Rails, rack, cassandra-rb, sidekiq и другие. Получилось интересно!
Над чем ты сейчас работаешь?
Из интересного работаю над прототипом системы очередей со специфичным набором плюсов и минусов, остальное секрет :D
Что является лучшей и худшей частью твоей работы?
Лучшей частью являются анализ и размышления. Над чем — архитектурой, АПИ, организацией кода, оптимизациями или багами — неважно. Худшая часть — это когда попадаются простые шаблонные задачи, но объемные по временным затратам.
Что ты считаешь своим главным достижением в жизни / карьере на данный момент?
Возможность обнять Аарон Патерсона в скором будущем. Непреднамеренный ддос гитхаба во время рельс рамбла после запуска нашего краулера на нескольких сотнях heroku-серверов — тоже было памятным событием ;)
На твой взгляд, в каком направлении будут развиваться Ruby и Ruby on Rails в ближайшие годы?
Начну с руби.
Ближайшее направление, в котором последуют новые большие изменения — это конкуренси. Как всем уже известно, Матц несколько месяцев назад писал, что хочет добавить в язык новую абстракцию для конкуренси и убрать GIL.
В сообществе идеи на первую тему уже давно довольно успешно исследуются (в итоге у нас есть гем concurrent-ruby с очень сильной командой разработчиков, который предоставляет всевозможные примитивы и абстракции для конкуренси (в том числе и более экзотические, например, software transactional memory и dataflow)).
Но решение убрать GIL свидетельствует о серьезности изменений, а не простом копировании какой-то библиотеки в ядро руби. И речь идет не о более мелких локах, которые Матц отвергал на протяжении долгого времени. Судя по последним презентациям Koichi Sasada (ko1, один из трех членов команды Матца), нас ожидает модель с раздельной памятью и ограниченным регионом общей памяти. Раздельная память будет представлена, скорее всего, с помощью актеров. Доступ к общей памяти будет, видимо, с каким-то защитным механизмом, чтобы из актеров не получилось обычных тредов с дополнительным режимом коммуникаций. Но не уверен, что такой компромис на практике сработает.
Предложение от Tony Arcieri (известен больше всего по celluloid): возможность привязывать связанные объекты к конкретному треду (с автоматическом рейзом ошибки при обращении из других тредов) — позволило бы текущим реализациям актеров и каналов решить проблему с изоляцией данных между тредами весьма эффективным и простым способом.
Неважно, какой в итоге способ будет выбран, главное что начало диалогу в области конкуренси положено, а предыдущие обсуждения (например, с рефайнментами) показывают, что Матц готов к конструктивному диалогу (надеюсь, протолкнут формализованную модель памяти).
Не стоит бояться или надеяться на радикальные решения. Принимаемые Матцом решения достаточно эволюционны, чтобы все сообщество двигалось вперед и не фрагментировалось по версиям из-за трудностей перехода.
Поэтому в области больших изменений языка, наверное, это все на ближайшее время. Надо дать время, чтобы общество не просто поддерживало руби 2.x, но и сформировался консенсус по использованию нового функционала, например, keywords, prepend, refinements. Поэтому новость о том, что в 5 рельсах будут поддерживать только руби 2.2+ радует.
Что будет среди мелких изменений, гадать не буду, благо, в каждом релизе таких изменений, сформированных в результате фидбека от сообщества, хватает. Главное, что постепенная модернизация стдлиб идет.
Зато в области развития самой MRI и дополнительных средств для анализа рантайма все будет и дальше лучше с каждой версией.
Теперь трейсить и мониторить исполнение методов и аллокаций объектов в руби проще чем когда-либо с помощью гема stackprof (автор — инженер гитхаба и контрибутор руби Aman Gupta), не хватает лишь веб интерфейса для более простого интерактивного анализа профайл-дампов.
Из грядущего нас ожидает, скорее всего, JIT-компилятор для MRI от Koichi, хотя Матц не исключает и AOT.
Несмотря на эти хорошие новости, я связываю будущее развитие руби с jruby. Но не просто jruby, а поверх truffle (в комбинации с graal и substrate VM). Нашему сообществу значительно повезло, что талантливые ребята из отдела Oracle Labs VM Research решили обкатать свои теоретические наработки в области разработки и оптимизации ВМ на руби. Рекомендую следить за блогом Chris Seaton, который объясняет, как они на порядок ускоряют руби. Еще одно отличие от обычного jruby состоит в поддержке C-расширений без деградации скорости. Надеюсь, увидеть публичный релиз в 2015 году. В планах на чуть более далекое будущее достичь время стартапа как у MRI (что, как демонстрирует прототип функциональности, достижимо).
Про рельсы.
От 5-ых рельс, которые будут этой весной, ожидаю, в основном, поверхностное обновление АПИ, связанное с уже упомянутым прекращением поддержки предыдущих версий руби. Больше символов, проще логика с prepend, чище методы с keyword arguments и тому подобное.
Надеюсь, под руководством Аарона Патерсона rack 2.0 будет доведен до ума. Поддерживать стриминг без костылей — это самая простая постановка задачи. В конце года выйдет стабильная спецификация HTTP 2.0 и формата request-response даже со стримингом недостаточно. Нативная поддержка семантики HTTP, как пытаются сделать webmachine и http-2 гемы, упрощает решение разных специфичных задач, но усложняет общее АПИ — сложность, как обычно, в поиске компромиса.
Параллельно с рельсами будет развиваться и дальше сопутствующая инфраструктура. На базе докера появятся инструменты для девелопмента, которые, с одной стороны, полностью предоставляют все необходимые сервисы и библиотеки для приложения (включая версию руби), при этом, с другой стороны, работа с ними будет абсолютно прозрачной: зашел в папку проекта, написал setup и у тебя поднялись все необходимые сервисы, а бинарники ruby, bundle, rails и остальные проксируются к запущенному образу. Система девелопера всегда чистая, проект всегда готов к запуску на любой системе, при этом разницы между разработкой никакой. В области деплоя переход на докер тоже может принести много бенефитов, но для этого нужен более высокоуровневый инструмент поверх него, который будет отвечать за развертывание, проксирование для переключения и ролбека без даунтайма, сбор логов, контроль крона и тому подобное.
Формирование новых конвенций для рельс-приложений далеко от завершения, общие идеи понятны, но общепринятого консенсуса по деталям пока нет. Более комплексные подходы, такие как гем trailblazer, имеют больше шансов на распространение, так как многие конвенции лучше всего работают в связке. В этом же геме есть идея концепций, которая может прижиться в сообществе, в котором хотят достичь большей модульности, но не всегда готовы к оверхеду полноценных сервисов или в ситуациях, когда обычные энджайны рассматриваются как оверкил.
Возможно, в дальнейшем поверх стриминга в рельсы добавят абстракции для построения датафлоу с клиентом (пока эксперименты с реактивной связью между сервером и клиентом вызывают довольно широкий интерес, даже если смотреть только в рамках руби сообщества, то voltrb стал популярным довольно быстро, хоть и находится на очень ранней стадии разработки).
Это первое, что пришло в голову. Если подумать, интересных направлений и разработок ведется очень много и говорить о них можно долго, буду рад пообщаться на рельсклабе с желающими :)
В чём, на твой взгляд, самая важная проблема, которая стоит сейчас перед сообществом разработчиков Ruby и Ruby on Rails?
На мой взгляд, это размытие культуры опенсорса. Важно помнить, что экосистема формируется руками сообщества и долг каждого ее развивать. Много людей просто работают и пытаются обойти проблемы экосистемы и опенсорса (порой с едкой критикой), вместо того, чтобы участвовать в их решении.
Как это решить — не знаю. Казалось бы, руби и так располагает к тому, чтобы было легко исследовать рантайм и решать проблемы, но значит нужны инструменты, чтобы сделать это еще проще. Было бы прекрасно, хоть и несбыточно, если бы в _why день была традиция на уровне рабочего этикета, чтобы вместо работы каждый руби-програмист мог потратить время и попытаться разобраться в проблеме, с которой ему довелось столкнуться. С наличием менторов внутри компании или на irc-канале. А потом повсеместные публикации на тему того, что сделали, для дальнейшего распространения духа. Казалось бы, один день в году, но для того, чтобы начать больше и не надо, при этом часто это самое сложное.
Есть гем, на который ты мог бы показать пальцем и сказать: “Вот так нужно писать код”?
Гем — это результат коллективной работы, а код с определенным почерком — отражение стиля индивидуума, поэтому я просто перечислю гитхаб-ники нескольких из тех, что в голову придут: evanphx, eregon, banister, dkubb, ConradIrwin, amatsuda, mbj, solnic, jeremyevans.
Ты много контрибьютишь в open source. Зачем это делаешь ты и почему это стоило бы делать другим?
Я делаю это, когда сталкиваюсь с проблемами и есть свободное время. В марсианах работа с открытым кодом почти обязательна, так что вдобавок к возможности обосновать трату рабочего времени на опенсорс, есть периодические материальные конкурсы и бонусы.
Вообще рекомендую остальным, так как маленькими шажками все сообщество движется вперед, плюс придется хорошо разобраться в проблематике, то есть прокачать свой скил.
Что ты читаешь о Ruby/RoR? Блог, ресурс, книга?
Разные блоги, твиттеры, рассылки, мейллисты, которые накопились в большом количестве за долгое время.
Бывает стыдно за код, который ты написал несколько лет назад?
Не бывает — если сейчас написал бы по-другому, то это означает наличие новой информации в моем сознании, но все знать невозможно, поэтому стыдиться незнания не стоит, главное — вкладывать душу :)
Чем тебе нравится заниматься кроме программирования?
Читать про современные экономические реформы и критиковать текущее правительство :D
Спасибо за интервью!
На конференции Равиль расскажет о Big Data: 27 сентября, в центре Digital October. Вся программа — на сайте RailsClub 2014 .
Регистрация и оплата участия — тут.
Билетов осталось совсем мало!
Наши спонсоры:
Генеральный спонсор — Toptal
Золотые спонсоры: Boookmate и FunBox
Серебряные спонсоры: AT-Consulting и Lookatme
HR-партнер: DigitalHR
Организаторы:
Undev.ru — сильная команда разработчиков на Ruby, Objective C, C++, C#, JavaScript. Работают над созданием уникальной технологической платформы для телевизионного вещания через интернет. На базе этой платформы были сделаны такие крупные проекты, как Веб-выборы 2012, ПМЭФ, трансляция ванкуверской и лондонской олимпиад, и еще несколько проектов аналогичного масштаба.
Evrone — команда разработчиков на RoR, Clojure и Scala. Энтузиасты сообщества и бессменные организаторы RailsClub.
Будьте в курсе наших новостей, подписавшись на рассылку на сайте railsclub.ru, и следите за обновлениями:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub
Уже в конце этой недели состоится конференция RailsClub. Наши гости собирают чемоданы (вот и Аарон Паттерсон написал в своем твиттере, что едет в Россию). А мы с нетерпением ждем встречи с вами!
Мы задали пару вопросов о жизни и программировании разработчику в Evil Martians, ведущему разработчику Oh My Stats Равилю Байрамгалину. Равиль контрибьютор больше 40 опенсорсных проектов, среди которых Ruby on Rails, rack, cassandra-rb, sidekiq и другие. Получилось интересно!
Над чем ты сейчас работаешь?
Из интересного работаю над прототипом системы очередей со специфичным набором плюсов и минусов, остальное секрет :D
Что является лучшей и худшей частью твоей работы?
Лучшей частью являются анализ и размышления. Над чем — архитектурой, АПИ, организацией кода, оптимизациями или багами — неважно. Худшая часть — это когда попадаются простые шаблонные задачи, но объемные по временным затратам.
Что ты считаешь своим главным достижением в жизни / карьере на данный момент?
Возможность обнять Аарон Патерсона в скором будущем. Непреднамеренный ддос гитхаба во время рельс рамбла после запуска нашего краулера на нескольких сотнях heroku-серверов — тоже было памятным событием ;)
На твой взгляд, в каком направлении будут развиваться Ruby и Ruby on Rails в ближайшие годы?
Начну с руби.
Ближайшее направление, в котором последуют новые большие изменения — это конкуренси. Как всем уже известно, Матц несколько месяцев назад писал, что хочет добавить в язык новую абстракцию для конкуренси и убрать GIL.
В сообществе идеи на первую тему уже давно довольно успешно исследуются (в итоге у нас есть гем concurrent-ruby с очень сильной командой разработчиков, который предоставляет всевозможные примитивы и абстракции для конкуренси (в том числе и более экзотические, например, software transactional memory и dataflow)).
Но решение убрать GIL свидетельствует о серьезности изменений, а не простом копировании какой-то библиотеки в ядро руби. И речь идет не о более мелких локах, которые Матц отвергал на протяжении долгого времени. Судя по последним презентациям Koichi Sasada (ko1, один из трех членов команды Матца), нас ожидает модель с раздельной памятью и ограниченным регионом общей памяти. Раздельная память будет представлена, скорее всего, с помощью актеров. Доступ к общей памяти будет, видимо, с каким-то защитным механизмом, чтобы из актеров не получилось обычных тредов с дополнительным режимом коммуникаций. Но не уверен, что такой компромис на практике сработает.
Предложение от Tony Arcieri (известен больше всего по celluloid): возможность привязывать связанные объекты к конкретному треду (с автоматическом рейзом ошибки при обращении из других тредов) — позволило бы текущим реализациям актеров и каналов решить проблему с изоляцией данных между тредами весьма эффективным и простым способом.
Неважно, какой в итоге способ будет выбран, главное что начало диалогу в области конкуренси положено, а предыдущие обсуждения (например, с рефайнментами) показывают, что Матц готов к конструктивному диалогу (надеюсь, протолкнут формализованную модель памяти).
Не стоит бояться или надеяться на радикальные решения. Принимаемые Матцом решения достаточно эволюционны, чтобы все сообщество двигалось вперед и не фрагментировалось по версиям из-за трудностей перехода.
Поэтому в области больших изменений языка, наверное, это все на ближайшее время. Надо дать время, чтобы общество не просто поддерживало руби 2.x, но и сформировался консенсус по использованию нового функционала, например, keywords, prepend, refinements. Поэтому новость о том, что в 5 рельсах будут поддерживать только руби 2.2+ радует.
Что будет среди мелких изменений, гадать не буду, благо, в каждом релизе таких изменений, сформированных в результате фидбека от сообщества, хватает. Главное, что постепенная модернизация стдлиб идет.
Зато в области развития самой MRI и дополнительных средств для анализа рантайма все будет и дальше лучше с каждой версией.
Теперь трейсить и мониторить исполнение методов и аллокаций объектов в руби проще чем когда-либо с помощью гема stackprof (автор — инженер гитхаба и контрибутор руби Aman Gupta), не хватает лишь веб интерфейса для более простого интерактивного анализа профайл-дампов.
Из грядущего нас ожидает, скорее всего, JIT-компилятор для MRI от Koichi, хотя Матц не исключает и AOT.
Несмотря на эти хорошие новости, я связываю будущее развитие руби с jruby. Но не просто jruby, а поверх truffle (в комбинации с graal и substrate VM). Нашему сообществу значительно повезло, что талантливые ребята из отдела Oracle Labs VM Research решили обкатать свои теоретические наработки в области разработки и оптимизации ВМ на руби. Рекомендую следить за блогом Chris Seaton, который объясняет, как они на порядок ускоряют руби. Еще одно отличие от обычного jruby состоит в поддержке C-расширений без деградации скорости. Надеюсь, увидеть публичный релиз в 2015 году. В планах на чуть более далекое будущее достичь время стартапа как у MRI (что, как демонстрирует прототип функциональности, достижимо).
Про рельсы.
От 5-ых рельс, которые будут этой весной, ожидаю, в основном, поверхностное обновление АПИ, связанное с уже упомянутым прекращением поддержки предыдущих версий руби. Больше символов, проще логика с prepend, чище методы с keyword arguments и тому подобное.
Надеюсь, под руководством Аарона Патерсона rack 2.0 будет доведен до ума. Поддерживать стриминг без костылей — это самая простая постановка задачи. В конце года выйдет стабильная спецификация HTTP 2.0 и формата request-response даже со стримингом недостаточно. Нативная поддержка семантики HTTP, как пытаются сделать webmachine и http-2 гемы, упрощает решение разных специфичных задач, но усложняет общее АПИ — сложность, как обычно, в поиске компромиса.
Параллельно с рельсами будет развиваться и дальше сопутствующая инфраструктура. На базе докера появятся инструменты для девелопмента, которые, с одной стороны, полностью предоставляют все необходимые сервисы и библиотеки для приложения (включая версию руби), при этом, с другой стороны, работа с ними будет абсолютно прозрачной: зашел в папку проекта, написал setup и у тебя поднялись все необходимые сервисы, а бинарники ruby, bundle, rails и остальные проксируются к запущенному образу. Система девелопера всегда чистая, проект всегда готов к запуску на любой системе, при этом разницы между разработкой никакой. В области деплоя переход на докер тоже может принести много бенефитов, но для этого нужен более высокоуровневый инструмент поверх него, который будет отвечать за развертывание, проксирование для переключения и ролбека без даунтайма, сбор логов, контроль крона и тому подобное.
Формирование новых конвенций для рельс-приложений далеко от завершения, общие идеи понятны, но общепринятого консенсуса по деталям пока нет. Более комплексные подходы, такие как гем trailblazer, имеют больше шансов на распространение, так как многие конвенции лучше всего работают в связке. В этом же геме есть идея концепций, которая может прижиться в сообществе, в котором хотят достичь большей модульности, но не всегда готовы к оверхеду полноценных сервисов или в ситуациях, когда обычные энджайны рассматриваются как оверкил.
Возможно, в дальнейшем поверх стриминга в рельсы добавят абстракции для построения датафлоу с клиентом (пока эксперименты с реактивной связью между сервером и клиентом вызывают довольно широкий интерес, даже если смотреть только в рамках руби сообщества, то voltrb стал популярным довольно быстро, хоть и находится на очень ранней стадии разработки).
Это первое, что пришло в голову. Если подумать, интересных направлений и разработок ведется очень много и говорить о них можно долго, буду рад пообщаться на рельсклабе с желающими :)
В чём, на твой взгляд, самая важная проблема, которая стоит сейчас перед сообществом разработчиков Ruby и Ruby on Rails?
На мой взгляд, это размытие культуры опенсорса. Важно помнить, что экосистема формируется руками сообщества и долг каждого ее развивать. Много людей просто работают и пытаются обойти проблемы экосистемы и опенсорса (порой с едкой критикой), вместо того, чтобы участвовать в их решении.
Как это решить — не знаю. Казалось бы, руби и так располагает к тому, чтобы было легко исследовать рантайм и решать проблемы, но значит нужны инструменты, чтобы сделать это еще проще. Было бы прекрасно, хоть и несбыточно, если бы в _why день была традиция на уровне рабочего этикета, чтобы вместо работы каждый руби-програмист мог потратить время и попытаться разобраться в проблеме, с которой ему довелось столкнуться. С наличием менторов внутри компании или на irc-канале. А потом повсеместные публикации на тему того, что сделали, для дальнейшего распространения духа. Казалось бы, один день в году, но для того, чтобы начать больше и не надо, при этом часто это самое сложное.
Есть гем, на который ты мог бы показать пальцем и сказать: “Вот так нужно писать код”?
Гем — это результат коллективной работы, а код с определенным почерком — отражение стиля индивидуума, поэтому я просто перечислю гитхаб-ники нескольких из тех, что в голову придут: evanphx, eregon, banister, dkubb, ConradIrwin, amatsuda, mbj, solnic, jeremyevans.
Ты много контрибьютишь в open source. Зачем это делаешь ты и почему это стоило бы делать другим?
Я делаю это, когда сталкиваюсь с проблемами и есть свободное время. В марсианах работа с открытым кодом почти обязательна, так что вдобавок к возможности обосновать трату рабочего времени на опенсорс, есть периодические материальные конкурсы и бонусы.
Вообще рекомендую остальным, так как маленькими шажками все сообщество движется вперед, плюс придется хорошо разобраться в проблематике, то есть прокачать свой скил.
Что ты читаешь о Ruby/RoR? Блог, ресурс, книга?
Разные блоги, твиттеры, рассылки, мейллисты, которые накопились в большом количестве за долгое время.
Бывает стыдно за код, который ты написал несколько лет назад?
Не бывает — если сейчас написал бы по-другому, то это означает наличие новой информации в моем сознании, но все знать невозможно, поэтому стыдиться незнания не стоит, главное — вкладывать душу :)
Чем тебе нравится заниматься кроме программирования?
Читать про современные экономические реформы и критиковать текущее правительство :D
Спасибо за интервью!
На конференции Равиль расскажет о Big Data: 27 сентября, в центре Digital October. Вся программа — на сайте RailsClub 2014 .
Регистрация и оплата участия — тут.
Билетов осталось совсем мало!
Наши спонсоры:
Генеральный спонсор — Toptal
Золотые спонсоры: Boookmate и FunBox
Серебряные спонсоры: AT-Consulting и Lookatme
HR-партнер: DigitalHR
Организаторы:
Undev.ru — сильная команда разработчиков на Ruby, Objective C, C++, C#, JavaScript. Работают над созданием уникальной технологической платформы для телевизионного вещания через интернет. На базе этой платформы были сделаны такие крупные проекты, как Веб-выборы 2012, ПМЭФ, трансляция ванкуверской и лондонской олимпиад, и еще несколько проектов аналогичного масштаба.
Evrone — команда разработчиков на RoR, Clojure и Scala. Энтузиасты сообщества и бессменные организаторы RailsClub.
Будьте в курсе наших новостей, подписавшись на рассылку на сайте railsclub.ru, и следите за обновлениями:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub
