Ruby NoName podcast

Разбирая архивы мы нашли неопубликованные эпизоды. Этот материал был записан во время RailsClub 2016. Но уже скоро RailsClub 2017.

Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

Разбирая архивы мы нашли неопубликованные эпизоды. Этот материал был записан во время RailsClub 2016. Но уже скоро RailsClub 2017.

Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции.

В этот раз мы поговорили с Ильей Зыкиным.

Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции.

В этот раз мы поговорили с Иваном Немытченко.

Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции.

В этот раз мы поговорили с Владимиром Дементьевым про Action Cable, обучение и open source.

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

Все очень просто - я сам себе заказчик. Я один из основателей этого стартапа, двое моих партнеров не имели достаточной технической экспертизы, поэтому доверяли мне. Надеюсь, они не ошиблись и не жалеют об этом :) Выбор технологий был за мной. Вопрос был только в том, чтобы найти время на переход с одной версии на другую. Ну и деньги, естественно. Когда момент настал, мы переписали все на рельсы, и вот эта третья (или четвертая) версия системы работала быстро, четко, все были довольны - как мы, так и клиенты.

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

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

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

Но найти разработчика на эрланге не очень просто. Тот единственный эрлангист, который у нас был, пришел студентом, он знал С и отлично знал математику, у него было олимпиадное прошлое и он хотел работать. Как эрлангиста мы его воспитывали с нуля. Он, кстати, до сих пор работает в проекте.

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

Когда стоял вопрос о переходе на Rails, был альтернативный вариант сразу переходить на Erlang. Я готов был это сделать. Наверное, мы бы дольше стартовали, но вероятно это было бы лучше с точки зрения эффективности. Хорошо, что мы этого не сделали: наши нагрузки не требуют каких-то жутких оптимизаций, и рельса вполне справляется, а скорость разработки дает намного большую. Сейчас я не думаю, что Phoenix можно полностью заменить рельсы именно с точки зрения построения бизнес-логики, слоя работы с данными.

Все что касается запросов, сокеты (это отдельный разговор мы к нему вернемся) - с этим в Phoenix все неплохо. Но Active Record (или его альтернативы) и экосистема вокруг него пока гораздо удобнее, чем все, что есть в Elixir. Это логично, там другая парадигма, там не так просто сделать удобный для использования инструмент. Поэтому, на мой взгляд, Elixir и прочие, с Phoenix или без, - это скорее технологии для идеологии микросервисов. Нужно использовать их в какой-то тяжелой части, в которую стучится очень много клиентов, с какими-то задачами, запросами. Такие части можно писать Elixir, решать их несколькими разными сервисами. А основная логика должна, мне кажется, оставаться в рельсах, если изначально была написана на них. Но даже если бы я сейчас начинал проект с нуля, я бы все равно не стал делать все на Elixir.

Во-первых, долгое время я был в Teachbase единственным разработчиком. Я начал набирать команду только в последнюю пару лет, когда у нас появилась такая возможность. Проблема для меня, как для разработчика, была в том, что я много всего попробовал, много нового узнал, но в основном на собственном опыте. Я никогда не работал в команде под руководством кого-то, кто был опытнее меня и имел какие-то знания, которых у меня не было. Это была одна из причин: мне было скучно, я понимал, что мой самостоятельный рост в Teachbase будет идти тяжело. Особенно, когда проект стабилизировался, не было каких-то супер интересных задач, только текучка типа добавления фич, нет воли творчеству.

Я рассматривал марисан, в первую очередь, так как я был знаком с некоторыми ребятами, я был на курсе Brainwashing, с тех пор у меня остались самые приятные впечатления об этой команде. Мне очень хотелось поработать с такими людьми, поделиться опытом, поделиться своими идеями. Когда я работал в Teachbase, мне не с кем было обсудить какие-то технические идеи, не было людей, которые разбирались бы хорошо в технических аспектах. Поэтому я хотел попасть в сильную команду.

Я бы поставил вопрос по-другому: что в рельсе лишнее, что мешает.

Фронтовая часть и сборка ассетов с помощью Sprockets, на мой взгляд, уже устаревшая схема. Фронт сейчас пишется со своими сборщиками, там своя очень развитая экосистема. Которая работает, по моему опыту, гораздо приятнее, чем Sprockets. Это быстро, удобно, куча дополнительных возможностей, тонкая настройка и так далее.. Тот же автопрефиксер вставить в Sprockets, конечно, можно. Но если вставить еще 20 аналогичных плагинов, то ассеты, скорей всего, будут собираться очень долго. Я использовал рельсу, по большей части, неклассическим образом, с серверным рендерингом, используя javascript шаблоны и подобные вещи для обновления странички. Я использовал Rails практически в API режиме, только JSON. HTML-странички отдавались также рельсами, но была идея избавиться и от этого, грузить статику отдельно, так как динамического рендеринга был минимум, например, : вставка логотипа налету. Все фишки типа шаблонов,Turbolinks, вот это все, должны быть отдельными примочками к рельсам. Если хочешь - добавляй.

Потому что на тот момент во фронте был популярен только Grunt, ужасный и монструозный, на мой взгляд. Он долго меня отталкивал от использования всего этого, пока не появились более приятные глазу альтернативы. Если говорить про текущий момент: если бы я сейчас начинал новый проект и брал бы в качестве бэкенда рельсу, я бы, учитывая, что у нас в Rails 5 есть встроенный API режим, сразу бы делал так, чтобы отдельно один проект делали фронты, отдельно бэкенды. Это очень удобно и с точки зрения разработки. Незачем фронту поднимать сервер, копаться там. Пусть он делает фронтовую работу и не знает, что на сервере. Пусть просто работает по спецификации, которую дают бэкенды.

Все зависит от того, какой проект, конечно.

Хороший вопрос. Если вопрос стоит как “что-нибудь другое на Ruby” - то нет. Во первых, у меня нет особого опыта. Я пробовал микрофреймворки типа Cuba, Sinatra. Такие микро-микросервисы, просто экспериментировал и смотрел, что это и зачем. Большие альтернативы, типа Trailblazer или Hanami, я не пробовал, они меня, в принципе, не заинтересовали. Я пока не понял, зачем они мне. Да, я видел бенчмарки, там все классно, быстро. Но рельсы и руби выбираются не для того, чтобы было быстро, а для того, чтобы было удобно. Поэтому такой аргумент для меня не самый важный.

Вот! Сложно тягаться в Rails, на котором пишут все, с них многие начинают свой путь в Ruby. Реальные конкуренты рельсам сейчас не внутри Ruby, а Elixir и Phoenix, которые набирают обороты. На мой взгляд это происходит отчасти потому, что Elixir хорошо пиарят. Его научились продавать командам разработчиков, говорят что Elixir классный, у вас все будет быстро. Даже в России уже есть люди, которые используют гибридный стек - часть рельсы, часть эликсира, все хотят его попробовать. И главное все хотят продать разработку на Elixir заказчику. Как коммерческий проект Elixir - очень классная штука. Он проще Erlang, хотя лично я бы все равно предпочел Erlang. Да, будет немножко больно, местами будет больше кода, хотя и это можно оптимизировать.

Если отвечать на вопрос “что, если не Rails”. Я бы выбрал Erlang, но только в том случае, если мне дали бы пару разработчиков и чуть больше времени. В основном, все упирается в наличие разработчиков: их мало. С Elixir тоже проблема: многие, кто начал изучать Elixir и что-то на нем сделали, сразу считают, что они знают Erlang. Это примерно та же история, как когда люди, потыкавшие в рельсы, потом говорят, что они знают Ruby. Скорее всего, рынок пострадает от этого. Найти хорошего разработчика на эрланге будет еще сложнее, потому что будет много левого мусора. Во фронте сейчас похожие проблемы: если люди, которые выучили Angular, но не понимают, что такое JavaScript. Теперь везде есть такая проблема.

Давай говорить хронологически. В школы и университете были Pascal, C, Basic, Assembler. Но в университете я пропускал программирование, оно мне очень не нравилось. Я до сих пор удивляюсь, как я так случайно стал программистом. Начинал я с ActionScript.

Да. Я начинал со второго ActionScript, он был ужасен. А вот в третьем появилось очень много изменений: нормальные классы, прокси объекты, которые все так ждут сейчас в JavaScript (но пока там не очень хорошо с поддержкой). Много всего классного, удобного. Как язык он был прикольным. Со своими минусами в виде не очень простой компиляции, в которой, если у тебя не Flash Builder от Adobe, приходится много колдовать. У меня был очень большой проект в рамках Teachbase, когда мы начали делать свое решение для вебинаров. Оно состоит из двух частей: клиентской и серверной. В серверной был Erlang, а в клиентской - большое ActionScript приложение. Это был мой первый большой проект, я продумывал его с нуля, с серьезной архитектурой, там было много классных идей. Это приложение до сих пор работает. В нем нет багов, я последний раз его правил два года назад! С тех пор оно классно работает. И это очень хорошо, потому что я даже не знаю, как мне его теперь собрать, запустить и так далее, у меня нет никаких систем сборки, и я уже плохо помню, как там все устроено.

Да, он очень старый, но еще жив, на нем пишут. Особенно много используют в игровой индустрии, сделали очень много оптимизаций с точки зрения графики, рендеринга, использованием GPU и так далее. На нем можно писать классные игры. Кажется, какая-то из популярных онлайн игр, типа танков, была изначально на flash. Сейчас не знаю, может, до сих пор.

Был период, когда эти технологии были во всем реалтайме, когда, например, нужно было сделать видеочат, когда не было и намека на другие технологии, flash был везде. Это сейчас он мало у кого стоит. На Flash раньше было реализовано то, что сейчас есть в Web RTC, peer-to-peer. Этот проект в итоге был заброшен. Изначально он назывался Stratus, мы даже делали на нем побочный проект - портал для психологов с возможностью консультации онлайн. Работало через раз. Сейчас те вебинары, которые существуют и работают просто в браузере, заявляют, что используют Web RTC, но в большинстве случаев это не так. Именно для стриминга по прежнему используется flash, rtmp. Там он еще жив.

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

Все получилось случайно и просто. Есть такая замечательная площадка Coursera, когда она только появилась, там было где-то пять курсов, один из них был про SaaS разработку и так далее. Этот курс, фактически, был таким введением в Rails, тогда еще 3. Не сказать, чтобы я выучил рельсы по этому курсу. Это был очень простой курс, вывод одной страницы и поиск по элементам из базы. Но там было хорошо рассказано про тестирование, про все его уровни. После этого я написал какой-то микро-микросервис для нашей системы. Очень страшный, некрасивый, он даже был запущен через rails s в development режиме. Но он работал, практически не падал.

Да, они подкинули вдохновения в этом направлении.

Если дальше говорить о языках, потом был Erlang.

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

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

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

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

Конечно, я всегда там что-то правлю, что-то отключаю, что-то включаю.

По-разному. Сейчас я, например, пришел в проект с большой кодовой базой и мы прикрутили обязательную проверку rubocop’ом, но там у нас очень минимальный конфиг, который проверяет на очень плохие вещи, типа забытого дебага в коде или фокусы в спеках и так далее. И еще у нас включено несколько оптимизационных копов. Вещи типа длины строки, количества строк в методе и так далее мы в этом проекте не проверяем.

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

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

Пустую строку в конце я всегда ставлю. Делаю это, потому что так удобно перейти в конец файла. Есть некоторый отступ снизу, тебе не надо попадать в границу дисплея. Я где-то читал, какими историческими ограничениями это правило было вызвано, в каких-то старых системах. Точно уже не воспроизведу, что там было. И сейчас гитхаб постоянно это подсвечивает в диффах, ругается когда у тебя нет пустой строки - это не очень приятно.

В моем дефолтном конфиге на нулевом проекте многое включено, но эти параметры сложности немного увеличены. Если где-то очень большая сложность, и я не хочу рефакторить какой-то метод осознанно, то я просто отключаю этот коп локально, да и все. Но во всех гемах, которыми я занимаюсь, или в которые я активно контрибьютил, внедрял это дело.

Я много работал над проектами из экосистемы 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.

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

Когда ученики хорошие - нравится, когда плохие - нет. Я очень нервный человек, мне хочется всех послать. В этом плане я скорее тренер, чем учитель, я довольно жесткий. При этом мне нравится общаться с теми, в ком я вижу интерес. Не обязательно должно получаться, но когда ребята стараются, это очень классно, с ними можно поговорить, мы периодически встречаемся лично. Они задают интересные вопросы, которые меня самого заставляют подумать. В целом, любой вид преподавания, особенно если ты преподаешь что-то связанное с твоей профессиональной деятельностью, - это бОльшая прокачка для того кто преподает, чем для тех, кто учится. Помимо знаний, которые получаешь по Ruby, про то как общаться с людьми, можно оттачивать свое ораторское искусство, общение с публикой по ту сторону кабеля, когда проводишь вебинары. Плюсов в этой деятельности много, минусы тоже есть. Есть рутина, когда ты третий раз ведешь один и тот же курс, тебе не так интересно. Ждешь, когда ученики уже дойдут до интересных тем, чтобы с ними было о чем поговорить, а то все какую-то фигню делают :).

Давай вернемся в весну 2015. За некоторое время до того, как состоялась конференция, на которой DHH объявил об этой замечательной фиче.

У меня к ней двойственное отношение. В чем-то замечательная, в чем-то “замечательная”. В любом случае, это громкая фича.

Хорошее впечатление от Action Cable относилось в первую очередь к каналам, к тому, что сделано непосредственно в Rails, обертке бизнес-логики. Мне очень понравилось, как все сделано: очень rails way, все как надо. Но была и вторая мысль - а на чем это будет? Это мысль пришла мне в голову, когда репозиторий самого кабеля в исходниках отдельно выложили на гитхаб. Тогда это работало на Celluloid, если я правильно помню. То есть это было реализовано на Ruby, что, конечно, не круто. У меня предвзятое, но распространенное мнение, что писать конкурентные программы на Ruby не нужно. Это не то, для чего этот язык был создан, особенно если говорить о масштабируемости и эффективности с точки зрения потребления ресурсов.

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

Тогда возникает вопрос, а какие вообще проблемы может решать Action Cable?

Может быть. По крайней мере, протокол веб сокетов подписан как ActionCable, но в какой сервер он стучится - мы не знаем. Протокол очень похож. К сожалению, инсайдерской информации оттуда нет. Но я не удивлюсь, если на самом деле там работает какой-нибудь сервер, который просто работает по тому же протоколу, может быть общается с рельсой, хотя на самом деле для того, что они делают, это и не нужно делают они буквально два сценария: отправить изменения, которые произошли на странице (кто-то написал комментарий, отправил тудушечку и так далее). Это бродкаст, первый сценарий. И сценарий, который, наоборот, от клиента отправляет информацию серверу о том, что человек делает на страничке. Она передается в несколько зашифрованном виде, но там примерно следующее: перешел на страничку или закрыл вкладку, трекинг активности некоторый.

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

Я первый раз ходил на конференцию в прошлом году. Чего-то о прямо очень зацепившего не было. Но были хорошие докладчики, например Claudio Baccigalupo, который говорил про Rails 5. Доклад Koichi Sasada про garbage collector, историю с поколениями, был очень сильный и интересный. Я понимал, наверное, процентов 70, но это было очень круто. Но я думаю, что любая конференция ценна не столько докладами, а тем, что происходит в кулуарах. Поэтому такого общения я и жду, учитывая что у нас приезжают “звезды”. Не знаю, насколько они будут готовы выйти в народ пообщаться, но это интересно.

Честно говоря, у меня к нему нет вопросов :)

Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции.

Первое интервью было с Лешей Тактаровым

Моя история знакомства с этими технологиями довольно нетипичная. Я начинал свою карьеру как человек, который делает системные тулзы. Я и с фронтендом тогда не встречался, просто занимался нативными интерфейсами для Windows. Какое-то время потратил на то, чтобы делать программы, которые работают с большим количеством потоков, которые работают с concurrency и так далее. А затем как-то плавно перешел во фронтенд, тогда как раз появился хайп. С Ruby и рельсами я начал работать уже после этого, и для меня это было небольшим откровением, потому что не все вещи, которые там работают, работают так как я привык. Лучший пример: в некоторых средах, где ты всегда должен следить за ресурсами, если ты что-то взял в одном потоке и работаешь, то должен быть уверен, что в другом потоке не будет проблем с этим - в ruby все эти проблемы обходили стороной. Я столкнулся с совершенно другими концепциями. И это было клево!

Если говорить конкретно - я пришел на проект как фронтендер, делал только фронтенд задачи. А потом у нас не стало бэкендера :) Он ушел, некому было решать его задачи, и я решил попробовать. Было необычно: обсудить было не с кем, человек который мне помогал был этаким мудрецом. Я приходил к нему раз в неделю, он говорил какие-то магические слова о том, что мне делать. Потом я уходил, вздыхал, думал: “О боже, что происходит”.

Через какое-то время мне вроде удалось постичь эту мудрость, хотя наверное не всю. Ту часть, которая заложена во фреймворке и языке, я почувствовал этот вкус.

Из личного - готовлюсь к свадьбе. Работаю над своим проектом, который еще слишком сырой, чтобы про него рассказывать. А еще работаю с партнером в команде, которая называется These Guys. Мы специализируемся на быстрой разработке MVP. Стараюсь по-максимум применить тот опыт, который я получил работая со Злыми марсианами, и с другими командами. Но сейчас я больше ориентируюсь сейчас не на решение технических задач, а на решение бизнес задач, продумываю как оптимально все построить для клиента.

Да. Хотя сказать об этом вслух мне сейчас очень страшно, почему-то :)

Мне кажется, что произошла такая ситуация: два или три года назад фронтенд резко скакнул и понесся вперед со скоростью локомотива, сметая все на своем пути. Ребята из других сообществ на это смотрели, кто-то скептически относился, кто-то воодушевленно. Но надо признать, что ускакал он очень далеко. В этом плане мир рельс остался без изменений.

Я всегда пытаюсь смотреть шире. Когда я вижу хайп вокруг фронтенда, я всегда пытаюсь найти и хорошие, и плохие стороны. Хорошо, что все развивается и движется, много идей, много что можно сделать такого, что поможет следующему поколению разработчиков. Но на это нужно смотреть с опаской, смотреть на то, действительно ли все так, как кажется? Это касается и компаний: какой они выбирают стек, как они общаются со своими разработчиками. Например, разработчики брали какой-то популярный сейчас стек, а потом все разваливалось. Компания переставала работать, потому что технология была сырая. У вас было такое?

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

Какое-то время назад мы с друзьями организовали в Ростове небольшую тусовочку, которая называется Code Hipsters. Это, в основном, лента новостей во вконтакте и в Телеграмме, мы пишем про всякие модные штуки во фронтенде (это и пытаемся обыграть в названии). Сейчас я немного отошел от дел, всем занимается мой друг Витя. У него прекрасный стиль, мне очень нравится как он пишет. Иногда мы собираемся и понимаем, что мы не читали за прошедшую неделю ничего нового :) Видимо, немного устали.

Последнее, о чем я слышал - это Rollup. На мой взгляд, там нет ничего революционного, но посмотреть интересно. Движение в сторону умных бандлеров, правильной сборки зависимостей я считаю очень важным, это хорошее направление. Хотя нельзя сказать, что это rocket science.

Во-вторых, компонентный подход. Он пришел давно, все его приняли, и это здорово.

В-третьих, FRP. В этом вопросе есть большая пропасть между теорией и практикой. Наверняка что-то появится, чтобы ее преодолеть.

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

Даже когда мы говорим о сборке файлов, которая на самом деле не сборка, а просто конкатенация в правильном порядке. Я считаю, что это плохо.

Я слышал, что не любят турболинкс, хотя я к ним отношусь вполне нормально, использую их в некоторых проектах.

Да, иногда приходится потратить много времени на то, чтобы сообразить, как все правильно делать. Но это приучает к порядку. Мне было проще: я не писал скрипты, я сразу начал писать single page applications. Приходилось думать о том, как выделять ресурсы, как их правильно тушить, о сервисах, о жизненном цикле приложения, о том, что оно может работать продолжительно время. Когда ты делаешь простой мультистраничный сайт с вкраплением скриптов, ты об этом не задумываешься.

Но иногда проект требует того, чтобы все это учитывалось, заставляет держать в голове паттерны, которым нас научил правильный фронтенд.

Не знаю, что я бы добавил прямо в рельсы. Есть тенденция выкидывать все ненужное, облегчать, оставлять рельсы только для 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 проектов (если можно так сказать). Возможно, они не очень интересны, не получили много звездочек на гитхабе, но все же. Я писал враппер для работы с принтерами под Node.js, для одного из моих хобби-проектов. Я делал что-то вроде распределенной печати фотографий из Инстаграма, нашел прикольный маленький принтер для фотографий и подключил его к Raspberry. Благо на Raspberry работал Node.js, пришлось его собирать. Написал что-то вроде агентной системы (не знаю, правильный это термин или нет). Идея была в том, чтобы подключать такие принтеры-устройства и потом печатать фотографии на произвольной станции. Все это легло в основу моего дипломного проекта, который я полностью выложил на гитхаб, я этим в какой-то степени горжусь. Иметь гитхаб это здорово, и использовать его для образования тоже. Вообще дипломный проект получился довольно прикольный.

На первом месте для меня стоит Code Hipsters. Даже если если я не читаю статьи, не ищу их, я все равно пользуюсь телеграмом и читаю канал Code Hipsters c огромным удовольствием. Конечно, я немного по-другому его воспринимаю, потому что это мои друзья.

Твиттер, особенно англоязычный помогает. Не назову какие-то конкретные аккаунты, это накопившийся за долгие годы слой информации. Иногда ты можешь листать ленту, и если произошло что-то действительно трендовое во фронтенде - ты это сразу увидишь, все лента будет заполнена этим.

Еще мне нравятся подкасты. Я слушаю Вебстандарты. Кстати, в недавнем выпуске они спрашивали, кто какие подкасты слушает - оказалось, что никто ничего не слушает :).

Нет, не пошло, вообще не получается слушать русскоязычные подкасты. Я слушаю The Changelog, еще мне нравится подкаст от Thougtbot. Еще Giant Robots, мне очень нравится стиль, атмосфера. Обычно это два спикера, и создается впечатление, что они просто встречаются на выходных, обсуждают, что у них произошло, забывают что есть тема для подкаста. Но это все равно интересно слушать. Это даже два подкаста, один скорее про бизнес (это подкаст от одного из создателей foreign key и еще какой-то платформы. А про разработку это подкаст парня который тоже будет на RailsClub, который поддерживает Phoenix для Elixir.

А про фронтенд это The Changelog.

О том, что фронтенд ускакал далеко и фреймворк за этим не поспевает. Я буду рассказывать о том, как собирать фронтенд в окружении рельс, какие есть решения, какие есть проблемы. И почему это на самом деле нужно. Буду стараться опираться на свой личный опыт.

Много интересных знакомств. Я бы хотел увидеть много ребят с горящими глазами. Да и вообще ребят, которые готовы пообщаться, не только на тему конференции. Конференции интересны людьми.

У меня была интересная ситуация: в прошлом году мы поехали на 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 по производительности. Я очень доволен этим фреймворком, в нем все есть для быстрого старта. Какие-то вещи смущают, особенно это касается Convention Over Configuration. Ребята, которые делали Ember (Ехуда Кац из Rails Core Team), вдохновлялись рельсами и постарались перенести много принципов. Мне кажется, что не все получилось здорово. Convention Over Configuration во фронтенд проектах, на мой взгляд, - это очень сомнительно. Мне проще написать больше фронтового кода, чем полагаться на какие-то вещи, которые встроены во фреймворк. С другой стороны, очень много удобных help'еров, можно быстро стартовать проект и так далее.

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

С Angular я практически не работал. Понимаю, к чему ты клонишь, но об этом сложно рассуждать. Я считаю, что эти споры лишены смысла. Не нужно искать кто главный, кто прав, кто нет. Нужно понимать, кто в какой ситуации хорош, где что лучше использовать. Если будет приложение, в котором я буду видеть четкую структуру, переходы, роуты, авторизацию, загрузки и так далее - я, наверное, положился бы на Angular. Хотя в глаза его никогда не видел, но я предполагаю, что там очень много поддержки для таких вещей. Если бы нужно было писать какой-то виджет, встраиваемую часть, какое-то простое приложение, с небольшим количеством состояний, в этом случае, наверное, выберу React. Я не стал бы ориентироваться на измерения производительности и какие-то фичи типа серверсайд рендеринга. Я считаю, что эти вопросы слишком много обсуждают, серверсайд рендеринг того не стоит. В реальности это нужно в 10% случаев, по крайней мере, мне так кажется. Поэтому я бы смотрел на те вещи, которые фреймворк предлагает: на то, что будет полезно для команды, для всего проекта, для компании.

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

Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

В первом эпизоде этого года мы поговорили с Антоном Давыдовым про Google Summer of Code, Hanami и open source в целом.

The Well-Grounded Rubyist

На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции.

Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.

На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции.

Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.

На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции.

Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.