RailsClub'Moscow 2014: Інтерв'ю з Равілем Байрамгалиным

Привіт!

Вже наприкінці цього тижня відбудеться конференція RailsClub. Наші гості збирають валізи (ось і Аарон Паттерсон написав у своєму твіттері, що їде в Росію). А ми з нетерпінням чекаємо зустрічі з вами!

Ми задали декілька питань про життя та програмування розробнику Evil Martians, провідному розробнику Oh My Stats Равілю Байрамгалину. Равіль контриб'ютор більше 40 опенсорсных проектів, серед яких Ruby on Rails, rack, cassandra-rb, sidekiq та інші. Вийшло цікаво!

image

Над чим ти зараз працюєш?

З цікавого працюю над прототипом системи черг із специфічним набором плюсів і мінусів, решта секрет :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 тощо.

Сподіваюся, під керівництвом Аарона Патерсона 2.0 rack буде доведений до розуму. Підтримувати стрімінг без милиць — це найпростіша постановка завдання. В кінці року вийде стабільна специфікація 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? Блог, ресурс, книга?

Різні блоги, twitter, розсилки, мейллисты, які накопичилися у великій кількості за довгий час.

Буває соромно за код, який ти написав кілька років тому?

Не буває — якщо зараз написав би по-іншому, то це означає наявність нової інформації в моїй свідомості, але все знати неможливо, тому соромиться незнання не варто, головне-вкладати душу :)

Чим тобі подобається займатися крім програмування?

Читати про сучасні економічні реформи і критикувати поточний уряд :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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.