RailsClub 2016: Інтерв'ю з Олексієм Тактаровим

Всім привіт! RailsClub 2016 залишилося трохи більше місяця. Саме час реєструватися!

Ми вже розповіли, що цього року до нас приїдуть виступати Юкихиро Мацумото, Акіра Мацуда, Шон Гріффін, Стів Клабник і Зак Брігс. А сьогодні ми починаємо публікувати традиційні інтерв'ю з нашими доповідачами. В цьому році зробити розмову зі спікерами цікавим нам допомагає подкаст RubyNoName.

imageХлопці записали перший розмову, з Олексієм Тактаровим, фронтенд(!) розробником з These Guys. Олексій спеціалізується на розробці single-page додатків, пропагує чистоту і простоту дизайну і коду. Брав участь у проектах Смартомато, ficus.io і resume.io, працював зі Злими марсіанами; його основні інструменти — Ember.js, React і Ruby on Rails. У вільний час займається південної близько-фронтенд тусовкою Code Hipsters.

Ми вперше ставимо в програму бекенд конференції доповідь про фронт. Нікуди без нього в 2016 році :). Льошин доповідь називається "Дайте фронтенду в Rails другий шанс!".

Про що піде мова:

У фронтенд-ком'юніті в останні роки не нудно! Складно сказати, втома-це або просвітительство (fatigue or enlightenment) від JavaScript, ясно одне — фронтенд-розробка мчить попереду всієї планети зі швидкістю надзвукового локомотива. У той же час бізнес і проекти живуть звичайним життям. Підходи до розробки фронтенда в Rails безнадійно застаріли: збірка ассетов через Sprockets — це довго, незручно, негнучке.
У своїй доповіді Олексій побіжно торкнеться поточний стан фронтенда і розповість про гостро стоять проблеми складання ассетов в Rails. Проведе эксурс в сучасні системи збирання Webpack, Gulp, Brunch і Rollup і покаже, як вони можуть бути інтегровані в екосистему Rails на прикладі реальних проектів.

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

Ми сьогодні зрозуміли, що твій доповідь — перший доповідь про фронтенеде на RailsClub. І це дуже круто! Я боявся ставити тобі, фронтендеру, питання про Ruby, але виявилося що ти розбираєшся і розумієш його. Розкажи, як так вийшло? Як ти прийшов до Ruby?

Моя історія знайомства з цими технологіями досить нетипова. Я починав свою кар'єру як людина, яка робить системні тулзы. Я і з фронтендом тоді не зустрічався, просто займався нативними інтерфейсами для Windows. Якийсь час витратив на те, щоб робити програми, які працюють з великою кількістю потоків, які працюють з concurrency і так далі. А потім якось плавно перейшов у фронтенд, тоді як раз з'явився хайп. З Ruby і рейками я почав працювати вже після цього, і для мене це було невеликим одкровенням, тому що не всі речі, які там працюють, працюють так, як я звик. Кращий приклад: в деяких середовищах, де ти завжди повинен стежити за ресурсами, якщо ти щось взяв в одному потоці і працюєш, то повинен бути впевнений, що в іншому потоці не буде з цим проблем — в ruby всі ці проблеми обходили стороною. Я зіткнувся з абсолютно іншими концепціями. І це було кльово!

Якщо говорити конкретно — я прийшов на проект як фронтендер, робив тільки фронтенд завдання. А потім у нас не стало бэкендера :) Він пішов, нікому було вирішувати його завдання, і я вирішив спробувати. Було незвично: обговорити було не з ким, людина яка мені допомагав, був таким мудрецем. Я приходив до нього раз на тиждень, він говорив якісь магічні слова про те, що мені робити. Потім я йшов, зітхав, думав: «О боже, що відбувається».
Через якийсь час мені начебто вдалося збагнути цю мудрість, хоча напевно не всю. Ту частину, яка закладена у фреймворку і мовою, я відчув цей смак.

Де і чим ти зараз займаєшся?

З особистого — готуюся до весілля. Працюю над своїм проектом, який ще дуже сирий, щоб про нього розповідати. А ще працюю з партнером в команді, яка називається These Guys. Ми спеціалізуємося на швидкій розробці MVP. Намагаюся по-максимум застосувати той досвід, який я отримав, працюючи зі Злими марсіанами, і з іншими командами. Але зараз я більше орієнтуюся зараз не на вирішення технічних завдань, а на рішення бізнес задач, продумую як оптимально всі побудувати для клієнта.

тобто ти зараз відкрив свою компанію?

Так. Хоча сказати про це вголос мені зараз дуже страшно, чомусь :)

Що тобі не подобається в поточній реалізації рейок з точки зору фронтенда?

Мені здається, що сталася така ситуація: два або три роки тому фронтенд різко стрибнув і понісся вперед зі швидкістю локомотива, змітаючи все на своєму шляху. Хлопці з інших спільнот на це дивилися, хто скептично ставився, хтось натхненно. Але треба визнати, що поскакав він дуже далеко. В цьому плані світ рейок залишився без змін.

Є думка, що рейки повинна перестати бути інструментом, у якої є і фронт і бек, зосередитися тільки на бек-офісі. Тому що фронтенд частина в самій рейці зараз явно не встигає. Доводиться рейки використовувати як серверну частину, а фронтова стоїть окремо, там окремі інструменти, окрема команда, окрема історія. Якій позиції ти дотримуєшся щодо цього?

Я завжди намагаюся дивитися ширше. Коли я бачу хайп навколо фронтенда, я завжди намагаюся знайти і хороші, і погані сторони. Добре, що все розвивається і рухається, багато ідей, багато що можна зробити такого, що допоможе наступному поколінню розробників. Але на це треба дивитися з побоюванням, дивитися на те, чи справді все так, як здається? Це стосується і компаній: який вони обирають стек, як вони спілкуються зі своїми розробниками. Наприклад, розробники брали якийсь популярний зараз стек, а потім все розвалювалося. Компанія переставала працювати, тому що технологія була сира. У вас було таке?

Я намагаюся дотримуватися золотої середини. Нещодавно прочитав статтю Равіля Байрамгалина з марсіан про новий рендерер. У неї цікава навіть не сама реалізація, а те, що йде в початок статті: у DHH немає великої кількості часу, щоб приділяти його розробці, але він записує і розповідає багато ідей, які можуть підхопити інші розробники, щоб успішно розвивати фреймворк. Мені здається, це здорово. Круто, коли є бачення, коли DHH розуміє куди йти. Можливо будуть розбіжності, десь це буде не зовсім правильний шлях. Але мені подобається, коли є розуміння спільної місії. В рейках таке бачення є, треба пережити хайп і рухатися далі. Мені здається у нас все вийде, моя позиція цілком позитивна :)

Якщо говорити про хайп у фронті. Що зараз є хайпи, а ніж реально можна користуватися? На що, на твою думку, варто звернути увагу? І що буде цікаво далі?

Якийсь час тому ми з друзями організували в Ростові невелику тусовочку, яка називається Code Hipsters. Це, в основному, стрічка новин у вконтакті та в Телеграмі, ми пишемо про всякі модні штуки під фронтенде (це і намагаємося обіграти в назві). Зараз я трохи відійшов від справ, всім займається мій друг Вітя. У нього прекрасний стиль, мені дуже подобається як він пише. Іноді ми збираємося і розуміємо, що ми не читали за минулий тиждень нічого нового :) Мабуть, трохи втомилися.

Останнє, про що я чув — це Rollup. На мій погляд, там немає нічого революційного, але подивитися цікаво. Рух у бік розумних бандлеров, правильного складання залежностей я вважаю дуже важливим, це гарний напрямок. Хоча не можна сказати, що це rocket science.

По-друге, компонентний підхід. Він прийшов давно, всі його прийняли, і це здорово.

По-третє, FRP. В цьому питанні є велика прірва між теорією і практикою. Напевно щось з'явиться, щоб її подолати.

Повертаючись до питання про рейці як фреймворку і до фронту. Що б ти додав а рейки або прибрав з неї, з точки зору фронтенд розробки? Може взагалі прибрав би фронт з рейки?

Я б не прибирав фронт. Мені здається, рішення, які є зараз, дозволить нам вижити у 80% проектів, принаймні таких, які є на ринку. Інгода дуже зручно мати такий функціонал.

Навіть коли ми говоримо про складання файлів, яка насправді не збірка, а просто конкатенація в правильному порядку. Я вважаю, що це погано.

Я чув, що не люблять турболінкс, хоча я до них ставлюся цілком нормально, використовую їх у деяких проектах.
Так, іноді доводиться витратити багато часу на те, щоб збагнути, як все правильно робити. Але це привчає до порядку. Мені було простіше: я не писав сценарії, я відразу почав писати single page applications. Доводилося думати про те, як виділяти ресурси, як їх правильно гасити, про сервіси, про життєвому циклі програми, про те, що воно може працювати тривалий час. Коли ти робиш простий мультистраничный сайт з вкрапленням скриптів, ти про це не замислюєшся.

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

Не знаю, що я б додав прямо на рейки. Є тенденція викидати все непотрібне, полегшувати, залишати рейки тільки для API. Правильно?

Там є окрема гілка, пов'язані саме з Rails API розробкою, відключенням непотрібних речей.

Так, це стосується і складання. Якщо ти запускаєш рейковий проект, напевно було б здорово вміти якось керувати процесами, які запускаються. Зараз це не просто rails сервер, або який-небудь Sidekiq. Було б кльово вміти моніторити процеси, які запускаються для збірки, які Node.js-процеси запускаються. Було б круто щось таке придумати. Хоча і тут можна запропонувати рішення начебто Foreman або Hivemind.

якщо ми почали говорити про інструменти: за якими ти зараз стежиш? Які проекти тобі подобаються, на які варто звернути увагу?

У деяких випадках я користуюся Webpack, мене він цілком влаштовує. Я розумію весь гумор, який стоїть за тим, що у нього складна конфігурація. Мені здається головною концепція, що модулі це кльово. Я довго користувався складальником Brunch. Його завжди обходили стороною, він залишався в тіні. Але для мене це ідеальний інструмент, коли потрібно щось дуже швидко накидати, коли потрібні просто модулі в стилі common js, коли потрібна дуже швидка збірка. Тому що він дійсно працює дуже швидко. Мене вразило, що багато хлопців, які роблять фреймворки, починають ліпити boilerplate і command line tools, наприклад Ember CLI, або штука для React, яка з'явилася нещодавно. У випадку з Ember мене вразило те, що ти дуже жорстко прив'язаний до збирача, ти не можеш вибрати інший складальник крім Broccoli (який я тоді взагалі не зміг налаштувати, і він збирав все ну дуже довго). Принаймні, на моїй машині це працювало вічність.

У мене був досвід роботи з Ember, ми свій проект до кінця збирали на Brunch. Навіть враховуючи те, що довелося дуже багато перенести під себе, тому що все спілкування перейшло на Ember CLI і, ми все одно користувалися Бранчем, терпіли. У нашому випадку, ми пожертвували зручністю в користь швидкості і швидкої збірки, тому що у нас було багато файлів і ми не могли собі дозволити чекати вічність.

Ти не намагався влитися в open source історію і почати допомагати якихось проектів? Якщо так, то куди ти коммитил?

Так, у мене є коміти. Я б не назвав себе активним помічником. Коммитил під фронтендовые проекти на рівні дрібних пулреквестов.

У мене є кілька своїх open source проектів (якщо можна так сказати). Можливо, вони не дуже цікаві, не отримали багато зірочок на гітхабі, але все ж. Я писав врапперов для роботи з драйверами під Node.js для одного з моїх хобі-проектів. Я робив щось на зразок розподіленої друку фотографій з Инстаграма, знайшов прикольний маленький принтер для фотографій і підключив його до Raspberry. Благо на Raspberry працював Node.js довелося його збирати. Написав щось на зразок агентій системи (не знаю, чи правильний це термін чи ні). Ідея була в тому, щоб підключати такі принтери-пристрою і потім друкувати фотографії в довільній станції. Все це лягло в основу мого дипломного проекту, який я повністю виклав на гитхаб, я цим в якійсь мірі пишаюся. Мати гитхаб це здорово, і використовувати його для освіти теж. Взагалі дипломний проект вийшов досить прикольний.

Де ти береш інформацію про фронті: ресурси, твіттер-акаунтів, за якими ти стежиш, новинні сайти? Про Ruby ми всі знаємо куди дивитися, на що підписатися, а з фронтовою частиною особисто у мене з ходу нічого не приходить на розум.

На першому місці для мене стоїть Code Hipsters. Навіть якщо я не читаю статті, не шукаю їх, я все одно користуюся телеграмом і читаю канал Code Hipsters c величезним задоволенням. Звичайно, я трохи по-іншому його сприймаю, тому що це мої друзі.

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

Ще мені подобаються подкасти. Я слухаю Вебстандарты. До речі, в недавньому випуску вони питали, хто які подкасти слухає — виявилося, що ніхто нічого не слухає :).

FrontFlip, напевно?

Ні, не пішла, взагалі не виходить слухати російськомовні подкасти. Я слухаю The Changelog, ще мені подобається подкаст від Thougtbot. Ще Giant Robots, мені дуже подобається стиль, атмосфера. Зазвичай це два спікера, і створюється враження, що вони просто зустрічаються на вихідних, обговорюють, що у них сталося, забувають що є тема для подкасту. Але це все одно цікаво слухати. Це навіть два подкасту, один скоріше про бізнес (це подкаст від одного з творців foreign key і ще якийсь платформи. А про розробку це подкаст хлопця який теж буде на RailsClub, який підтримує Phoenix для Elixir.

Про що ти будеш розповідати на RailsClub нам, бекенд розробникам?

Про те, що фронтенд поскакав далеко і фреймворк за цим не встигає. Я буду розповідати про те, як збирати фронтенд в оточенні рейок, які є рішення, які є проблеми. І чому це насправді потрібно. Буду намагатися спиратися на свій особистий досвід.

Як я розумію, ти не був раніше на RailsClub. Що ти чекаєш від конференції?

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

У мене була цікава ситуація: в минулому році ми поїхали на Frontend Union Conf, вона була в минулому серпні в Москві, в цьому десь у Прибалтиці. Ми приїхали всією тусовкою, але так втомилися з дороги, що дуже складно було впіймати хвилю доповідей, ми слухали одним вухом. Драйв почався на афтепаті. Ми познайомилися з хлопцем з SoundCloud, Jan Monschke. Я не пам'ятаю, який у нього був доповідь, але після спілкування конференції запам'яталося. Він кльовий чувак, розповів нам про свої проекти. Мова зайшла про Brunch, збирача про який я вже говорив. І з'ясувалося, що він був одним з чуваків, які розпочали цей проект. Да ладно!? Це саме те, для чого потрібно їхати на конференції: спілкування. Ну і доповіді теж :)

Крім розробки, чим ти захоплюєшся? Читаєш, співаєш, граєш на чомусь, ходиш в гори?

Сode Hopsters, хоча це швидше пов'язано з роботою. Я можу сказати, що мене надихають (і в роботі, і в житті) багато речей, які я дізнався, коли був дитиною. У дитинстві мені подобалися всякі штуки, механізми. У мене була невелика майстерня, в якій я робив з дерева всякі луки, арбалети. На жаль, у мене не було наставника, який би показав як можна підключити все це до електрики, як робити більш просунуті штуки.

Коли я натрапив на книгу, яка називається Код, її написав Charles Petzold. Книга була цікава тим, що розповідала про дитинство: уявіть собі, що у вас є друг, ви живете у будинках навпроти. І ви захотіли спілкуватися, подаючи один одному таємні знаки. Ви дістаєте ліхтарик, починаєте малювати на стіні його будинку літери. Потім він плавно переходить до кодів і абетці Морза, азбуки Брайля, розповідає про телеграф. Якщо ти хочеш робити телеграфний зв'язок, тобі потрібен повторювач, а повторювач можна зробити на основі реле… І тут починається найцікавіше. По книзі можна зробити всякі logiс gate і тд. Спойлер: книга закінчується тим, що він показує як на асемблері писати прототип операційної системи. Ця книга — ідеальне опис того, що мене надихає, ось такі уявні експерименти.

Ще мені подобається, коли код якось переплітається з дизайном. Можу порадити книгу "The Nature of Code", вона написана звичайним мовою, але показує як писати processing, як моделювати природні системи, типу зграї птахів і так далі. Такі речі мене дуже надихають. Я думаю, це в якійсь мірі визначає те, який я розробник, то, як я працюю і живу.

Скільки у тебе проектів і який ти зараз використовуєш фронтенд стек?

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

Якщо я розумію, що проект з великою кількістю станів, не вимагає сильної інтерфейсної логіки, то чому б не зробити його multipage, чому б не зробити його на рейках, у них все для цього є.

Якщо вдаватися в подробиці, то я користуюся Slim, пишу на SCSS. Я помітив, що коли довго пишеш single page програми, фронтенд змінює тебе. У нас був складний проект: окремий бекенд і багато single page додатків. Всі вони були написані на ember.js.

Взагалі у ember цікавий шлях, від моменту як визріла ідея, до моменту коли навколо нього почало з'являтися ком'юніті і він почав змагатися з react по продуктивності. Я дуже задоволений цим фреймворком, у ньому все є для швидкого старту. Якісь речі бентежать, особливо це стосується connection over configuration. Хлопці, які робили Ember (Єхуда Кац з rails core team), надихалися рейками і постаралися перенести багато принципів. Мені здається, що не все вийшло здорово. Connection over configuration у фронтенд проектах, на мій погляд, — це дуже сумнівно. Мені простіше написати більше фронтового коду, ніж покладатися на якісь речі, які вбудовані у фреймворк. З іншого боку, дуже багато зручних help'єрів, можна швидко стартувати проект і так далі.

Повертаючись до теми multipage. Я помітив за собою, що на рейкових проектах, які не використовують зовнішній складальник, а повністю покладаються на assets pipeline, я починаю організовувати свої фронтендные файли в якусь структуру, писати сервіси, організовувати все в якусь подобу view. Хоча це просто чисті ES6 класи, які отримують в конструкторі рутовую ноду, від якої можна працювати. Такий полегшений backbone view, але тільки без всього, просто для ізоляції. Я думаю, що це хороша тенденція. Це дозволяє і кодову базу тримати в хорошому стані, і уникати ефектів, які часто вилазять при її розростання.

Зараз йде якесь протиборство Angular і React. Ти на чиєму боці, на темній або світлій? І що є темна, а що є світла?

З Angular я практично не працював. Розумію, до чого ти хилиш, але про це складно розмірковувати. Я вважаю, що ці суперечки позбавлені сенсу. Не потрібно шукати хто головний, хто правий, хто ні. Потрібно розуміти, хто в якій ситуації гарний, де краще використовувати. Якщо буде додаток, в якому я буду бачити чітку структуру, переходи, роуты, авторизацію, завантаження і так далі — я, напевно, поклався б на Angular. Хоча очі його ніколи не бачив, але я припускаю, що там дуже багато підтримки для таких речей. Якби потрібно було писати якийсь віджет, що вбудовується частина, якесь просте додаток, з невеликою кількістю станів, в цьому випадку, мабуть, виберу React. Я не став би орієнтуватися на вимірювання продуктивності і якісь фічі типу серверсайд рендеринга. Я вважаю, що ці питання надто багато обговорюють, серверсайд рендеринг того не варто. У реальності це потрібно в 10% випадків, принаймні, мені так здається. Тому я б дивився на ті речі, які фреймворк пропонує: на те, що буде корисно для команди, для всього проекту, для компанії.

тобто ти займаєш у цій війні нейтралітету?

Так! Якщо б мене попросили порадити щось наступному поколінню, я б порадив прочитати цікаву статтю про те, як бути 40-річним розробником. Автор дуже цікаво розповідає про все своє життя, чому його навчила робота більше ніж у 10 компаніях. Він говорить дуже важливу думку: не покладайтеся на хайпи, це помилкове відчуття, намагайтеся дивитися на все тверезим поглядом. Оцінюйте, не покладаючись на короткочасні почуття. Я вважаю, це дуже мудро. Я б теж хотів дотримуватися такої позиції.

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

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

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

0 коментарів

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