RailsClub 2016: Інтерв'ю з Володимиром Дементьєвим

Всім привіт! Ми активно готуємося до RailsClub 2016. На сайті вже викладені тези більшої частини доповідей — радимо подивитися! Вже зареєструвалося майже 400 учасників, приєднуйтесь, до 22 жовтня залишилося не так багато часу!

imageПродовжуємо викладати інтерв'ю з нашими доповідачами в подкасті RubyNoName. Сьогоднішня розмова з Володимиром Дементьєвим, розробником в Evil Martians.

Аудіо можна послухати на сайті подкасту, а тут ділимося розшифровкою.

Сьогодні у нас в гостях Вова Дементьєв, відомий також як palkan. Розкажи трішки про себе?

В Ruby співтовариство я прийшов не так давно. Приблизно 4 роки тому я в перший раз спробував рейки, погрався. Мені сподобалося. але проект, на якому я тоді працював, їх не використав. Тому довелося відкласти до чергової реінкарнації проекту Teachbase, нашого стартапу. Teachbase — це SaaS система для організації управління навчанням, вона дозволяє вам зробити власну Coursera в рамках компанії або проекту. Коли я прийшов, то був страшний проект на PHP, а я тоді мало що вмів. Кодил, що говорили. Потім я познайомився з рейками і з того моменту, як став технічним директором, почав виношувати ідею написати нову класну версію системи на просунутій технології. Така нагода трапилася в 2014 році, і тоді ми повністю перейшли на рейковий стек в частині веб-додатки. З тих пір я почав активно цим займатися.

Як ти зміг переконати замовника перейти на Rails?

Все дуже просто — я сам собі замовник. Я один із засновників цього стартапу, двоє моїх партнерів не мали достатньої технічної експертизи, тому довіряли мені. Сподіваюся, вони не помилилися і не шкодують про це :) Вибір технологій був за мною. Питання було тільки в тому, щоб знайти час на перехід з однієї версії на іншу. Ну і гроші, звичайно. Коли момент настав, ми переписали все на рейки, і ось ця третя (або четверта версія системи працювала швидко, чітко, всі були задоволені — як ми, так і клієнти.

Вона і зараз працює?

Так, вона продовжує працювати. Ми довели проект до дуже хорошого стану, коли робити нову версію має сенс вже не з технологічних причин, а скоріше ідеологічним. Не знаю, які у хлопців плани на даний момент. Поки вони займаються підтримкою цієї системи, продажем. Все йде непогано, проект живий, працює.

Teachbase досить великий проект на рейках. Причому це були рейки 4.1, 4.2 ми не стали переходити, хоча планували. Рік з невеликим тому було оголошено про вихід 5 рейок восени 2015, в цей момент ми вирішили, що немає сенсу переходити на 4.2, коли можна відразу перейти на 5. Всі знають, що потім було. Пройшов ще рік, п'яті рейки вже вийшли, але зараз переходити на них, напевно, ще небезпечно. Треба почекати хоча б 5.0.1, а краще 5.1, тоді можна буде переходити. Ми сподівалися на реліз-плани команди розробників рейок, вони не виправдалися, тому наш проект досі висить на 4.1. І особливих проблем з цим немає.

тобто, з точки зору технологій проект закінчений, і ви робите щось нове коли розумієте, що це потрібно бізнесу?

Так. Є плани переробити значну частину логіки, і це, швидше за все, буде новий проект на нових рейках, а може і не рейках. У нашому стеку завжди був Erlang, так як ми займалися відеоконференціями, відповідно, потрібен був стриминговый сервіс, який працював би з протоколу RTMP. Він потрібен, щоб люди, використовуючи технологію flash (яку всі ненавидять), могли спілкуватися в браузері, проводити вебінари на велику кількість людей і так далі. Бекендом для всього цього служив сервіс на эрланге, який відмежувався від досить відомого проекту Erlyvideo.

Ви взяли форк, який був ще в open source?

Так, це був open source, версія приблизно 2.18. Відбувалося це в 2011 році. Спочатку ми його просто використали, потім стали розкривати баги і правити їх, адаптувати все під нашу історію. А потім Макс Лапшин закрив код і почав розробляти платний Flussonic. Нам це, в принципі, не заважало. Так у нас з'явився досвід в Erlang, і ми почали робити деякі інші другорядні сервіси для системи на эрланге. Наш стек знайшов другий основний мову.

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

Але більше таких людей не було, тому на початку цього року, коли я ще працював у Teachbase, ми почали програму знайомства з Elixir (як для тих, хто програмував на Ruby, так і для тих хто програмував на Erlang). Був окремий підпроект, в якому було 2 розробника: рубист і эрлангист. Вони повинні були освоювати технологію разом, використовуючи кожен свої сильні сторони. Один краще знає Ruby і його парадигму, знає Rails, які схожі з Phoenix в частині MVC. А другий чоловік, який знає Erlang, робив на Elixir якісь більш близькі до цієї парадигмі речі. Проект поки не дороблений, але він дуже цікавий. Ми почали переходити на цей стек, скоріше через його популярності, щоб було простіше надалі жити і наймати нових співробітників.

А не хотіли перевести на Phoenix? Повністю відмовитися від Ruby, залишити Erlang, поверх нього Elixir, а зверху ще Phoenix?

Коли стояло питання про перехід на Rails, був альтернативний варіант відразу переходити на Erlang. Я готовий був це зробити. Напевно, ми б довше стартували, але ймовірно це було б краще з точки зору ефективності. Добре, що ми цього не зробили: наші навантаження не вимагають якихось моторошних оптимізацій, і рейки цілком справляється, а швидкість розробки дає набагато більшу. Зараз я не думаю, що Phoenix можна повністю замінити рейки саме з точки зору побудови бізнес-логіки, шару роботи з даними.
Все що стосується запитів, сокети (це окрема розмова ми повернемося до нього) — з цим у Phoenix все непогано. Але Active Record (або його альтернативи) і екосистема навколо нього поки що набагато зручніше, ніж усе, що є в Elixir. Це логічно, там інша парадигма, там не так просто зробити зручний для використання інструмент. Тому, на мій погляд, Elixir та інші, з Phoenix або без, — це швидше технології для ідеології микросервисов. Потрібно використовувати їх в якійсь важкій частини, в яку стукає дуже багато клієнтів, з якимись завданнями, запитами. Такі частини можна писати Elixir, вирішувати їх кількома різними сервісами. А основна логіка має, мені здається, залишатися в рейках, якщо спочатку була написана на них. Але навіть якби я зараз починав проект з нуля, я б все одно не став робити все на Elixir.

Ти говориш про Teachbase і своєї ролі CTO в ньому, як про минулу історію. Зараз, наскільки я знаю, ти працюєш в Evil Martians, працюєш просто розробником. Чому ти перейшов від управління до розробки? Частіше навпаки, люди хочуть пройти шлях від розробника до управлінця. Чи вважаєш ти це кроком назад, або це якийсь проміжний етап?

По-перше, довгий час я був у Teachbase єдиним розробником. Я почав набирати команду лише в останню пару років, коли у нас з'явилася така можливість. Проблема для мене, як для розробника, була в тому, що я багато всього спробував, багато нового дізнався, але в основному на власному досвіді. Я ніколи не працював в команді під керівництвом когось, хто був досвідченіший за мене і мав якісь знання, яких у мене не було. Це була одна з причин: мені було нудно, я розумів, що мій самостійний зростання в Teachbase буде йти важко. Особливо, коли проект стабілізувався, не було якихось супер цікавих завдань, тільки плинність типу додавання фіч, немає волі творчості.

Я розглядав марисан, в першу чергу, так як я був знайомий з деякими хлопцями, я був на курсі Brainwashing, з тих пір у мене залишилися найприємніші враження про цю команду. Мені дуже хотілося попрацювати з такими людьми, поділитися досвідом, поділитися своїми ідеями. Коли я працював в Teachbase, мені не було з ким обговорити якісь технічні ідеї, не було людей, які зналися б добре в технічних аспектах. Тому я хотів потрапити в сильну команду.

Те, що в Teachbase у мене була «влада», а тепер я рядовий співробітник, не страшно. Напевно. Хоча моя дружина каже, що після того, як я перестав керувати, я намагаюся трошки частіше керувати будинку. Компенсую :)

Мені подобається відсутність вертикалі, можна з усіма спокійно спілкуватися, розмовляти, сперечатися, лаятися іноді. Мені потрібно було потрапити в середу, скажімо так.

Ми почали говорити про Rails і довгоочікувану 5 версію, в якій багато всього з'явилося. Наприклад, Action Cable, про який ти і будеш розповідати на конференції. Чого тобі не вистачає в Rails?

Я б поставив питання по-іншому: що в рейці зайве, що заважає.

Так, це хороше питання. У минулому подкасті ми говорили з Олексієм Тактаровим про те, чи варто викинути фронтову частину. А що б ти викинув?

Фронтова частина і складання ассетов з допомогою Sprockets, на мій погляд, вже застаріла схема. Фронт зараз пишеться зі своїми збирачами, там своя дуже розвинена екосистема. Яка працює, з мого досвіду, набагато приємніше, ніж Sprockets. Це швидко, зручно, купа додаткових можливостей, тонка настройка і так далі… Той же автопрефиксер вставити в Sprockets, звичайно, можна. Але якщо вставити ще 20 аналогічних плагінів, то ассеты, скоріше всього, будуть збиратися дуже довго.

Я використовував рейку, по більшій частині, некласичним чином, з серверним рендерінгом, використовуючи javascript шаблони і подібні речі для оновлення сторінки. Я використовував Rails практично в API режимі, тільки JSON. HTML-сторіночки віддавалися також рейками, але була ідея позбутися і від цього, вантажити статику окремо, так як динамічної візуалізації був мінімум, наприклад: вставка логотипу нальоту. Всі фішки типу шаблонів,Turbolinks, ось це все, повинні бути окремими примочками до рейок. Якщо хочеш — додавай.

У свій час Sprockets був справжнім проривом. Можливо, зараз ця технологія застаріла, тому що фронт розвивається якимись божевільними темпами.

Тому що на той момент у фронті був популярний тільки Grunt, жахливий і монструозний, на мій погляд. Він довго мене відштовхував від використання всього цього, поки не з'явилися більш приємні оку альтернативи. Якщо говорити про поточний момент: якби я зараз починав новий проект і брав би як бекенду рейці, я б, враховуючи, що у нас в Rails 5 є вбудований API режим, відразу б робив так, щоб окремо один проект робили фронти, окремо бэкенды. Це дуже зручно і з точки зору розробки. Нема чого фронту піднімати сервер, копирсатися там. Нехай він робить фронтову роботу і не знає, що на сервері. Нехай просто працює по специфікації, яку дають бэкенды.

Ти підняв цікаву тему: якщо зараз робити проект на рейці. А якщо не на рейці, на що б ти робив?

Все залежить від того, який проект, звичайно.

Давай як приклад візьмемо Teachbase. API, взаємодія з JSON. Викидаємо Action View, викидаємо щось ще. Може варто використовувати альтернативи на Ruby, але не Rails? Або взагалі іншу мову?

Хороше питання. Якщо питання стоїть як «що-небудь інше на Ruby» — то немає. По-перше, у мене немає особливого досвіду. Я пробував микрофреймворки типу Cuba, Sinatra. Такі мікро-микросервисы, просто експериментував і дивився, що це і навіщо. Великі альтернативи, типу Trailblazer або Hanami, я не пробував, вони мене, в принципі, не зацікавили. Я поки не зрозумів, навіщо вони мені. Так, я бачив бенчмарки, там все класно, швидко. Але рейки і рубі вибираються не для того, щоб було швидко, а для того, щоб було зручно. Тому такий аргумент для мене не найважливіший.

Так, у Hanami є один дуже великий недолік: його ніхто не використовує.

Ось! Складно змагатися в Rails, на якому пишуть всі, багато з них починають свій шлях в Ruby. Реальні конкуренти рейках зараз не всередині Ruby, а Elixir і Phoenix, які набирають обертів. На мій погляд це відбувається частково тому, що Elixir добре піарять. Його навчилися продавати командам розробників, кажуть що Elixir класний, у вас все буде швидко. Навіть в Росії вже є люди, які використовують гібридний стек — частина рейки, частина еліксиру, всі хочуть його спробувати. І головне всі хочуть продати розробку на Elixir замовнику. Як комерційний проект Elixir — дуже класна штука. Він простіше Erlang, хоча особисто я б все одно вважав за краще Erlang. Так, буде трошки боляче, місцями буде більше коду, хоча і це можна оптимізувати.

Якщо відповідати на питання «що, якщо не Rails». Я б вибрав Erlang, але тільки в тому випадку, якщо мені дали б пару розробників і трохи більше часу. В основному, все впирається в наявність розробників: їх мало. З Elixir теж проблема: багато хто, хто почав вивчати Elixir і щось на ньому зробили, відразу вважають, що вони знають Erlang. Це приблизно та ж історія, як коли люди, потыкавшие в рейки, потім кажуть, що вони знають Ruby. Швидше за все, ринок постраждає від цього. Знайти хорошого розробника на эрланге буде ще складніше, тому що буде багато лівого сміття. У фронті зараз схожі проблеми: якщо люди, які вивчили Angular, але не розуміють, що таке JavaScript. Тепер скрізь є така проблема.

Ми почали говорити про альтернативи Ruby. У тебе великий досвід роботи з Erlang, ти писав на PHP, наскільки я знаю, ти ще пишеш на go. На яких мовах ти щось пробував робити і що хотів би спробувати?

Давай говорити хронологічно. У школи та університеті були Pascal, C, Basic, Assembler. Але в університеті я пропускав програмування, воно мені дуже не подобалося. Я до сих пір дивуюся, як я так випадково став програмістом. Починав я з ActionScript

тобто Flash?

Так. Я починав з другого ActionScript, він був жахливий. А от у третьому з'явилося дуже багато змін: нормальні класи, проксі об'єкти, які всі так чекають зараз в JavaScript (але поки там не дуже добре з підтримкою). Багато всього класного, зручного. Як мову він був прикольним. Зі своїми мінусами у вигляді не дуже простої компіляції, в якій, якщо у тебе не Flash Builder від Adobe, доводиться багато чаклувати. У мене був дуже великий проект у рамках Teachbase, коли ми почали робити своє рішення для вебінарів. Воно складається з двох частин: клієнтської і серверної. У серверній був Erlang, а в клієнтській — велике ActionScript додаток. Це був мій перший великий проект, я продумував його з нуля, з серйозною архітектурою, там було багато класних ідей. Це додаток досі працює. У ньому немає багів, я останній раз його правил два роки тому! З тих пір воно класно працює. І це дуже добре, тому що я навіть не знаю, як мені його тепер зібрати, запустити і так далі, у мене немає ніяких систем збирання, і я вже погано пам'ятаю, як там все влаштовано.

Почекай, третій ActionScript вийшов дуже давно, він старий. Близько 10 років. Він взагалі розвивається?

Так, він дуже старий, але ще живий, на ньому пишуть. Особливо багато використовують в ігровій індустрії, зробили дуже багато оптимізацій з точки зору графіки, візуалізації, використанням GPU і так далі. На ньому можна писати класні ігри. Здається, якась з популярних онлайн ігор, типу танків, була спочатку на flash. Зараз не знаю, може, досі.

Був період, коли ці технології були у всьому реалтайме, коли, наприклад, потрібно було зробити відеочат, коли не було й натяку на інші технології, flash був скрізь. Це зараз він мало у кого стоїть. На Flash раніше було реалізовано те, що зараз є в Web RTC, peer-to-peer. Цей проект в підсумку був покинутий. Спочатку він називався Stratus, ми навіть робили на ньому побічний проект — портал для психологів з можливістю консультації онлайн. Працював через раз. Зараз ті вебінари, які існують і працюють в браузері, заявляють, що використовують Web RTC, але в більшості випадків це не так. Саме для стрімінг досі використовується flash, rtmp. Там він ще живий.

Я дуже добре знав ActionScript, але зараз не сказав би, що я в ньому експерт. І не планую ним займатися.

А тепер повернемося до нашого питання: що було після ActionScript?

Потім був php. Не пам'ятаю, яка там була версія, з ним були різні замуты.

А як ти познайомився з Rails?

Все вийшло випадково і просто. Є така чудова майданчик Coursera, коли вона тільки з'явилася, там було десь п'ять курсів, один з них був про SaaS розробку і так далі. Цей курс, фактично, був таким введенням в Rails, тоді ще 3. Не сказати, щоб я вивчив рейки за цим курсом. Це був дуже простий курс, висновок однієї сторінки і пошук за елементами з бази. Але там було добре розказано про тестування, про всі його рівні. Після цього я написав якийсь мікро-микросервис для нашої системи. Дуже страшний, негарний, він навіть був запущений через rails s development режимі. Але він працював, практично не падав.

Складно сказати, в який момент я почав вивчати і щось робити, перемикатися. Сильним поштовхом був похід на Brainwashing. Коли я туди йшов, я практично нічого не знав саме про Rails: що там, як там. А на курсі отримав стусана, скажімо так. Сів і почав розробляти.

Можна сказати що Равіль і Газай справили на тебе великий вплив?

Так, вони підкинули натхнення в цьому напрямку. Якщо далі говорити про мови, потім був Erlang. Зараз я іноді використовую Golang для різних речей. Мова досить простий, можна вибирати його, якщо треба щось швидко накидати. Він компілюється в виконуваний файл і його можна використовувати. Ще я дуже багато займався фронтом, зараз вже менше.

Не тягне на фронт? Перейти темну сторону.

Хороше питання. Напевно, немає. Я так собі фронетенд, тому що я не дуже сильний у всьому, що стосується стилів, верстки та іншого. Особливо з новими замутами: якісь CSS модулі, CSS 4, все змінюється дуже швидко, я не встигаю за цим стежити. Мені ніколи не подобалось, я завжди вважав верстку роботою для якихось… як-би без расизму обійтися… не буду говорити :) Це чорнова робота.

Практично завжди ми віддавали її на аутсорс. Нам надсилали верстку, ми її інтегрували.

Один раз я запропонував не мучитися, і все зробити самостійно. Тоді я почав цим займатися. Спасибі Андрію Ситнику, який розповів всякі цікаві штуки і показав, як робити не треба, дав деякий вектор. І я почав робити багато фронту, в результаті у нас в Teachbase основна логіка на клієнта — це написаний мною фреймворк. Ми починали ще до того, як React став популярний, Angular ще не був особливо популярний, але вже існував. Я вирішив, що мені швидше написати самому, я розумів як працює JavaScript, і не хотів витрачати час на те, щоб розібратися як працює Angular. Я ні разу не шкодую про це, тому що Angular працював у першій версії жахливо, на мій погляд занадто очевидним. Хоча комусь це може здаватися зрозумілим. У другій версії може бути що-небудь змінилося. У мене був свій велосипед, він і досі працює, хлопці його використовують. У вільний від роботи час я намагався написати його нову версію на es6, але вільного часу виявилося не так багато. Тому на гітхабі висить дві недороблених версії мого фреймворку :) Там прикольні ідеї, але враховуючи, що я витрачав на це один день на місяць, вони сильно відстають від тенденцій, які зараз є у фронті.

Ми почали тему своїх велосипедів. Як ти береш участь в open source? Чи є проекти, на які ти хотів би, щоб хлопці звернули увагу? Класний проект, але його ніхто не помічає. Свої проекти або чужі — не важливо.

Знову прорекламую Brainwashing :) Open source для мене почався там, я зробив свій перший комміт в OS. В рамках курсу хлопці натрапили на баг в pry-byebug, який був у экстеншене на C. Я його знайшов, пофиксил, відправив і отримав свій перший pull request, отримав від цього задоволення і трохи підсів :) Почав цим займатися.

Якщо говорити про чужі проекти: я дуже багато працював над Rubocop, це проект Божидар Батсова. Мені дуже подобається цей проект і в цілому ідея, що код повинен бути стилізований. Я це скрізь пропагую, де є можливість.

Але ти ж не використовуєш дефолтний конфіг rubocop?

Звичайно, я завжди там щось правлю, щось відключаю, що-то вмикаю.

А змінюються налаштування проекту в проект? У тебе є сформовані установки, які ти завжди використовуєш чи вважаєш, що кожен раз потрібно домовлятися з іншими розробниками в проекті?

По-різному. Зараз я, наприклад, прийшов в проект з великою кодовою базою і ми прикрутили обов'язкову перевірку rubocop'ом, але там у нас дуже мінімальний конфіг, який перевіряє на дуже погані речі, типу забутого дебага в коді або фокуси спека і так далі. І ще у нас включено кілька оптимізаційних копів. Речі типу довжини рядка, кількості рядків у методі і так далі ми в цьому проекті не перевіряємо.

А ти прихильник історії про 80 символів, 120 або просто вимикаєш цю перевірку?

Я підтримую цю тему, зазвичай я ставлю 100. Це число вийшло досвідченим шляхом: я довгий час працював на 21-дюймовий iMac і розробляв зі сплитскрином. Я робив так, щоб в обох частинах екрану входили всі рядки. Це як раз приблизно 100 символів. Логіка вибору довжини рядка була така, тому що горизонтальний скрол це дуже незручно.

Про довжину методів або довжину класу… немає.

Коментар на початку рядка, enter в кінці...

Порожній рядок в кінці я завжди ставлю. Роблю це, тому що так зручно перейти в кінець файлу. Є певний відступ знизу, тобі не треба попадати в кордон дисплея. Я десь читав, якими історичними обмеженнями це правило було викликано, в якихось старих системах. Точно вже не воспроизведу, що там було. І зараз гитхаб постійно це підсвічує в диффах, лається коли у тебе немає порожнього рядка — це не дуже приємно.
В моєму дефолтному конфіги на нульовому проекті багато включено, але ці параметри складності трохи збільшені. Якщо де-то дуже велика складність, і я не хочу рефакторіть якийсь метод усвідомлено, то я просто відключаю цей коп локально, так і все. Але у всіх гемах, якими я займаюся, або в які я активно контрибьютил, впроваджував цю справу.

Про rubocop зрозуміло. На які ще проекти варто звернути увагу? В яких ти брав участь?

Я багато працював над проектами з екосистеми InfluxDB. Це база даних для зберігання тимчасових рядів. Цікавий проект, зараз він виріс в InfluxData, у них свій стек, це щось схоже на стек від Elasticsearch, де у тебе є складальник логів, візуалізатор, сама база, але він заточений не на логіку, а на якісь тимчасові метрики. Я почав його використовувати в Teachbase, він тоді був не дуже відомий, це було приблизно півтора року тому. Їх історія дуже схожа на історію з Rails 5: була версія 0.8, вони обіцяли через місяць випустити наступну, більш стабільну і з багфиксами, з кластеризацией і так далі. Я навіть з ними списувався, мені відповідали, що робота йде, версія скоро буде. Було досить ризиковано використовувати не дуже production ready історію, пару раз все дуже страшно падало. Але в підсумку, обіцяна версія вийшла, як і Rails, тільки на початку цього року. Ми прожили рік на нестабільної версії, довелося все-таки з нею працювати.

Один з моїх найбільших open source проектів, якраз відомий тим, хто працює з цією базою. Я написав адаптер для роботи з цією базою в стилі Active Record. Проект називається Influxer. Він дуже схожий на ActiveRecord: визначається певний клас, кажеш які у нього є атрибути (це атрибути цих міток в базі), і він дозволяє робити запити, такий синтаксичний цукор. InfluxDB підтримує SQL-подібний мову, і замість того, щоб писати на ньому можна використовувати ось таку обгортку. Це зручно, там є деякі фішечки, згідно з моделями і так далі. Він активно використовувався в Teachbase, для цього він і робився. Я і зараз продовжую його підтримувати, в зв'язку з виходом нових версій бази і зміною API, там все більш або менш актуально. Проект хтось використовує, є кілька десятків зірок.

Крім Influxer я займався іншими проектами для цієї екосистеми. До якогось моменту весь код був відкритий, сама база і всі другорядні сервіси, які там використовувалися. В цьому році вони запровадили комерційний варіант. Частину коду, природно, вже не в open source, особливо те, що стосується кластеризації. Все інше відкрито, і розробники ради, коли туди приходять люди і контрибьютят. Там все написано на go, і мій перший досвід з go вийшов саме там. Я робив пару патчів в проект, який називається Telegraf: це складальник логів, щось типу Logstash або нових beats від Elasticsearch. Проект дуже активно розвивається, до стабільної версії далеко. Якщо ви хочете спробувати go і взяти участь в open source, знайте, що там досить просто зробити pull request.

Розкажи ще про Thinknetica. Ти там граєш роль наставника, що це означає? Який досвід ти звідти винесла? Скільки навчив людей?

Так, слово наставник мені подобається більше. Раніше ми називали один одного ментори, але це якось не по-російськи. Я працюю там 1,5 року, але з перервами. Ми беремо групу, займаємося, потім робимо перерву і так далі. Я навчив чоловік 50, може трохи більше. З них 20 відсотків дуже класні хлопці, які добре працевлаштувалися після курсу. Багато хто з випускників влаштовується потім на профільні вакансії, але я не дуже стежу за цим. Коли навчаєш досить простим речам (ми не вчимо чогось складного), це розширює кругозір, не дає очам замылиться. Ти бачиш різний код дуже різних людей. Ти бачиш різні помилки, перш за все. Деякі ти зустрічаєш перший раз у житті, то як люди пишуть, дивні баги. Дуже багато цікавої інформації для мозку. Не даєш собі засохнути.

чи Подобається тобі бути наставником?

Коли учні хороші — подобається, коли погані — ні. Я дуже нервова людина, мені хочеться всіх послати. В цьому плані я швидше тренер, ніж учитель, я досить жорсткий. При цьому мені подобається спілкуватися з тими, в кого я бачу інтерес. Не обов'язково повинно виходити, але коли хлопці стараються, це дуже класно, з ними можна поговорити, ми періодично зустрічаємося особисто. Вони задають цікаві питання, які мене змушують подумати. В цілому, будь-який вид навчання, особливо якщо ти викладаєш щось пов'язане з твоєю професійною діяльністю, — це велика прокачування для того хто викладає, ніж для тих, хто навчається. Крім знань, які отримуєш по Ruby, про те як спілкуватися з людьми, можна відточувати своє ораторське мистецтво, спілкування з публікою по ту сторону кабелю, коли проводиш вебінари. Плюсів у цієї діяльності багато, мінуси теж є. Є рутина, коли ти втретє ведеш один і той же курс, тобі не так цікаво. Чекаєш, коли учні вже дійдуть до цікавих тим, щоб з ними було про що поговорити, а то все якусь фігню роблять :)

Ось і ми дійшли до цікавої теми :) Лейтмотив нашого інтерв'ю — RailsClub, ти там будеш розповідати про Action Cable. В основному, всі йому раді. Є недоліки, не все ще кльово, він підтікає; буває, що два треда пишуть в один канал. Але в цілому, всі дуже задоволені. І тільки від тебе я чую скепсис. Розкажи про що будеш доповідати? Не хочеться спойлерити, але я відчуваю, що у тебе на цю тему є біль. Поділишся?

Давай повернемося в весну 2015. За деякий час до того, як відбулася конференція, на якій DHH оголосив про цієї чудової фиче.

Це для тебе дійсно чудова фіча або така «чудова фіча», в лапках?

У мене до неї подвійне ставлення. У чому-то чудова, в чомусь «чудова». У будь-якому випадку, це гучна фіча.

У Teachbase вебсокеты використовувалися. Природно, вони були підтримані эрлангом, тому що це був наш стек. У нас були плани щодо тісної інтеграції сервісу, який обробляв дані з веб сокетів, з рейкою. Готові рішення, які були в рейці, ми не розглядали, тому що людям, у яких є вебсокет сервіс написаний на эрланге, навіщо пхати вебсокеты на Ruby було б дивно. Це як дати двірнику іграшковий совок. У нас була власна ідея (вона реалізована, викладена в open source і працює), як подружити рейки з сокетами. І ось, в березні або квітні виходить Action Cable. Я подивився відео, подивився приклади, які були. Перше враження було: “Вау, нічого собі! Це круто, це виглядає дуже класно, зручно, красиво — прямо те, що я б хотів використати". Це був додатковий аргумент, щоб не мігрувати на 4.2, а чекати Rails 5, щоб у новій зробити що-то, використовуючи кабель, зробити все класно.

Гарне враження від Action Cable стосувалося в першу чергу до каналів, до того, що зроблено безпосередньо в Rails, обгортки бізнес-логіки. Мені дуже сподобалося, як все зроблено: дуже rails way, все як треба. Але була й друга думка — а на чому це буде? Це думка прийшла мені в голову, коли репозиторій самого кабелю в исходниках окремо виклали на гитхаб. Тоді це працювало на Celluloid, якщо я правильно пам'ятаю. Тобто це було реалізовано на Ruby, що, звичайно, не круто. У мене упереджене, але поширена думка, що писати конкурентні програми на Ruby не потрібно. Це не те, для чого ця мова був створений, особливо якщо говорити про масштабованості та ефективності з точки зору споживання ресурсів.

Тоді у мене виникла ідея подумати над тим, як же нам взяти хороше від Action Cable і добре від того, що на той момент вже було реалізовано в сервісі на Erlang. А там було вже багато всього: горизонтальна масштабованість, різні авторизації і так далі. Тоді я ще не знав про Phoenix. Як потім з'ясувалося, це було дуже схоже на те, з чого починався Phoenix. Але тільки зроблено на живому Erlang. Хоча по факту під капотом все ми використовуємо один і той же Cowboy як ерланговскій веб сервер.

За рік в кабелі сталося, звичайно, дуже багато змін. Всі вони, мабуть, позитивні. По-перше позбулися Celluloid на користь nio4r (який тим не менш і до Celluloid має відношення).Додали дуже багато різних можливостей синхронізації, адаптери та інше.Але основні проблеми йти не поспішають. Буквально недавно був гучний баг витікає з пам'яттю, незакрывающимися сполуками. Досить дивно, що він виник вже після релізу 5.0. Ще висить декілька багів, пов'язаних з продуктивністю. Все це говорить про те, що Action Cable зараз не підходить для продакшену в якусь велику систему, не блог з відвідуваністю 100 осіб, а реально велику систему з навантаженням в тисячі і сотні тисяч людей. Це не той інструмент, який може вирішити задачу.

Тоді виникає питання, а які взагалі проблеми може вирішувати Action Cable?
Всі ми знаємо, що всі нововведення в Rails з'являються заради одного всім відомого проекту на букву B. Я перевірив, там дійсно використовується Action Cable, наскільки це можливо визначити, просто подивившись логи браузера. Там використовується там не той Action Cable, який зараз пропонується в рейці, а, мабуть, якась його попередня версія.

А може це взагалі не Action Cable?

Може бути. Принаймні, протокол веб сокетів підписаний як ActionCable, але в який сервер він стукає — ми не знаємо. Протокол дуже схожий. На жаль, інсайдерської інформації звідти немає. Але я не здивуюся, якщо насправді там працює якийсь сервер, який просто працює по тому ж протоколу, може бути спілкується з рейкою, хоча насправді для того, що вони роблять, це і не потрібно роблять вони буквально два сценарії: відправити зміни, які відбулися на сторінці (хтось написав коментар, відправив тудушечку і так далі). Це бродкаст, перший сценарій. І сценарій, який, навпаки, від клієнта відправляє інформацію серверу про те, що людина робить на сторінці. Вона передається в кілька зашифрованому вигляді, але там приблизно наступне: перейшов на сторінку або закрив вкладку, трекінг активності деякий.

тобто, у них це все використовується не дуже навантажений?

Так. І в цьому випадку Action Cable вистачає. З одного боку. А з іншого боку виникає питання: а навіщо тут рейки? Я бачу єдиний момент, який точно там використовується, це аутентифікація. Нам потрібно якось підтвердити право людини підключитися до сокета, підписатися на конкретний канал і так далі. Ось тут вони напевно взаємодіють з додатком. Але не факт, може бути і немає. Все інше має мале відношення до бізнес-логікою. Я робив щось подібне, у мене як раз веб сокети використовувалися для трекінгу активності. Всі ці дані не писалися в основне додаток, вони там взагалі не потрібні, принаймні в сирому вигляді. Вони писалися в окрему систему, там вже оброблялися і потім витягувалися, коли потрібно. В даному контексті не дуже зрозуміло: потрібен там Action Cable чи ні? Використовується він чи ні? Але раз це квакає як Action Cable, давайте припустимо, що це він. Більше я не знаю реальних прикладів. І я думаю, поки немає відомих проектів, які використовують Action Cable. Напевно, багато хто хоче його використовувати, але питання в обсягах. Він дуже хороший в тому, в чому гарні всі рейки — швидко зібрати MVP, показати кому-то першу версію проекту. Тобі не потрібно нічого тягнути, все є в коробці, накидав realtime і працює. Але коли ти починаєш це справа розвивати, і з'являються клієнти, навантаження і так далі — що робити з Action Cable? Можна, в принципі, плодити инстансы, він виноситься окремо, як якийсь фоновий Sidekiq та інші побічні сервіси, які є у нас в додатку. Але наскільки це ефективно — не знаю, поки у мене є з цього приводу великі сумніви.

На твій доповідь я дуже хочу сходити. За моїми очікуваннями це буде один з самих кльових доповідей. Які у вас очікування від RailsClub'а?

Я перший раз ходив на конференцію в минулому році. Чогось про прямо дуже зачепили не було. Але були хороші доповідачі, наприклад Claudio Baccigalupo, який говорив про Rails 5. Доповідь Koichi Sasada про garbage collector, історію з поколіннями, був дуже сильний і цікавий. Я розумів, напевно, відсотків 70, але це було дуже круто. Але я думаю, що будь-яка конференція цінна не стільки доповідями, а тим, що відбувається в кулуарах. Тому такого спілкування я і чекаю, враховуючи що у нас приїжджають «зірки». Не знаю, наскільки вони будуть готові вийти в народ поспілкуватися, але це цікаво.

тобто ти б поставив кілька запитань Матцу?

Чесно кажучи, у мене до нього немає питань :) Я б послухав, що він буде відповідати на запитання інших, зазвичай я роблю так, рідко сам питаю. На минулій конференції я спілкувався з тобою, після доповіді про микросервисах (Андрієм Дерябиным, провідним подкасту). І трохи спілкувався з Клаудіо. Ще на минулому RailsClub я дізнався про Crystal, це досить цікаво, я тепер стежу за цим проектом. Подумую над тим, щоб як-небудь де-небудь його застосувати, написати на ньому який-небудь экстеншен для Ruby, благо є така можливість. Якесь вузьке місце, може бути навіть в проекті, над яким я зараз працюю. Чекаю, коли видасться вільний день, щоб розібратися і пограти з цією справою. Про RailsClub цього року поки не опублікована інформація про доповідях, є тільки люди. Подивимося, що нас чекає.

Якщо ви хочете обговорити актуальні теми з Володимиром особисто, приходьте на конференцію! Всі подробиці тут, ціна квитка — 9000 рублів.

Традиційне дякуємо компаніям, які підтримують конференцію:

Генеральний партнер: Toptal
Золоті партнери: Rambler&Co і AT-Consulting
Срібний партнер: JetBrains
Бронзові партнери: Gitlab і VoltMobi, Insales і Seendex
Пивний партнер, підтримує традиційне афтепаті — CloudCastle
Будьте в курсі наших новин, підписавшись на розсилку на сайті railsclub.ru.
До зустрічі!
Джерело: Хабрахабр

0 коментарів

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