Спонсор выпуска — 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 страниц, это было бы странно. Но, думаю, небольшая книга будет полезна многим. Ярослав Ну что же, удачи в написании книги. Спасибо, что зашел! Божидар Вам спасибо. Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.