Ruby NoName podcast

By Андрей Дерябин и Кир ШатровTechnology Tech News

Ruby NoName podcast episodes

October 21, 2015 Ruby NoName Podcast S07E02
На RailsClub 2015 мы традиционно взяли интервью у спикеров конференции.
Первое интервью было с разработчиками Медузы: Саматом Галимовым и Борей Горячеевым.
Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
44 min
June 02, 2015Ruby NoName Podcast S07E01
Михаил Клишин
Профиль на Github
Твиттер
Ресурсы от Миши Клишина
ClojureWerkz
Cloud Foundry
Docker
Pivotal
Pivotal Labs
Tammer Saleh
Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
1 hr 18 min
December 31, 2014Ruby NoName Podcast S06E21
Умер Эзра @ezmobius, автор Merb, сооснователь Engine Yard
Rails 4.2
active form
Ruby 2.2.0-preview2
Raptor оказался Phusion Passenger
active_emoji от @sferik
Язык PETOOH
Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
16 min
December 11, 2014Ruby NoName Podcast S06E20
Rubyconf 2014
Про статически типизированный Руби
Программа конференции
Записи докладов
Фотоальбом Кира
Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
26 min
November 16, 2014Ruby 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 и видео про него
Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
22 min
October 27, 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 страниц, это было
бы странно. Но, думаю, небольшая книга будет полезна многим.
Ярослав
Ну что же, удачи в написании книги. Спасибо, что зашел!
Божидар
Вам спасибо.
Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
43 min
October 09, 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,
который занимает много времени. Вот. Я сейчас в основном занимаюсь изучением
других языков, и занимаюсь всякой всячиной для собственного удовольствия.
Кир
Спасибо за интервью!
Йонас
Без проблем.
Мы также выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
43 min
September 24, 2014Ruby 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 и по почте [email protected]. В письме не забудьте указать, как быстрее всего с вами связаться (почта и телефон, например).
Мы рассматриваем работы на Ruby (улучшения/патчи/PR в Rails, популярные гемы, или ваши собственные новые проекты) и работы по фронтенд-части (тут спектр уже — нас интересуют только улучшения PostCSS, а еще лучше — собственные разработки на базе PostCSS; про него слушайте в подкасте).
Единственный победитель будет выбран ведущими подкаста и брейнвошингов. Крайний срок подачи работ — 6 октября 2014 года (чтобы вы за неделю до первого брейнвошинга еще успели спланировать время и попасть на курс). Победитель может выбрать один из брейнвошингов для бесплатного посещения.
Андрей Ситник
Профиль на Гитхабе
Профиль в Твиттере
Сайт
Проекты
Autoprefixer
PostCSS
evil-blocks
evil-front
visibility.js
easings.net
R18n
Прочее
«Цифровой шаббат», статья в «Хакере»
Сайт Сергея Короля
Мы также выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
1 hr 1 min
September 13, 2014Ruby NoName Podcast S06E15
Наш гость — Павел Аргентов
Промокод для скидки на RailsClub: rubynoname
Профиль на Гитхабе
Профиль в Твиттере
Павел очень рекомендует ЖЖ Анатолия Левенчука
52 min
August 25, 2014Ruby 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
А также выражаем благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
33 min

About Ruby NoName podcast

From the publisher's feed

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

Share Ruby NoName podcast

Sign up to save your podcasts

Ruby NoName podcast

Ruby NoName podcast episodes

About Ruby NoName podcast