podcast_image

Ruby NoName podcast

Каталог
Подкастинг
Технологии

Серия русскоязычных подкастов о языке Ruby, фреймворке Rails и различных других техонологиях, с ними связанными, начиная от PostgreSQL и Redis, и заканчивая JavaScript. Каждый выпуск состоит из двух частей — короткий блок новостей в мире Ruby, и длинный блок, состоящий из обсуждений и интервью с различными участинками русскоязычного Ruby-сообщества

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Владелец: Kir Shatrov, Andrey Deryabin
Выходит c 23.01.2012
Последний выпуск от 22.09.2017
Я автор

Выпуски (79)

Ruby NoName Podcast S08E08

Разбирая архивы мы нашли неопубликованные эпизоды. Этот материал был записан во время RailsClub 2016. Но уже скоро RailsClub 2017. Ссылки Профиль на Github Twitter Asakusa.rb Kaminari Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.
22.09.2017

Ruby NoName Podcast S08E07

Разбирая архивы мы нашли неопубликованные эпизоды. Этот материал был записан во время RailsClub 2016. Но уже скоро RailsClub 2017. Ссылки Страница в wiki Профиль на Github Twitter Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.
21.09.2017

Ruby NoName Podcast S08E06

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. В этот раз мы поговорили с Ильей Зыкиным. Ссылки Профиль Ильи на Github Основной работодатель Аркадий Забажанов Сhewy – Ruby обертка над ElasticSearch Открытая кухня Анны Нечаевой Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.
16.10.2016

Ruby NoName Podcast S08E05

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. В этот раз мы поговорили с Иваном Немытченко. Ссылки Профиль Ивана на Github Персональный сайт Проекты с RailsRumble Tequila – HAML-like JSON generator Quiz - Ruby or Rails Статистика Quiz HappyDev - Теплая и ламповая ИТ-конференция Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.
15.10.2016

Ruby NoName Podcast S08E03

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. В этот раз мы поговорили с Владимиром Дементьевым про Action Cable, обучение и open source. Ссылки Профиль Владимира на Github первый проект Владимира – Teachbase Универсальный RPC фреймворк Brainwashing – Курс по Ruby on Rails Rubocop Первый open-source коммит в pry-byebug InfluxDB - БД написанная на языке Go Influxer - InfluxDB ActiveRecord-style Telegraf - сборщик логов Thinknetica Расшифровка эпизода, опубликованная на Habrahabr Расскажи немножко о себе? В 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 этого года пока не опубликована информация о докладах, есть только люди. Посмотрим, что нас ждет. Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.
30.09.2016

Ruby NoName Podcast S08E02

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. Первое интервью было с Лешей Тактаровым Ссылки These Guys Code Hipsters - Ироничные новости фронтенд-разработки глазами бьюти-кодеров Rollup - Next-generation ES6 module bundler Webpack – A bundler for javascript and friends Foreman – Manage Procfile-based applications Hivemind – The mind to rule processes of your development environment Статья Равиля Brunch – A Front end build system CODE. The Hidden Language of Computer Hardware and Software - Код. Тайный язык информатики The Nature of code Being A Developer After 40 – Каково это — быть разработчиком, когда тебе сорок перевод Расшифровка эпизода, опубликованная на Habrahabr Как ты пришел к 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. А про фронтенд это The Changelog. О чем ты будешь рассказывать на 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 по производительности. Я очень доволен этим фреймворком, в нем все есть для быстрого старта. Какие-то вещи смущают, особенно это касается Convention Over Configuration. Ребята, которые делали Ember (Ехуда Кац из Rails Core Team), вдохновлялись рельсами и постарались перенести много принципов. Мне кажется, что не все получилось здорово. Convention Over Configuration во фронтенд проектах, на мой взгляд, - это очень сомнительно. Мне проще написать больше фронтового кода, чем полагаться на какие-то вещи, которые встроены во фреймворк. С другой стороны, очень много удобных help'еров, можно быстро стартовать проект и так далее. Возвращаясь к теме multipage. Я заметил за собой, что на рельсовых проектах, которые не используют внешний сборщик, а полностью полагаются на assets pipeline, я начинаю организовывать свои фронтендные файлы в какую-то структуру, писать сервисы, организовывать все в некое подобие view. Хотя это просто чистые ES6 классы, которые получают в конструкторе рутовую ноду, от которой можно работать. Такой облегченный backbone view, но только без всего, просто для изоляции. Я думаю, что это хорошая тенденция. Это позволяет и кодовую базу держать в хорошем состоянии, и избегать эффектов, которые часто вылезают при ее разрастании. Сейчас идет какое-то противоборство Angular и React. Ты на чьей стороне, на темной или на светлой? И что есть темная, а что есть светлая? С Angular я практически не работал. Понимаю, к чему ты клонишь, но об этом сложно рассуждать. Я считаю, что эти споры лишены смысла. Не нужно искать кто главный, кто прав, кто нет. Нужно понимать, кто в какой ситуации хорош, где что лучше использовать. Если будет приложение, в котором я буду видеть четкую структуру, переходы, роуты, авторизацию, загрузки и так далее - я, наверное, положился бы на Angular. Хотя в глаза его никогда не видел, но я предполагаю, что там очень много поддержки для таких вещей. Если бы нужно было писать какой-то виджет, встраиваемую часть, какое-то простое приложение, с небольшим количеством состояний, в этом случае, наверное, выберу React. Я не стал бы ориентироваться на измерения производительности и какие-то фичи типа серверсайд рендеринга. Я считаю, что эти вопросы слишком много обсуждают, серверсайд рендеринг того не стоит. В реальности это нужно в 10% случаев, по крайней мере, мне так кажется. Поэтому я бы смотрел на те вещи, которые фреймворк предлагает: на то, что будет полезно для команды, для всего проекта, для компании. То есть ты занимаешь в этой войне нейтралитет? Да! Если бы меня попросили посоветовать что-то следующему поколению, я бы посоветовал прочитать интересную статью про то, каково быть 40-летним разработчиком. Автор очень интересно рассказывает про всю свою жизнь, чему его научила работа больше чем в 10 компаниях. Он говорит очень важную мысль: не полагайтесь на хайп, это ложное чувство, старайтесь смотреть на все трезвым взглядом. Оценивайте, не полагаясь на кратковременные чувства. Я считаю, это очень мудро. Я бы тоже хотел придерживаться такой позиции. Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.
15.09.2016

Ruby NoName Podcast S08E01

В первом эпизоде этого года мы поговорили с Антоном Давыдовым про Google Summer of Code, Hanami и open source в целом. Антон Давыдов Профиль на Github Твиттер Moscow.rb Твиттер Сайт Rubyunderhood Твиттер Архив ведущих Hanami Luca Guidi Official Page Twitter Ишью с лотус трендмарком Ссылки Google Summer of Code 2016 Sidekiq Статья от Майка про зависимости Как начать писать в опенсорс Книги The Well-Grounded Rubyist Конференции 19 марта. Ruby Meditation 7 в Киеве 2 апреля. IT Global Meetup в Питере. Набираем программу на ruby-островок. 4-5 июня. RubyC – Cамая большая ruby-конференция на Украине
09.03.2016

Ruby NoName Podcast S07E05

На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции. Сэм рассказал нам о работе над RSpec и о том, выступить на десятке конференций в год и не потерять мотивацию. Первое интервью - с разработчиками Медузы Второе интервью - с Koichi Sasada Третье интервью - с Claudio Baccigalupo Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
03.01.2016

Ruby NoName Podcast S07E04

На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции. В интервью с Claudio Baccigalupo мы обсудили опыт Клаудио в Rails, новые языки программирования и стартап-тусовку в LA. Первое интервью - с разработчиками Медузы Второе интервью - с Koichi Sasada Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
13.12.2015

Ruby NoName Podcast S07E03

На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции. Второе интервью мы взяли у Koichi Sasada, Ruby core committer. Первое интервью - с разработчиками Медузы Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
06.12.2015

Ruby NoName Podcast S07E02

На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции. Первое интервью было с разработчиками Медузы: Саматом Галимовым и Борей Горячеевым. Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
21.10.2015

Ruby NoName Podcast S07E01

Михаил Клишин Профиль на Github Твиттер Ресурсы от Миши Клишина ClojureWerkz Cloud Foundry Docker Pivotal Pivotal Labs Tammer Saleh Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
02.06.2015

Ruby NoName Podcast S06E21

Умер Эзра @ezmobius, автор Merb, сооснователь Engine Yard Rails 4.2 active form Ruby 2.2.0-preview2 Raptor оказался Phusion Passenger active_emoji от @sferik Язык PETOOH Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
31.12.2014

Ruby NoName Podcast S06E20

Rubyconf 2014 Про статически типизированный Руби Программа конференции Записи докладов Фотоальбом Кира Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
11.12.2014

Ruby NoName Podcast S06E19

Спонсор выпуска — Vexor CI – облачный continuous integration сервис для ruby разработчиков с поминутной оплатой. С учетом поминутной оплаты, Vexor очень выгоден для маленьких проектов и эффективен для больших. Каждому новому пользователю предоставляется $10 на счет для экспериментов. Попробовать Vexor CI Релизы Новый секьюрити-релиз Rails MRI 2.1.4 Новости RailsRumble winners Coderequest.io Обзор Raptor Пост про новую админку Shopify Ernie Miller: alias/alias_method The Metal, rack 2.0 от Аарона volt.rb Inspeqtor и видео про него Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
16.11.2014

Ruby NoName Podcast S06E18

Спонсор выпуска — Vexor CI – облачный continuous integration сервис для ruby разработчиков с поминутной оплатой. С учетом поминутной оплаты, Vexor очень выгоден для маленьких проектов и эффективен для больших. Каждому новому пользователю предоставляется $10 на счет для экспериментов. Попробовать Vexor CI Расшифровки Коллекция рецептов для быстрого руби от Эрика. Интервью с Эриком Кир Первый раз в Москве? Эрик Ага, да. Кир И как тебе Москва, что думаешь о городе? Эрик Очень красивый город. Первый раз тут, и мне все очень нравится. Погода хорошая; вчера гуляли, были в музее космонавтики и в музее холодной войны — было здорово. Кир Круто. Эрик Ага. Кир Так вот. Ты работаешь в SoundCloud, в Берлине? Эрик Да! Кир Можешь рассказать об архитектуре SoundCloud? Эрик Так, в SoundCloud мы используем архитектуру микросервисов. Я работаю в команде, которая занимается платформой, проще говоря — серверным API. Публичный API — который используется, если использовать SoundCloud API — там запросы обрабатываются Rails приложением. Но вот как мы работаем.. Как только у нас появляются новые сервисы, и есть смысл их как-то отделить от основного, сделать их отдельным сервисом — мы так и делаем. В общем, мы используем Ruby, Rails, еще довольно много используем Scala, Clojure; все наши утилиты командной строки написаны на Go. Да, у нас даже сервисы на Julia есть. Все зависит от того, что лучше подойдет для задачи, которую мы пытаемся решить. Кир Интересно. То есть, как я понимаю, вы мигрировали с монолитного Rails приложения, да? Эрик Да! Думаю, многие компании, когда они развиваются и начинают масштабироваться, переходят с такой монолитной архитектуры приложения на архитектуру микросервисов. И да, мы довольно далеко в этом деле продвинулись. Кир Ясно. Давай поговорим про open source, над которым ты работал — какой проект твой любимый? Эрик Ох, их много — сложно выбрать. Не знаю, некоторые обертки над API, над которыми я работал — таких было несколько.. Я сделал octokit, обертку над API GitHub; еще обертку над API RubyGems.org, чтобы можно было доставать метаданные о gem'ах. Ну и, наверное, самая популярная обертка, которую я сделал — gem twitter. Да и gem soundcloud, я его сейчас поддерживаю, но автором был не я. Да, думаю, решать проблемы такого рода, причем несколько раз для разных сервисов, стало таким неплохим шаблоном, так что я горжусь теми gem'ами. Думаю, приемы работы над кодом, которые я использовал там, приводят к коду довольно чистому, хорошо покрытому тестами, и все такое. И, знаешь, наверное самый популярный мой gem — это rails_admin, там код и близко не такой чистый, так что для меня над ним не так приятно работать по этой причине. Каждый раз, когда с ним работаю, всегда нахожу какие-то вещи, которые стоит зарефакторить; но раз уж столько людей его используют, просто приятно было сделать что-то такое — люди постоянно ко мне подходят, благодарят. Так что им приятно заниматься по другой причине — не из-за красоты кода, а из-за пользы, которую он дает. Кир Понятно. А что вообще помогает тебе работать над новыми open source проектами? Эрик Ну, думаю, как и у всех — главная причина, наверное, в том, что когда я использую какой-то проект и нахожу баг, я вкладываюсь в проект просто чтобы пофиксить этот самый баг, или просто в какой-то степени этот проект улучшить. Иногда я начинаю проекты только затем, чтобы чему-то научиться — попробовать в деле новый фреймворк или новый язык; да, в общем, получается такое игрушечное приложение или игрушечная библиотека, и тогда нет причин не выпустить этот код как open source, чтобы другие люди могли учиться так же, как учился я, или научиться чему-то на моих ошибках. Да я и сам учусь на своих ошибках, потому что когда ты выпускаешь что-то как open source, другие люди видят твою работу, присылают пулл-реквесты, чтобы ее улучшить, и каждый раз, когда это происходит — это возможность мне чему-то научиться; другие же люди это увидят и тоже сделают какие-то выводы для себя. Кир Точняк. Ты упомянул, что в SoundCloud используется много разных языков, так вот, есть у тебя какой-то open source не на Ruby? Эрик Да, у нас есть. Кир Scala, Clojure? Эрик Да-да. Посмотри на https://github.com/soundcloud, думаю, у нас там больше сотни публичных репозиториев. И да, там есть проекты на Ruby, наш самый популярный — Large Hadron Migrator, LAM (https://github.com/soundcloud/lhm). Там идея в том, что если у тебя есть действительно здоровенная база данных (MySQL — прим. пер.), и тебе нужно сделать миграцию, с помощью этого проекта можно это сделать без даунтайма. Если на пальцах, он работает вот так: копирует таблицу, прогоняет миграцию на копии, потом на копию переносит все данные, которые скопились с момента начала миграции. Довольно эффективный способ делать миграции в БД. Нам этот проект был реально нужен, у нас были очень большие таблицы в MySQL, на которых нужно было делать миграции, а если мы делали обычные миграции, мы могли попасть на несколько часов даунтайма. Так что мы сделали такой вот инструмент. Другие компании, у которых тоже было много строк в таблицах их баз данных, большие таблицы, и нужно было делать миграции над ними, тоже оценили наше решение. Кир На каком это языке? Эрик На Ruby. Так что да, это в основном для миграций с Rails. Но у нас.. Если посмотреть на https://github.com/soundcloud, у нас есть репозитории почти на всех языках, что можно представить — Ruby, Clojure, Scala, Go.. Как я уже говорил, у нас есть код на Julia, думаю, мы его тоже выложили. Да, ну и на других языках. В SoundCloud мы гордимся тем, что всегда используем лучший инструмент для каждой конкретной задачи, а инженеры принимают решения основываясь на том, что по их мнению лучше всего использовать. Так что если давать инженерам автономию для принятия решений, последуют лучшие решения, чем если в компании просто есть правила — «использовать один язык для всего», или «использовать этот фреймворк для всего». И даже внутри нашей организации, мы иногда используем Rails, иногда Sinatra или другие фреймворки. Это действительно зависит только от характера проблемы, которую мы пытаемся решить. Кир Какое будущее у Ruby, по твоему мнению? Эрик Хм. Хороший вопрос. Надеюсь, что будущее будет таким же, как и прошлое — за последнее время каждый год выходит новая версия Ruby, и каждый раз она быстрее и лучше предыдущей. Так что да, надеюсь, такое продолжится в будущих версиях. Что я действительно хотел бы видеть (я упомянул об этом в своем докладе), так это JIT компилятор в MRI (CRuby). Кажется, над этим уже работают, так что я настроен оптимистично — думаю, скоро мы это увидим. Так же, как и AOT компилятор. Я еще работаю над парой интерфейсов для командной строки; Ruby не очень хорош для работы с командной строкой, потому что время запуска может быть большим, а вот если был бы компилятор, который бы предварительно парсил весь Ruby код в бинарник, было бы круто — особенно для штук вроде CLI (Command-Line Interface — прим. пер.). Так что вот, JIT и AOT компиляторы. И еще получше примитивы для параллелизма. Матц говорил, что он сожалеет о решении использовать Thread как главный примитив для параллелизма в Ruby, так что он вместе с Core Team думает над использованием actors, и может каких-то еще примитивов. Чтобы они появились в core библиотеках языка. Так что я этого очень жду, думаю, будет круто. Кир Да, я заметил тренд с переписыванием инструментов командной строки на Go. Эрик Да, точно. Кир Вот Heroku так делает. Эрик Да, это хороший пример. Их CLI для выполнения разных команд, раньше был на Ruby, но, вообще, думаю, он намного лучше стал на Go, по ряду причин. Во-первых, у Go весь runtime включен в бинарник, так что нет такой зависимости, как Ruby — не надо сначала устанавливать Ruby, а потом уже CLI. Можно просто установить бинарник, в котором все уже есть. Ну и то еще, что можно кросс-компилировать сразу на несколько разных платформ, делает разработку инструментов для командной строки намного проще. И вообще тот факт, что Go — язык компилируемый, означает, что никакой подготовки кода во время запуска нет, как в Ruby. Так что если есть, скажем, 30 библиотек, от которых зависит инструмент, то в Ruby даже для самой простой операции сначала нужно пропарсить все эти библиотеки, а это может занять много времени, особенно если нужно выполнить какую-то простую команду — такую, как help, version или что-то такое, и во многих CLI на Ruby это работает куда медленнее, чем должно бы. Так что AOT компилятор существенно этому поможет, Ruby сможет составить конкуренцию языкам вроде Go в борьбе за CLI. Кир Давай поговорим о Берлине. Эрик Ага. Кир Что ты думаешь о стартап-культуре, об атмосфере? Эрик Очень хорошая. Я переехал в Берлин из Сан-Франциско, где я до этого прожил 8 лет. И в Сан-Франциско чувствуется такое отношение, словно это единственное место в мире, где можно сделать стартап, и что если тебе нужно сделать стартап, то нужно переехать в Сан-Франциско, если хочешь добиться успеха. Это сработало для многих компаний, но в SoundCloud нам этого делать не пришлось. Есть много преимуществ работы в Берлине. Главное преимущество — мы можем нанимать талантливых людей со всей Европы, да и со всего мира, вообще говоря. У нас отличный офис, где есть разработчики из.. кажется, 35 разных стран, или вроде того. Думаю, эмиграционные законы США делают такое куда более сложным. У меня был такой скепсис, когда я переезжал из Сан-Франциско, но.. Мои коллеги — невероятно талантливые люди, я каждый день у них чему-то учусь. Да, Берлин — отличное место для работы. И стартап сцена — не только SoundCloud, у нас куча других стартапов! От самых маленьких, где пара человек работают над какой-то идеей, до людей, которые уже подняли венчурный капитал и теперь быстро растут. Да и просто классное сообщество и отношение. Митапы каждую неделю, наверное, даже каждый день — можно ходить на разные технарские митапы в Берлине. И вот что еще круто в Берлине: классное сообщество для тех, кто хочет учиться. То есть, если вы хотите научиться программированию, или если вы пока юниор, и вы ищете возможность подкачаться, Берлин — отличное для этого место. Вот Rails Girls начинались не в Берлине, но благодаря Travis CI, да, там много классных людей — Свен (Sven Fuchs — прим. пер.), Аника (Anika Lindtner — прим. пер.), да и вся команда — Джош (Josh Kalderimis — прим. пер.), Константин (Konstantin Haase — прим. пер.)… Такое комьюнити они создали! Меня пригласили выступить на Eurucamp пару лет назад — тогда я в первый раз оказался в Берлине, еще до того, как я туда переехал. Перед конференцией я побыл коучем на Rails Girls, и это был первый раз, когда я помогал на Rails Girls, и было круто. Но, думаю, Rails Girls проводятся в Берлине уже очень давно, теперь и Summer of Code проводится оттуда. Есть целые четыре разные команды Summer of Code, которые расположены в Берлине. Так что вот, это отличное место для того, чтобы научиться программированию и прокачаться. Кир Все, спасибо большое! Эрик Да, конечно. Спасибо за вопросы! Интервью с Божидаром Ярослав Привет, Божидар! Как тебе Москва? Божидар Все здорово. Фантастический город, счастлив, что я здесь и что меня пригласили. Это мой первый визит в Россию, для меня все в новинку и очень увлекательно. У вас прекрасный город, прекрасная страна. Ярослав Первый вопрос будет про Rubocop. Многие из наших ребят знают о gem parser нашей местной знаменитости, Петра (Зотова — прим. пер), который, кстати, выступал в прошлом году на этой самой конференции. Можешь рассказать немного о том, как parser и Rubocop работают вместе? Божидар Да, конечно. Когда я начал работать над Rubocop, я использовал Ripper, внутренний парсер MRI, у которого есть две фундаментальные проблемы: во-первых, он работает только с MRI, что сделало бы Rubocop несовместимым с JRuby и Rubinius. Во-вторых, он генерит ужасный AST. Я пытался отправить несколько багфиксов в Ripper, но стало понятно, что это ни к чему не приведет. В одном из сообщений об ошибке, которое я открыл на официальном багтрекере Ruby, кто-то упомянул, что мне лучше бы не использовать Ripper вообще, потому что есть новая библиотека под названием parser от Петра. Я ее посмотрел, она работала замечательно, выдавала отличный формат AST, в общем, делала ровно то, что нужно. Была переносимой, правда очень глючной, но я намеревался работать с ней, несмотря на это. В основном из-за Петра, отличного мейнтейнера. Я зарепортил, наверное, около 50 багов, или вроде того. И он обычно отвечал в течение пары часов. После того, как вышла первая версия Rubycop с использованием parser, обнаружилось еще больше багов — пользователи умудрялись писать такой Ruby код, что мы даже не знали о том, что так можно написать. Но в течение следующих релизов Петр все исправил, и я уверен, что это лучшая библиотека из тех, что существуют. Производительность отличная, почти так же быстро, как и с Ripper, но выдаются структуры данных намного проще, с этим намного приятнее работать. Если мне бы пришлось работать с Ripper, я бы, наверное, забросил Rubocop. Ярослав Мы говорим о Ripper, но ведь еще есть gem.. как его.. Божидар ruby_parser? Ярослав Да, ruby_parser. Божидар Да, проблема с ruby_parser была в том, что его не мейнтейнили особенно. Думаю, Петр изначально хотел улучшить ruby_parser (так и было — прим. пер.); он был совместим с Ruby 1.8, но не обновлялся для 1.9. Я видел от него несколько пулл-реквестов, но ребята, которые мейнтейнили ruby_parser, сказали, что изменения слишком сложные, или что-то в этом духе, и что они не будут их применять. Думаю, это и было мотивацией для Петра сделать новый gem. И еще дело было в том, что ruby_parser не был так производителен, как parser, так что при работе с огромными проектами это могло стать проблемой — можно было ждать целый час, пока идет анализ кода. Ярослав Ага. Следующий вопрос про твою самую известную работу — Ruby Guide. Можешь рассказать о процессе, о том как ты работаешь над ним? У тебя просто появился набор каких-то правил, ты сделал первый коммит и потом ты начал их обновлять? Как ты итерируешь, как обновляешь эти правила? Думаешь ли ты, что многие из них обязательные, или какие-то нет? В общем, твой Ruby Style Guide и Rails Style Guide не высечены в камне, они обновляются, так что хочется послушать про процесс. Например, как ты их валидируешь. Божидар Ну, обычно я делаю что-то, что называю проверкой толпой (Crowd Validation). Я добавляю правила иногда, когда натыкаюсь на хорошие идиомы в книгах, докладах; встречаю что-то, чего я раньше не замечал. Если я делаю правки и они не вызывают существенной негативной реакции в сообществе, значит, это и правда хорошая рекомендация. Если я что-то добавляю и все начинают на это жаловаться, значит, я сделал ошибку. Если мнения разделяются, мы начинаем вдаваться в детали. Например, мы делаем поиск по ruby-исходникам на GitHub, и если мы видим, что недавно добавленное или предложенное правило имеет смысл, если большинство отобранных проектов используют это правило, иначе мы его убираем, или правим существующее правило. Это уже много раз случалось. Но, в конце концов, кто-то должен проталкивать эти правила — обычно это не только я; можно видеть, что довольно много людей предлагают новые правила. Но я всегда стараюсь делать проверку, чтобы быть уверенным, что мы не предлагаем что-то, что нарушает сложившиеся практики. Так что если что-то звучит как хорошая идея, но никто ее не придерживается, мы не будем ее рекомендовать. Мы не хотим заставлять кого-то следовать стилю, который не принимается, не является естественным для Ruby сообщества. Ярослав Ясно. А ты начал с своего собственного набора правил, или ты использовал другие источники для вдохновления? Божидар Я начал с правил, которые я собрал из моих любимых книг по Ruby. В основном.. Моя любимая книга по Ruby — это, наверное, “The Ruby Programming Language”.. Ярослав Pickaxe? Божидар Не-не. Это “Programming Ruby”. Ярослав А, другая. Божидар Да. Так вот, я начал с советов из «Библии», то есть, единственной книжки, написанной самим Матцем, по крайней мере, частично. Я детально сверил стиль, который он использует, со стилем, который используется в Pickaxe. Были некоторые различия в верстке кода, например, Матц не использовал столько пустого места, отбивок, как использовал Дейв Томас, а я люблю читаемый код. Так что я взял у Дейва стиль для таких случаев. После этого, я начал добавлять вещи из “Eloquent Ruby”, “The Ruby Way” — книг, которые я считаю каноническими для сообщества. Так что начинал я оттуда, а после первого публичного релиза гайда, я получил массу отзывов — часто с приложенным анализом использования из поиска по GitHub, о котором я уже говорил. Например, все книги утверждали, что стоит избегать использования тернарного оператора, а использовать вместо него if/then/else в одну строку, но оказалось, что ни в одном Ruby проекте такого нет, наоборот, все используют тернарный оператор. Да, так что если люди хотят писать код так, кто я такой, чтобы им запрещать. Так что мы изменили это правило, да и другие правила тоже подверглись изменениям с изначальной версии. Мы обновляем правила все время. Например, когда все начиналось, еще не было Ruby 2.0 и 2.1, так что не было правил о аргументах-ключсловах (keyword arguments), использованию private на той же строке, что и определение метода, потому что это не имело смысла. Но гайд постоянно развивается, и, думаю, чем больше проходит времени, тем больше мы приближаемся к настоящей душе Ruby-стиля. Ярослав Я спрашивал, потому что еще до того, как я увидел твой гайд, был гайд от Кристиана, автора Rack (https://github.com/chneukirchen/styleguide — прим. пер.). Видел его? Божидар Да, видел. Ярослав Я его использовал неоднократно для обучения внутри команды, и только потом увидел твой гайд, который намного больше и подробнее. Божидар Да, я проводил поиски по гайдам. Я видел этот, видел веб-страницу, не помню URL, что-то от zenspider, наверное. Я видел три ресурса, но во всех отсутствовали примеры. Были правила, но без объяснений о том, почему это вообще хорошая идея. Некоторые правила были явно в противоречии с устоявшимися практиками. Это все были попытки, предпринятые одним человеком, больше похожие на личный набор правил. Вместо чего-то, что могло бы использоваться всеми, что и было моей целью. Потому что изначально я занимался документом по заказу компании. И мой проект случайно стал популярным. Ярослав Еще что хочу спросить о твоих гайдах. В каком-то смысле использование гайда по стилю — это как принятие методологии разработки ПО, методологии гибкой разработки ПО, например. Это много как можно сделать — кто-то делает все в точности по правилам, по книге, кто-то начинает использовать некоторые вещи и модифицирует их потом, и получается его собственная методология, и все такое. То есть, одни люди пишут книги, а другие люди просто используют их, как им заблагорассудится. Так как ты думаешь, как лучше всего применять твой гайд, или, может быть, как ты сам его применяешь на своих проектах, когда работаешь консультантом? Ты заставляешь людей ему следовать, или это процесс, шаг за шагом? Божидар Ну, обычно на моих проектах, Ruby Style Guide в его чистой форме дается как правило. Но это правило лишь до какой-то степени; некоторые правила абсолютны — например, не нужно мешать метод и его алиас в проекте, нужно выбрать одно название и использовать его везде. Правила про отступы тоже абсолютны, но, с другой стороны, у нас есть вещи вроде правил по метрикам: короткие методы, короткие классы, и вот они иногда довольно субъективны, нужно идти на нарушение правил: как ни старайся, иногда нельзя раздробить какую-то задачу на больше частей, чем ты уже сделал. Есть точка, после которой попытки упростить что-то просто вредны: больше это не оптимизация, ты уже делаешь код сложнее. Так что.. Есть другие такие правила, которые не следует применять вслепую.. Нужно думать. Я всегда говорю людям: это не десять заповедей, ниспосланные нам свыше. Многие из них — крайне разумные практики, и ничего плохого от их применения не случится, но нужно знать, когда их нарушать, и нужно знать, почему они были хорошей идеей изначально. Не нужно их нарушать, если нет четкой причины это делать. Ярослав Еще вопрос. Посмотрел на твой профиль на GitHub, и оказывается, что ты интересуешься Clojure. Божидар Да-а-а. Ярослав И у тебя даже гайд по стилю для Clojure есть. Не знал раньше. Так вот, в Ruby сообществе много разговоров идет.. В общем, на каждой Ruby конференции по крайней мере в России есть много людей, которым вообще не интересно разговаривать про Ruby, они хотят говорить про Clojure, Scala, функциональные языки, Elixir тоже популярная тема. Так вот, почему именно Clojure? Божидар Ну.. По той же причине, по которой я изначально выбрал Ruby. Я был очарован простотой и мощью языков из семейства Lisp. Когда я был начинающим программистом, я немного писал на Common Lisp. И потом я наткнулся на Ruby, и, хотя он не был Lisp'ом, очевидно, но в нем было много наследия Lisp. И это был язык, для работы на котором я хотя бы нашел людей, готовых мне заплатить. Rails был на волне, все хотели разрабатывать на Rails, веб. Это был хороший компромисс. Но сейчас есть Clojure, настоящий Lisp, со всей мощью, без ограничений Ruby. Все говорят о проблемах с производительностью Ruby, но, думаю, что есть ряд проблем, для которых объектно-ориентированный подход становится «бутылочным горлышком» в архитектуре. Ты сказал об Elixir, еще одном не-ООП языке, который недавно стал набирать популярность. Люди делают на нем классные вещи. Haskell становится популярным после того, как существовал уже 20 лет. Ярослав Да, но есть много людей, которые называют его академическим языком — в противовес Erlang и Clojure. Божидар Ну да, но нельзя отрицать и то, что количество open source проектов, использующих Haskell, выросло в 4 раза за последние пару лет. Не думаю, что люди занимаются на Haskell только исследованиями. Люди используют его для реальной, полезной работы. Есть известные веб-фреймворки для Haskell, его точно используют для решения реальных проблем, а не вычисления чисел Фибоначчи. Так что думаю, что с тем, как мультиядерность становятся нормой, языки, которые могут масштабироваться, языки, на которых можно строить распределенные системы, будут становиться все более и более популярными. А Ruby придется развиваться быстрее, или он потеряет в популярности. То, о чем ты говоришь — что люди на Ruby-конференциях здесь не хотят говорить о Ruby — это не случайность. Если посмотреть на Ruby-конференции в Штатах, например — всегда есть доклады об альтернативных языках. На последней конференции был доклад по Elixir, перед этим Рич Хики собственной персоной докладывался по Clojure на RubyConf (думаю, речь идет о RailsConf'2012 — прим. пер.), а это что-нибудь да значит. И еще нам нужно иметь в виду, что многие известные рубисты забросили Ruby и стали работать на других языках. Например, Аарон говорил о Хосе Валиме.. Ярослав С которого и начался Elixir, ага. Божидар Да. Я почти уверен, что ему Ruby уже не интересен — да, его компания известна среди рубистов, он все еще мейнтейнер Rails и сопутствующих проектов, что нужно для клиентов, но его настоящая страсть — Elixir. Он об этом сам несколько раз говорил. Был еще известный рубист, Фил Хагельберг (@technomancy — прим. пер.), сейчас он один из самых известных кложуристов. Ярослав Да, но он всегда был поклонником Emacs, и поклонником Lisp. Он был главным источником всего, что в Emacs было связано с Ruby. Все люди, которые начинали с Lisp в университете или школе, которые хакали на Emacs долгое время.. У них теперь время возмездия. Божидар Да, но думаю, что Ruby-программистов привлекает мощь всех этих новых альтернативных языков. Думаю, некоторые из хороших идей этих функциональных языков рано или поздно окажутся в Ruby. Я говорил об идее сделать строки иммутабельными, не уверен, как это можно сделать, учитывая что весь код, который зависит от строк, мутабелен, но люди говорят о персистентных структурах данных в Ruby. Матц говорил, что главная фича в Ruby 3.0 — фреймворк для параллелизма, видимо, похожий на actors. Весь мир ПО движется в этом направлении; нельзя отрицать и то, что нельзя бесконечно делать веб-приложения. Ландшафт рынка веб-приложений существенно изменился. Rails стал популярным, когда все веб-сайты были довольно стандартными. Была довольно статичная прослойка для представления, довольно простые модели. И сейчас все дошло до клиентских приложений, когда весь твой фронтенд — это отдельное приложение, а твое Rails-приложение — просто JSON-сервер. И ты начинаешь спрашивать себя — а нужен ли мне Rails только для JSON сервера? Почему бы мне не сделать приложение на чем-то высокопроизводительном — Java, Erlang? Потому что если избавиться от тесной интеграции представлений-моделей в Rails, его ценность резко уменьшается. Думаю, что мир ПО изменяется очень быстро, и сообщество Ruby и Rails должно реагировать мгновенно, или сгинет в геенне огненной. Как и много других классных технологий. Ярослав Депрессивно, но справедливо. Еще вопрос, чтобы не очень долго тебя задерживать. Очевидно, написание правильного Ruby — очень важная тема в эти дни. Ruby вырос, люди должны перестать делать отстойные приложения, чтобы их было проще поддерживать. Один из докладчиков на этой конференции — удаленный докладчик, правда — Сэнди Метц, она тоже рассказывает о способе писать на Ruby правильно, но она делает это с помощью книги. Вот. А у тебя есть гайд, с пятью тысячами вотчеров, кажется, на GitHub, огромное число, я точно не помню, но это все-таки open source проект, у него есть URL, надо ему поставить звездочку. Так вот, есть планы написать книгу? Божидар Да, я об этом говорил на докладе. Я запланировал написать книгу, но потом я стал мейнтейнером Cider, это IDE для Clojure, очень популярная. Пришлось много с этим работать, и это выкачало из меня все силы, которые я откладывал на Rubocop, Ruby Style Guide, Rails Style Guide, и вообще на все связанные с Ruby проекты, потому что очень уж я вдохновлен Clojure. Но моя работа с Cider сейчас в таком состоянии, что я ей более или менее доволен, так что я думаю, что продолжу там, где я остановился. И сделаю маленькую книгу, очень маленькую книгу. Но, думаю, будет здорово, если у всех правил будут описания побольше, примеры подлиннее. В Styleguide я этого сделать не могу — это как README длиной в 50 страниц, это было бы странно. Но, думаю, небольшая книга будет полезна многим. Ярослав Ну что же, удачи в написании книги. Спасибо, что зашел! Божидар Вам спасибо. Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
27.10.2014

Ruby NoName Podcast S06E17

Расшифровки Интервью с Аароном Ярослав Так, ладно, поехали. Аарон Паттерсон с нами, привет Аарон! Аарон Привет! Ярослав Так, ладно, с чего бы начать. Ты первый раз в Москве? Как тебе? Аарон Да, я первый раз в Москве, и, кстати, первый раз в России. Все потрясающе, здорово. Красивый город, вкусная еда, да и пожаловаться не на что. Ярослав Хорошо — это прямо как в Сиэтле? Аарон Ну, еда — еда совсем другая, город намного больше. Кстати, по погоде сейчас очень похоже. Я слышал, тут очень холодно бывает, так что вот. Ярослав Ага. Аарон К счастью, в Сиэтле так холодно не бывает. Не думаю, что здешнюю зиму я бы пережил. Ярослав Как у тебя впечатления о нашей руби тусовке? Это локальная группа (LUG — прим. пер.), или что-то большее? Аарон Не, намного больше. Намного больше, чем обычная локальная группа. Больше, чем наша группа в Сиэтле, это уж точно. Но да, здорово — тут столько компаний разных. Кажется, в Москве сообщество рубистов процветает. Ярослав Ага, ладно. Для начала — можешь рассказать о своей новой работе? Аарон Да-да-да. Я перешел на работу в RedHat.. недели две назад, кажется. Нет, три. Я работаю в команде, которая.. В общем, мы делаем продукт, систему управления виртуальными машинами. Да, в общем, и все — если у вас есть ферма серверов, можно поставить наше приложение и рулить всем из одной точки. Ярослав Оно на ванильных Rails, или как? Аарон Это Rails приложение. Прямо сейчас у нас есть ветка с нашими собственными патчами, и моя работа, часть моей работы — взять все наши патчи, слить их с апстримом Rails, и перевести приложение на основную версию Rails. Вот когда я с этим закончу, будет ванильный Rails. То есть, мы возьмем все изменения RedHat и запушим их в апстрим. Ярослав А какая часть твоей работы — именно опенсорс? Я могу ошибаться, но, насколько я знаю, в AT&T Interactive ты все рабочее время занимался только опенсорсом в Rails. В этот раз — это частично работа над продуктом, частично опенсорс? Аарон Вообще, продукт — все равно опенсорс, так что формально я в любом случае занимаюсь опенсорсом. Но прямо сейчас.. Не знаю, в основном работаю над Rails, в оставшееся время — над продуктом, может, 30-40% времени. Моя цель — взять продукт, перевести его на Edge Rails (последнюю версию — прим. пер.), и использовать его как контрольный пример для самих Rails. Ярослав А значит ли это.. Ну, помимо того, что продукт будет работать на последних рельсах, будут ли какие-то новые фичи в самих Rails? Так же, как Дэвид пробует кучу вещей в Basecamp, и потом вливает их в апстрим? Аарон Да, конечно. У нас есть фичи — в нашей ветке, есть разные фичи, которых нет в Rails, так что вот их я и буду вливать в апстрим. Будут новые фичи, да. Ярослав Вопрос, который меня очень интересует — работаешь ли ты плотно с ребятами из JRuby? Потому что многие в России, ну, многие из нас пришли из Java, и многим нравится JVM, потому что это явно один из самых сложных когда-либо созданных проектов.. Аарон Точно, точно. Ярослав Поэтому многие думают, что главный способ сделать Ruby быстрее и Rails быстрее — сделать так, чтобы Rails лучше работал с JRuby, и речь не о том, чтобы мьютекс просто запихнуть поглубже. Аарон Я работаю с ними немного и не напрямую. Проще говоря, я разговариваю с командой TorqueBox — мы смотрим, как сделать, чтобы Rails лучше работал на TorqueBox. И там точно будут улучшения, но это не то, чтобы.. В смысле, моя работа в RedHat — сотрудничать со всеми командами, которые используют у нас Ruby, поэтому я работаю с командой JRuby, но не только с ними. Ярослав Ага. Еще вопрос: мы начали с вопроса про Ruby комьюнити и все такое, хочу немного спросить о Seattle Ruby Brigade (Seattle.rb — прим. пер.). Вы, ребята, кажется, самая известная и хорошо организованная руби бригада, да и одна из первых, верно? Аарон Да. Ярослав Так вот как у вас.. Ну, в чем секретный рецепт, как у вас получилось все это организовать, локальную руби группу? Я спрашиваю, потому что у нас тут в Москве до сих пор есть только коммерческая конференция — уже 5 лет — с классными спикерами, но просто конференция — люди не собираются вместе, чтобы над чем-то поработать. Аарон Думаю.. Ну, честно, это все Райан Дэвис. В этом только его заслуга. Вот, что он говорит — у него был доклад на эту тему — секретный рецепт в том, чтобы собираться каждую неделю. Приходить всегда, назначить определенное время, и приходить; приходить, даже если никто еще не собирается, посвещать этому время. И тогда будет приходить все больше людей — так наша группа и выросла, она была очень маленькой, но мы постоянно встречались, каждую неделю; кто-то приходит, кто-то уходит, но мы начали собирать все больше и больше людей. Ярослав Ага. У меня есть немного спорный вопрос, он больше к докладу относится, но его пока еще не было, так что спрошу прямо сейчас. И может потом, для аудитории, ладно? Извини что спрашиваю, но Джош Пик (Josh Peek) однажды затвитил, что решение строить Rails на базе Rack было худшим его решением. Ну, он правда так сказал. Аарон (смеется) Ярослав Думая о названии твоего доклада, не мог перестать вспоминать тот твит. Получается, что чтобы перейти к Rack 2.0, поддерживать стриминг, надо переделать все API, сверху донизу. Так что ты думаешь о решении, которое было принято, когда Rails мигрировал на Rack? Это было умное решение, или может быть, или?.. Аарон Ну, я думаю.. Это было умное решение. Думаю, что у Rack не очень хорошее API, но решение было очень хорошим, например, для того, чтобы поддерживать разные веб-серверы, да? Из-за Rack можно использовать, знаешь, Unicorn, Puma, Thin, да что угодно. Любой веб-сервер, и это очень мощная фича. Так что это самая важная вещь, которую позволил сделать Rack. Так что хорошо, что Rails перешел на Rack, но теперь надо развивать API дальше. Стали ясны недостатки в API, так что надо двигать его дальше. Это была хорошая идея, но надо делать все постепенно. Ярослав Думаешь ли ты, что так называемый успех Node.js (не будем отвлекаться на порку Node.js) — это было.. Ну, проще говоря, одной из причиной этого стало отсутствие реального стриминга в Rails? JavaScript не то чтобы хороший язык, и не будем больше об этом, но.. Аарон Ну, весь бум, большой бум с Node.js — это возможность делать стриминг и все такое, и их API.. Вообще, в своем докладе.. Ты увидишь API, который я предлагаю для Rack 2.0, и там будет видно, что я вообще-то краду многое из Node.js. Я серьезно думаю, что у них хороший API. Он классный для стриминга, чтобы на нем писать простые, несложные веб-сервера, и это то, что нам стоит у них позаимствовать. Ярослав Ты сказал, что главная фича Rack, использования Rack — это то, что можно использовать разные веб-сервера. Я думаю, что одна из самых больших фич — это то, что сейчас у нас есть куча разных веб-фреймворков, большинство из них — просто микрофреймворки, но они все работают на Rack, и им не нужно переизобретать все заново, да и они могут работать на разных веб-серверах. Вот что я хочу спросить — появляется ли шанс у новых фреймворков, которые сейчас развиваются, например, как его.. От Люка Гуиди, как он называется? Кир ..?! Ярослав Так, щас (гуглит). Lotus, он называется Lotus. Видел? Аарон Неа. Ярослав Ладно, скину ссылку, это хорошая вещь. Там идея в том, что лучше бы вам, ребята, использовать паттерны, и использовать их на полную катушку, без рельсизмов. Аарон Ага. Ярослав Так вот, пока Rails переходит на новое API, есть ли шанс, что разовьются фреймворки, которые скажут — знаете, Rails вам больше не нужен. Потому что вам не нужен ActionView, раз уж куча приложений работает на JavaScript интерфейсах.. Аарон Угу. Ярослав .. куча вариантов с ORM, как Sequel, например, так вот, будет ли большая конкуренция? Аарон Ээ, думаю, будет большая конкуренция, но конкуренция и так есть, и будет еще больше. Но, это очень хорошо. Я имею в виду, это будет пушать Rails вперед еще больше. Штука с Rails — не нужно принимать решения вроде «какую бы ORM мне использовать?», или там, какой шаблонизатор — ты абстрагирован от таких проблем и можешь сосредоточиться на самом приложении. Не нужно об этом думать. Но, если будет больше рельсоподобных фреймворков, они будут двигаться вперед и будет конкуренция — это хорошо. Ярослав Еще одна штука про Rails — ну, тролинг, но все-таки — куча людей говорят, что Rails, то есть, Ruby — он только хорош для Rails, знаешь? Точно есть фреймворки для управления конфигурацией, большинство из них работает на Ruby — Chef на Ruby, Puppet на Ruby, да и скриптования на Ruby куча — насколько я слышал, в Amazon куча скриптования внутри на Ruby. Думаешь ли ты, что Ruby должно быть намного больше в каких-то областях? Больше скриптования, или эмбеддинга, чего-нибудь такого? Аарон Ммм. Мне сложно сказать, я веб-чувак. Мне нравится Ruby на вебе использовать, но, в смысле.. Мне Ruby для всего нравится использовать. Скриптование, просто скриптование. Разработка для встраиваемых систем — mruby для этого лучше, конечно, но знаешь.. Я везде использую Ruby, и думаю, что большему количеству людей тоже стоило бы так делать. Неправильно говорить, что Ruby — это только для Rails, совсем. Есть куча примеров, как ты и говорил, Chef и Puppet — все это показывает, что есть куча способов использовать Ruby, где бы ты не работал. Ярослав Точняк. Так.. Аарон (продолжает синячить портвейн) Хорошая штука! Ярослав Серьезно? Аарон Да, мне нравится. Порто А-ле-гро? Ярослав Порто Аллегре, да. Аарон Порто Аллегре Руби. Хорошая штука! Кир Когда я был в Португалии, взял с собой семь литров. Семь бутылок. Аарон (довольно зевает) Ярослав Долейте чуваку. Аарон Извините, что прерываем подкаст такими разговорами. Ярослав Да, это была хорошая идея. Ребята думали, что я шутил, когда спрашивал, брать одну бутылку или две. Аарон (смеется) Ярослав Ладно, еще вопрос. Есть такая штука с русскими митапами по Ruby — по крайней мере половину времени мы говорим о языках, отличных от Ruby. Иногда больше, чем половину времени. Обычно люди интересуются функциональщиной. Аарон Угу. Ярослав То есть, Erlang, Clojure, Scala; Elixir — это горячая тема. Аарон Rust! (смеется). Go, Rust, ну да. Ярослав Функция была представлена неделю назад и безнадежно устарела — вот тебе Rust. Аарон (смеется) Да, точняк. Ярослав Так тебе нравятся какие-то языки кроме Ruby, что ты используешь? Какие именно? Аарон Да-да. Что мне нравится в Ruby сообществе — так это то, что мы не замыкаемся на самом Ruby, всегда смотрим на другие языки и вообще изучаем программирование. Ярослав Ну, с Ruby началась революция «у нас есть задача, надо подобрать под нее язык». Аарон Да. Ну вот, я в последнее время учил Rust. Пытаюсь учить Elixir. Но вообще я много пишу на Scheme. Ярослав То есть, раз нравится Scheme, нравится и Clojure, наверное? Аарон Да, ну, Clojure клевый. Мне очень нравится Clojure. Главная причина, по которой я использую.. Я использую CHICKEN Scheme, главная причина — я в свободное время много пишу для встраиваемых систем, так что нужна хорошая поддержка C. И там хорошая поддержка C-библиотек и всякое такое. Но да, Clojure клевый. Ярослав Тебе нравятся языки на JVM, например, или просто все подряд? Аарон Все подряд, мне плевать, на чем оно работает. C, JVM, Erlang, мне все равно. Главное, чтобы язык нравился. Ярослав Еще вопрос. У меня есть, вроде как, любимый вопрос для опенсорс знаменитостей. Глупый немного, но думаю, с этой проблемой сталкивался любой, кто начал заниматься опенсорсом, или, может быть, даже закончил заниматься из-за этого. В общем, многие, кто занимается опенсорсом, особенно популярными проектами, сталкиваются с кучей негатива, да? Аарон Угу. Ярослав В общем, люди часто тебе говорят, что код у тебя отстой, и подход твой отстой, и надо делать все по другому, и вообще сходил бы ты подучился. Есть люди, которые к тебе относятся, как будто они твои заказчики.. Аарон Да-а-а. Ярослав И вот они тебе объясняют, что ты обязан что-то сделать, и они расчитывают, что ты управишься к понедельнику, знаешь? Так вот, как ты с таким негативом борешься? И ты вроде как — не знаю, как по-английски — расстрельный человек? (я имел в виду расстрельную должность — прим. пер.) — в общем, человек, на которого все пальцем покажут, если что-то пойдет не так. Вот, помнишь начало года, проблемы с безопасностью.. Аарон Ой, да. Ярослав В общем, сначала все обсуждают проблемы с безопасностью и говорят — эти чуваки отстой, у нас уязвимость. Аарон Да! Ярослав А потом ты фиксишь и пушаешь релиз, и все такие — теперь мне еще и все приложения обновлять! Аарон (смеется) Ярослав В общем, ты долгое время этим занимался, так что как ты с этим справляешься? Аарон Ну, тут такое дело. Надо понимать, что на каждого человека, который жалуется и говорит что код твой отстой, или что-то такое, найдется сто человек, которые, вообще-то, очень довольны твоей работой. Ярослав Да, но они молчат же. Аарон Да, ты просто от них ничего не слышишь. Но надо.. Лично я это просто держу в голове. Каждый раз кто-то говорит — ты отстой, и так далее — я просто не обращаю внимания, потому что знаю, что есть еще очень много людей, которым очень нравится то, чем я занимаюсь. И знаешь, вообще есть люди, которые на самом деле говорят — спасибо за то, что ты делаешь. Такое довольно часто случается. И я себя так чувствую.. Ну, один человек, который сказал спасибо, отменяет негатив по крайней мере от десяти других. В общем, не знаю, по-моему, у меня иммунитет выработался. Ярослав Знаешь, я вспоминаю твой твиттер, когда обсуждались проблемы с безопасностью, ты пытался выпустить релиз, и ты писал в том духе, что это твой последний релиз, был очень раздражен. Так ты что, просыпаешься утром и проблемы проходят? Аарон Да, да. Нельзя, чтобы такие вещи тебя задевали, просто нельзя. Я знаю, что это все очень влияет на нервы и знаю многих людей, которые мне говорили, что больше не выдержат и просто уходили. Но, не знаю, мне просто все равно (смеется). Вот к чему все сводится. Ярослав Так, еще одна спорная вещь, которую хочется обсудить. Было несколько людей из Rails Core тут в Москве за эти годы, с некоторыми я говорил, и все сходятся на том, что есть проблема с разработкой Rails: у тебя есть клевая идея, или фича, и ты даже делаешь патч для нее, и тут приходит Дэвид и говорит: «я этого не вижу в Rails». Аарон Ох, да. Ярослав Ну и многие люди, с кем я говорил — кто-то из Rails Core, кто-то, кто хотел бы попасть в Core — рассказывали, что не могут так работать. Так что, какой есть способ защищать свои идеи и пушать их в Core сейчас? Аарон Ну, я расскажу тебе секрет, но тебе придется дать слово, что никому не расскажешь. Ярослав Кроме слушателей. Аарон Кроме твоих слушателей. Слушатели, пожалуйста не рассказывайте никому. А секрет такой: коммитишь и не спрашиваешь. Ярослав … Аарон Коммичу и все. Ярослав Такой твой секрет? Аарон Да! Надо попасть в команду Rails Core, и делай все что хочешь. Добавляешь что-то, и если никто не заметит — то все зашибись (смеется). Да, ну а если честно, я иногда так делаю — добавляю какую-то определенную фичу, которая мне нужна, и если всем все равно — люди же видят, что ты коммитишь — и если всем все равно, она там остается. Но, на самом деле, вот что нужно сделать: нужно разработать.. Как бы это.. Вкус к тому, что может войти в Rails, а что нет. Я в команде Rails Core уже так долго, что я теперь вроде как могу предсказать, что DHH отклонит, а что ему понравится. И на сто процентов я это сделать не могу. Приходится его изучать, и пробовать как-то представить свою идею так, чтобы ему понравилось, и тогда все получится. Ярослав То есть, ты говоришь, что Дэвид все еще всем рулит? Аарон О да, однозначно, да. Ярослав Все еще Basecamp Rails? Аарон Однозначно. Basecamp Rails! (смеется) Ярослав У вас там еще есть секретный Campfire, где вы все обсуждаете? Аарон Ну, у нас есть комната в Campfire, она особенно и не секретная. Любой может попроситься, мы пригласим — это неважно. Ну, надо спросить — «эй, мне можно попасть в комнату?» — и мы пригласим (не делайте этого, если не уверены — прим. пер.). Но да, есть у нас комната в Campfire, где мы обсуждаем все, но Basecamp все еще… Имеет очень «сильное влияние»… (смеется) Я пытаюсь об этом сказать настолько мягко, насколько это возможно! Не думаю, что будет RedHat Rails. Ярослав Да, но много было разговоров о том, чтобы делать форки. Некоторые ребята из Rails Core думали о том, чтобы сделать форк. Ну, и я многого не знаю, но GitHub работает на собственном форке с устаревшей версией Rails, большой форк. Аарон Угу. Ну, это правда, но большинство людей.. Сложно получить какую-то поддержку (traction — прим. пер.) форка — нужно достаточно людей, нужно что-то, из-за чего люди его поддержат. Ярослав Вроде сотни гитхаберов. Аарон Да, вроде сотен гитхаберов. Точно. Нужно много людей на борту. Но вот форк GitHub — там вещи, специфичные именно для них, для GitHub. То, над чем я сейчас работаю в RedHat — нам, наверное, не нужно, то что сделал GitHub. Так что нам сложно найти общее. Ярослав Да, но все еще много чего нет. Например, у нас до сих пор нет нормальной.. По крайней мере, нормального API для партишенинга баз данных, потому что.. Аарон Да-а-а. Ярослав Потому что в Basecamp не хотели бы покупать больше одной БД. Аарон Да, все правда. Ярослав Поэтому приходится работать со страшными хаками, которые ломаются из релиза в релиз. Аарон Ну, хорошая новость в том, что в приложении, над которым я работаю в RedHat, есть партиционирование баз данных, так что, наверное, увидим его в будущих версиях (смеется). Ярослав Так, вопросы, наверное, кончились, давай последний. Много ребят приходят в Rails Core, много ребят уходят, да? Кто-то водит блестящие спорткары, у кого-то появляются новые хобби, кто-то основывает успешные компании, как Тоби (Tobias Lütke, CEO Shopify — прим. пер.), кто-то может обнаружить, что у него три ребенка, которых растить надо. Так вот, какие у тебя.. Глупый вопрос, но какие у тебя лично планы на Rails? Не устал ли ты сейчас, много ли осталось времени именно тебе в Rails? Я спрашиваю потому, что иногда кажется, что ты — такой последний герой, как тогда с проблемами с безопасностью. Аарон Не знаю. Причина, по которой я работаю над Rails.. Ну, я программист. И я работал на компании.. Я работал на много компаний, которые делают какой-то продукт.. Я не знал, скольким людям я помогаю, не понимал необходимости того, что я делал. Звучит хреново. Когда я работаю над Rails, я делаю продукт, который помогает точно таким же людям, как я; я веб-разработчик, и когда я делаю очередные улучшения, я помогаю моим друзьям — всем, кого я знаю, кто делает то же самое. Так что я продолжаю делать то, что делаю.. Хочу, чтобы у других разработчиков, таких же как и я, были инструменты лучше, чтобы мир, в котором они работают, был лучше. Хочу, чтобы моим продуктом с удовольствием пользовался я сам и мои друзья. Поэтому и продолжаю. Ярослав А у тебя не бывает таких мыслей по ночам, вроде, блин, я веб-разработчик, сколько уже, 5-10 лет, я не занимаюсь улучшением здоровья людей, не занимаюсь правительственными вещами.. Аарон Да.. (смеется) Ярослав Не занимаюсь супер-нагруженными штуками, и все что я делаю — HTML и CSS, так что отстойный из меня программист. Ну, многие молодые ребята так думают. Думают, к черту все это, пойду Clojure заниматься, или чем-нибудь таким. Аарон Нуу. Иногда я думаю о таких вещах, но, все-таки, я занимаюсь тем, что лучше всего умею, так что раз уж я чем-то хорошо умею заниматься, мне стоит стараться делать это лучше всего, да? Так я больше всего смогу повлиять на мир. Ну да, я думаю о таких вещах, но.. Раньше я от этого расстраивался, но теперь я понял, что раз уж я хорош в том, что делаю, значит так я могу больше всего улучшить мир, и больше это проблемой не кажется. Ярослав В общем, ты счастлив? Аарон Да, точно. Ярослав Спасибо, с нами был Аарон! Аарон Тебе спасибо. Интервью с Йонасом Кир Пишем! Так вот, это твой первый визит в Москву? Йонас Да, все так. Кир Как тебе в Москве, что думаешь о городе? Йонас Да все хорошо. Организаторы конференции очень хорошо о нас заботятся. Здорово провел время здесь в городе, видел много классных вещей. Хотел бы побыть подольше, но, к сожалению, уезжаю уже завтра, вот. Кир Три дня, да? Йонас Три дня. Кир Начнем больше про программирование. Планируешь новую большую версию Carrierwave? Йонас Я вообще не особенно участвую в проекте в последнее время. Я взял самоотвод как мейнтейнер.. Довольно давно, два-три года назад. Но, вообще, было очень интересно сегодня слышать презентацию, не помню имя спикера (Кирилл Горин из Coub — прим. пер.), он, в общем, написал похожую библиотеку на Carrierwave. Кир Да, его зовут Кирилл. Йонас Кирилл, да. Кир Изменил ли ты что-то в Carrierwave, если бы у тебя была возможность сделать какие-то вещи по-другому? Лет пять назад, или вроде того. Йонас Ну да, если сейчас вспоминать о том, что было, точно есть какие-то вещи.. Он был написан в другое время. Кир Согласен. Йонас Так что.. Библиотека изначально, что довольно смешно, была плагином для Merb, так что если посмотреть на первые коммиты, она вообще-то называлась merb-upload, и долгое время не называлась Carrierwave. И в то время Rails приложения по-другому разворачивали (деплоили), была другая архитектура и администрирование по-другому велось, так что.. В некотором смысле, думаю, сейчас надо было бы строить библиотеку для загрузки файлов по-другому, не так, как я сделал в Carrierwave раньше. Она все еще решает многие проблемы хорошо, но можно было бы решать и проблемы посложнее, из числа тех, которые она сейчас не решает — загрузку напрямую с клиента (видимо, речь идет о прямой загрузке на S3 минуя сервер — прим. пер.), фоновую обработку, и всякие такие вещи, которыми она сейчас не занимается. Кир У нас сейчас есть клиент с довольно большим Rails приложением.. Йонас Угу. Кир Там, например, несколько сотен тысяч загрузок каждый день (Кир оговорился, на самом деле десятки тысяч — прим. пер.), и мы по полной используем Carrierwave. И однажды я обнаружил, насколько там здоровенный стек. Там был carrierwave_backgrounder, и сверху — куча вещей, чтобы сделать кастомный URL для хранилища в S3, так что стек там был такой большой.. В общем, для следующего проекта я начал писать свою библиотеку — небольшую замену, только с тем, что мне нужно, и было очень интересно. А вообще, большое тебе спасибо за Carrierwave. Так вот, теперь к Capybara. Будет что-нибудь новенькое с Capybara? Йонас Хех. Надеюсь. Я, в общем, и в этом проекте не так много делаю теперь. Но, думаю, безопасность в многопоточной среде будет проблемой. То, о чем Аарон говорил на своем докладе, про то, как тесты должны идти в параллель — многое из этого применимо и к Capybara. А текущая реализация небезопасна для работы в несколько потоков, что, конечно, проблема. Так что это то, чему мне, или кому-то еще, придется заняться в будущем. Кир Расскажи, какие развивающиеся языки тебе интересны? Йонас Мне дико интересен Rust. Думаю, это потрясающий язык. И из-за него меняется мое представление о программировании, так что.. точно рекомендую всем на него посмотреть. Он слишком новый и слишком нестабильный, так что новую версию вашего большого приложения на нем писать не стоит, пока что. Но он очень интересен тем, что обещает быть заменой C и C++ — таким же быстрым по скорости, но намного лучше. И безопаснее. Кир Знаешь кого-нибудь, кто использует Rust в бою? Йонас Да! Ребята из Tilde — это где работает Йехуда Кац. Кир Это приложение для знакомств? Йонас Нет, это Tinder. Tilde делают продукт под названием Skylight.. Кир А, да, да. Йонас Сервис для мониторинга Rails. И у них часть клиента, клиентской штуки на Rust — то, что раздают людям. И, вроде бы, используют его и на стороне сервиса, но я не уверен на сто процентов. Думаю, это первое, и, может, единственное использование Rust в продуктиве. Кир И спасибо тебе большое за pundit! Йонас Ой, да. Кир Я пушаю ребят в нашей команде, чтобы мы больше использовали pundit у себя, и людям он очень нравится, и очень классно им пользоваться после cancan. Потому что можно писать эти миниатюрные классы с настройками доступа.. Мы несколько раз о нем рассказывали в нашем подкасте. Йонас Да, здорово, спасибо большое. Действительно, веселый проект. Оказывается, люди с большим энтузиазмом к нему относятся. Кажется, он становится де-факто стандартом для авторизации в Rails — круто для такой небольшой библиотеки. Там всего сотня строк кода. Но нам она точно помогла во многом. Оказалось, с ее помощью мы сильно улучшили код в нашем приложении, который относится к авторизации. Кир Так ты сейчас сфокусирован на pundit? Йонас Ну, он не то чтобы много энергии у меня отнимает, слишком маленький проект. У него неожиданно большое количество контрибьюторов, но это в основном небольшие поправки здесь и там. Так что это не такой проект, как Capybara или Carrierwave, который занимает много времени. Вот. Я сейчас в основном занимаюсь изучением других языков, и занимаюсь всякой всячиной для собственного удовольствия. Кир Спасибо за интервью! Йонас Без проблем. Мы также выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
09.10.2014

Ruby NoName Podcast S06E16

Наш гость — Андрей Ситник Промокод для скидки на RailsClub: rubynoname Конкурс Осенью 2014 года Злые марсиане проведут два курса в Москве — Брейнвошинг по Ruby on Rails (11-14 октября) и Брейнвошинг по фронтенду (18-21 октября). Чтобы получить ссылку при оформлении билета, укажите в поле комментариев код «RUBYNONAME» — это даст вам (или оформляющему билет вашему работодателю) скидку 2000 руб. Еще можно с помощью специальной ссылки на странице каждого из курсов задать вопрос преподавателям — если вопрос будет интересный, мы с удовольствием опубликуем ответ, а вы получите скидку 5000 руб. Брейнвошинги очень полезные, но относительно дорогие, и возможность посетить их есть не у всех. Для поощрения open-source активистов мы вместе с Ruby NoName Podcast уже во второй раз проводим конкурс, приз которого — бесплатное посещение одного из брейнвошингов за вклад в open source. Условия Участники конкурса присылают свои open source работы за сентябрь (и оставшуюся до подведения итогов конкурса часть октября) нам в редакцию. Нужно прислать ссылки на свои коммиты или pull requestы, желательно с описанием или со ссылкой на статью в блоге с описанием — нам в комментарий к Gist и по почте info@rubynoname.ru. В письме не забудьте указать, как быстрее всего с вами связаться (почта и телефон, например). Мы рассматриваем работы на Ruby (улучшения/патчи/PR в Rails, популярные гемы, или ваши собственные новые проекты) и работы по фронтенд-части (тут спектр уже — нас интересуют только улучшения PostCSS, а еще лучше — собственные разработки на базе PostCSS; про него слушайте в подкасте). Единственный победитель будет выбран ведущими подкаста и брейнвошингов. Крайний срок подачи работ — 6 октября 2014 года (чтобы вы за неделю до первого брейнвошинга еще успели спланировать время и попасть на курс). Победитель может выбрать один из брейнвошингов для бесплатного посещения. Андрей Ситник Профиль на Гитхабе Профиль в Твиттере Сайт Проекты Autoprefixer PostCSS evil-blocks evil-front visibility.js easings.net R18n Прочее «Цифровой шаббат», статья в «Хакере» Сайт Сергея Короля Мы также выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
24.09.2014

Ruby NoName Podcast S06E15

Наш гость — Павел Аргентов Промокод для скидки на RailsClub: rubynoname Профиль на Гитхабе Профиль в Твиттере Павел очень рекомендует ЖЖ Анатолия Левенчука
13.09.2014

Ruby NoName Podcast S06E14

Конференции Промокод для скидки на RailsClub: rubynoname 27 сентября пройдет RailsClub 2014 rubyconf 17-19 ноября, Сан Диего rubyconf Argentina 24 октября, Буэнос Айрес FrozenRails 11-12 сентября Новости Рельсе 10 лет (24 июля 2004 — первый публичный релиз 0.5) Rails 4.0.8, 4.1.4. Security с PostgreSQL Range Matz Reddit AMA (видео) Rails Rumble 2014: 18-19 октября 1.8.7, 1.9.2 EOL 31 июля Matz: My vague plan for Ruby GIL is 1) add more abstract concurrency e.g. actors 2) add warning when using threads directly 3) then remove GIL Rails 4.2 new sanitizer Rails и front-end, David Bryant PgHero Mediator Pattern Timeouts in Ruby (MRI) Pstore Jekyll 2.2 FactoryGirl Tips factory_girl-seeds Advanced aRel: When ActiveRecord Just Isn't Enough Basecamp: Search с DHH Memoization patterns Create mocks from active record models and run them without loading rails or running a database Rmagick всё Roda by Jeremy Evans .dup vs .clone А также выражаем благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
25.08.2014
avatar
  Подписаться  
Уведомлять о