Спонсор выпуска — Vexor CI – облачный continuous integration сервис для ruby разработчиков с поминутной оплатой.
С учетом поминутной оплаты, Vexor очень выгоден для маленьких проектов и эффективен для больших. Каждому новому пользователю предоставляется $10 на счет для экспериментов.
Расшифровки
Коллекция рецептов для быстрого руби от Эрика.
Интервью с Эриком
Кир
Первый раз в Москве?
Эрик
Ага, да.
Кир
И как тебе Москва, что думаешь о городе?
Эрик
Очень красивый город. Первый раз тут, и мне все очень нравится. Погода хорошая;
вчера гуляли, были в музее космонавтики и в музее холодной войны — было здорово.Кир
Круто.
Эрик
Ага.
Кир
Так вот. Ты работаешь в 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 и RailsStyle 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 страниц, это былобы странно. Но, думаю, небольшая книга будет полезна многим.Ярослав
Ну что же, удачи в написании книги. Спасибо, что зашел!
Божидар
Вам спасибо.
Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.